CfB can offer a minimum bound on bandwidth required for 1000 TPS (1 MBS) but can't say how many NXT service nodes that can handle the full blockchain are required.
I forgot about a very important detail. 1000 tps @ 1 Mbps assumes that we use
binary protocol. Now all data in protocol is encoded in
JSON, this adds 3x-5x overhead.
We have to migrate to binary protocol before switching TF on.
I guess after the migration that the API as we know it now would cease to exist? If so, how about if we did switch to full TF, but kept JSON transport? Obviously we couldnt expect 1Mtps then, but could we expect 200Ktps?
If so that should sustain us well long enough to get a testbed setup to convert peerexplorer, block explorers, and custom clients over to a binary transport protocol.
@CfB & Client Devs: I was seriously considering putting the requests sent to the NRS into a separate thread in order not to block the GUI while it is under way. With MANY requests passing back and forth, this can be a real problem, when the GUI seems unresponsive!
Do you guys use a separate NRS-request Thread? And is this still neccessary when the legacy thing CfB mentioned is droppped?