Quote from: nexern on February 02, 2014, 12:48:20 PM

Quote from: l8orre on February 02, 2014, 09:33:19 AM

Quote from: opticalcarrier on February 02, 2014, 06:13:17 AM

Quote from: Come-from-Beyond on February 02, 2014, 06:03:56 AM

Quote from: rickyjames on February 01, 2014, 11:51:21 PM

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?

hi l8orre, initialisation and sending funds are sync, updates while runnning async.
data is completely memory buffered without the need to buy latency via a disk based
database approach. closing the client writes a compressed runtime-image to disk
and loads it in one call to memory when started again. this structure removes problems
with orphaned blocks and not updated transaction confirmations, because the whole
account structure is updated, not incremental but complete. an average account
is loading/updating in 15-30 sec. this way. fast enough even with upcoming lesser block
creation time.

ps: iirc you are using python, just throw the json into a collection during runtime and dump
the collection serialized to disk. it's like a mini redis. superfast robust and easy to handle.
the lastest api improvements removed the need parsing raw blocks and transactions and
you can run an http/https async loop to update the structure in complete without the
need to care about timers and race conditions.

Thanks for the hints! Appreciated!