From: Steve <shadders.del@gm...> - 2011-09-08 08:16:03
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.
It's probably best to keep this discussion on just one mailing list. It's
confusing to have duplicate threads in different places. People will end up
making the same points.
To repeat what I posted elsewhere, for now I'd just start with the simplest
- Ignore version skew for now (disconnect older clients)
- Don't send received transactions/blocks to the bitcoind. Let it hear about
them from its own p2p connections. That way you will always receive all
valid transactions/blocks which you can then relay/cache/drop inbound
- Parse/handle inv/getblocks/getheaders requests so clients that connect and
catch up with the chain don't place any load on the bitcoind. If a client
requests data the proxy doesn't have in RAM, it can go fetch it from the
If you can make v1 work and demonstrate actual scalability improvements,
then you can always go back and make it smarter in v2.
From: Steve <shadders.del@gm...> - 2011-09-08 10:29:59
> It's probably best to keep this discussion on just one mailing list.
> It's confusing to have duplicate threads in different places. People
> will end up making the same points.
Fair enough I'll take it to the bitcoinj list. I wanted to post here in
case I got any nibbles from c developers about option 2. If anyone
want's the follow this discussion on the other list it's here: