4a/ Serialize all request/response exchanges. i.e. request comes in from remote node, proxy aquires lock on the proxy-localdaemon channel and sends request. Channel remains locked until response is received or timeout (in which case remote node gets no response). Unlock channel after response received and send to client.
Possibly messages that don't expect a response (e.g. relaying a tx broadcast from remote node) can be pushed down a locked channel to improve performance as they won't interfere with sequencing. Locked channels may also receive other unsolicited messages from local daemon before the expected response message which would be dealt with the same as if they came from an unlocked channel. Disadvantages: Idle time for channel while waiting for response. As per option 2 this allows the proxy to stay dumb/thin but loses opportunity for de-duplicating/caching unless option 1 is layered on top. 4b/ As per 4a but use all 125 available bitcoind connections in a channel pool. Acquiring a lock on a channel consists of checking for an unlocked channel first then waiting in a queue for one to become available. ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
