On Tue, Sep 6, 2011 at 4:17 PM, Steve
<shadders.del@gmail.com>
wrote:
I'm not really
understanding the use case though. I believe most
bitcoind's have a default max connections of 8. Is the goal
to increase this without fundamentally altering the bitcoind
concurrency model?
bitcoind already uses asynchronous IO. That's not the
problem.
The issue came up in a conversation about scalability. If
Bitcoins popularity continues to grow, users are very likely
to migrate away from running full verifying nodes to
lightweight clients, either a different mode of the Satoshi
client or different implementations like the Android Wallet or
MultiBit.
Lightweight clients cannot verify thus should not relay.
And they'll be run by users who just want to send/receive
coins from time to time, so don't leave the programs running
24/7. The result could be running out of sockets (like we have
had problems with recently). It's especially true because
lightweight clients cannot check transactions for themselves.
If they want to show transactions appearing immediately (and
they do), they have to use "heard from lots of nodes" as a
proxy for validity. So lightweight clients are likely to be
socket intensive.
We could solve this by just hoping that lots of people run
full nodes. The problem is that a full node is quite an
intensive thing already, it uses lots of CPU and disk seeks,
and will just get more expensive in future. And as transaction
traffic increases, that leaves less CPU time available to
service thousands of connected clients. The ROI of bringing up
a new node decreases at the same time as the userbase
increases.
One traditional approach to solving this is frontend
proxies. Jabber.com/org used this technique many years ago,
and Google has also used it to scale up
the
lockservice (see section 3.1). It's effective because
often maintaining connections to thousands of clients doesn't
involve much brainwork, just shifting bytes around. This is
especially true of Bitcoin. So if somebody is running a full
node already they could increase their client capacity by just
bringing up a frontend proxy and having it handle things like
outbound tx broadcasts/deduping inbound broadcasts, connection
setup, relaying recently found blocks etc. A well written
proxy could probably support tens of thousands of simultaneous
clients which frees up the bitcoinds time for verification and
wallet manipulation.