1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <shadders.del@gmail.com>) id 1R0wTB-0000dT-1I
for bitcoin-development@lists.sourceforge.net;
Tue, 06 Sep 2011 14:17:45 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=shadders.del@gmail.com;
helo=mail-qy0-f175.google.com;
Received: from mail-qy0-f175.google.com ([209.85.216.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R0wTA-0000nl-25
for bitcoin-development@lists.sourceforge.net;
Tue, 06 Sep 2011 14:17:44 +0000
Received: by qyk4 with SMTP id 4so552145qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Tue, 06 Sep 2011 07:17:38 -0700 (PDT)
Received: by 10.229.70.130 with SMTP id d2mr1860993qcj.130.1315318658593;
Tue, 06 Sep 2011 07:17:38 -0700 (PDT)
Received: from [10.1.1.50] (155.88-67-202.dynamic.dsl.syd.iprimus.net.au.
[202.67.88.155])
by mx.google.com with ESMTPS id x15sm195585qaa.25.2011.09.06.07.17.35
(version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 07:17:37 -0700 (PDT)
Message-ID: <4E662B79.5090303@gmail.com>
Date: Wed, 07 Sep 2011 00:17:29 +1000
From: Steve <shadders.del@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <4E65CEE6.7030002@gmail.com> <4E65DA06.9060403@gmail.com> <CALxbBHUajARXc1oA-NjD+U8hW5uSqF=u4ZHHBfcmT_O8GjpNiA@mail.gmail.com> <CANEZrP0VXDUs_mAKCVKD1Q0ijyb989oADrCN1zTZ1nnN_JQ=cQ@mail.gmail.com> <4E661FAE.9020008@gmail.com>
<CANEZrP3=UPYkBQo6b421xaMGyP4BsGiw8DBuM8pT2ow1Vom9JQ@mail.gmail.com>
In-Reply-To: <CANEZrP3=UPYkBQo6b421xaMGyP4BsGiw8DBuM8pT2ow1Vom9JQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------020701080500050303030203"
X-Spam-Score: -0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(shadders.del[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R0wTA-0000nl-25
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Building a node crawler to map network
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shadders.del@gmail.com
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 14:17:45 -0000
This is a multi-part message in MIME format.
--------------020701080500050303030203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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.
--------------020701080500050303030203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mike,<br>
<br>
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...<br>
<br>
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.<br>
<br>
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.
<br>
<br>
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? <br>
<br>
On 06/09/11 23:31, Mike Hearn wrote:
<blockquote
cite="mid:CANEZrP3=UPYkBQo6b421xaMGyP4BsGiw8DBuM8pT2ow1Vom9JQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">I've looked but can't find a post like you're
talking about. Can you point me to it?<br>
</div>
</blockquote>
<div> </div>
<div><a moz-do-not-send="true"
href="https://groups.google.com/forum/?pli=1#%21topic/bitcoinj/LSlZdUWcCdk">https://groups.google.com/forum/?pli=1#!topic/bitcoinj/LSlZdUWcCdk</a></div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">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.</div>
</blockquote>
<div><br>
</div>
<div>Patches to BitCoinJ are always welcome :-)</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
</body>
</html>
--------------020701080500050303030203--
|
