From: Steve <shadders.del@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Building a node crawler to map network
Date: Wed, 07 Sep 2011 00:17:29 +1000 [thread overview]
Message-ID: <4E662B79.5090303@gmail.com> (raw)
In-Reply-To: <CANEZrP3=UPYkBQo6b421xaMGyP4BsGiw8DBuM8pT2ow1Vom9JQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]
Hi Mike,
I expect I'll be submitting patches for bitcoinj sometime in the future
but I'm not really across it yet to the point where I'd be confident
submitting patches right now...
This proxy sound like a good match for what I've been up to lately
though so long as it wouldn't involve direct changes to bitcoind on my
part. My c/c++ skills are non-existent.
However I have been building a pool protocol using protobufs and netty
for non-blocking IO and I'd imagine the kind of multiplexing proxy
you're talking about could be easily implemented using netty.
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? Or
is it to provide capactity for a more hub/client oriented network? If
the latter then presumably this is functionality that should ideally be
native to the client in the long term in the form of NIO?
On 06/09/11 23:31, Mike Hearn wrote:
>
> I've looked but can't find a post like you're talking about. Can
> you point me to it?
>
> https://groups.google.com/forum/?pli=1#!topic/bitcoinj/LSlZdUWcCdk
> <https://groups.google.com/forum/?pli=1#%21topic/bitcoinj/LSlZdUWcCdk>
>
> If so then bollocks... I'm looking for something useful to do atm.
> PoolServerJ is in a holding pattern atm as I've stabilisied all
> the bugs I know about and am waiting for several pools to finish
> testing and move into production so I'm twiddling thumbs trying to
> figure out how to spend my time.
>
>
> Patches to BitCoinJ are always welcome :-)
>
> If you'd rather do your own thing, you could experiment with writing a
> proxy that sits in front of bitcoind and multiplexes connections.
> Gavin is concerned about socket exhaustion as users move to
> lightweight clients. Multiplexing proxies are a battle-tested
> technique for reducing the strain of this type of thing. BitCoinJ uses
> thread-per-connection so wouldn't do a good job of that right now, but
> allowing it to use a mix of async io and multi-threading would be a
> nice improvement. It'd need some changes to bitcoind as well for a
> really good effort, to allow for IPs to be forwarded. I'm happy to
> discuss it more with you over on the bitcoinj list if wanted.
[-- Attachment #2: Type: text/html, Size: 3612 bytes --]
next prev parent reply other threads:[~2011-09-06 14:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-06 7:42 Steve
2011-09-06 8:29 ` Steve
2011-09-06 8:36 ` Christian Decker
2011-09-06 12:49 ` Mike Hearn
2011-09-06 13:27 ` Steve
2011-09-06 13:31 ` Mike Hearn
2011-09-06 14:17 ` Steve [this message]
2011-09-06 14:52 ` Mike Hearn
2011-09-06 15:25 ` Steve
2011-09-06 14:36 ` Rick Wesson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E662B79.5090303@gmail.com \
--to=shadders.del@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox