Thanks for the overview Mike. I just bailed up Gavin on IRC and between
that convo and what you've just written I'm starting to picture a plan
in my head... This sounds right up my alley, I wish I didn't have to go
to bed right now as I've got a ton of ideas buzzing around I'd like to
get started on right now. But I'll be onto it as soon as I've got a
free moment...
On 07/09/11 00:52, Mike Hearn wrote:
On Tue, Sep 6, 2011 at 4:17 PM, Steve <shadders....@gmail.com
<mailto:shadders....@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
<http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/chubby-osdi06.pdf> (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.
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
