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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1Qp7a9-0003UA-E9
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 23:44:05 +0000
X-ACL-Warn:
Received: from mail-iy0-f171.google.com ([209.85.210.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qp7a6-0007kQ-FY
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 23:44:05 +0000
Received: by iyf13 with SMTP id 13so3584778iyf.30
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 16:43:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.244.3 with SMTP id lo3mr285490icb.335.1312501437031; Thu,
04 Aug 2011 16:43:57 -0700 (PDT)
Received: by 10.42.19.65 with HTTP; Thu, 4 Aug 2011 16:43:56 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
In-Reply-To: <201108041629.04130.luke@dashjr.org>
References: <BANLkTinus7PWNLJi9rEvTtSB93hjLKhFpg@mail.gmail.com>
<201107101442.43605.luke@dashjr.org>
<201108041629.04130.luke@dashjr.org>
Date: Thu, 4 Aug 2011 19:43:56 -0400
Message-ID: <CA+8xBpdYJVE_DkKrmZCUd1gAdoMzcLuS-7fBdZx+fPeYqTz83Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Qp7a6-0007kQ-FY
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 04 Aug 2011 23:44:05 -0000
>> =A0 threaded_rpc
>> =A0 \-- rpc_keepalive (depends on threaded_rpc, or a single connection w=
ould
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0keep the JSON-RPC interface l=
ocked up)
Definitely want _some_ path to HTTP/1.1 persistent connections, either
this or async I/O, https://github.com/bitcoin/bitcoin/pull/214
Based on field usage, it sounds like the above, threaded rpc, is more
stable. So my only question remaining, for which I've not yet
reviewed the code, is: what is the behaviour under assault from lots
of new incoming TCP connections? One very common problem with
threaded TCP servers is blindly creating new threads without any
filtering or checking of incoming connections, thereby quickly
reaching thread limits, possibly causing other parts of the program to
fail.
Any amount of RPC request volume, miner or not, sent to the present
implementation winds up using a lot of socket resources due to the
constant disconnect/reconnect demanded of the current HTTP/1.0 code.
This patch addresses that key issue, providing positive impact for all
production bitcoin sites using RPC.
Miners are hitting these problems now, and Gavin's right that mainnet
miners are a small portion of the total population, but our RPC server
implementation really is bloody awful at present. Reliable,
production TCP servers use either threads or async I/O, or a
combination of both (thread pool + async I/O =3D=3D win). Deploying
HTTP/1.1 persistent connections will make a positive impact at any
site heavily using RPC.
>> =A0 bugfix_CreateThread_leak
Did I leave something out, when merging
commit 67ed7d9d4929d8fe1c5f976c184c72dff02d83b7
Author: JoelKatz <DavidJoelSchwartz@GMail.com>
Date: Mon Jul 25 15:06:45 2011 -0700
?
>> =A0 getwork_dedupe (original branch for my bugfix)
I think we need this, but have not yet reviewed/thought about it.
>> =A0 gitignore (ignore some common misc files)
Sounds nice to have.
Jeff
P.S. I'm moving my home computer lab setup to a new house. Internet
will be spotty until August 11, and you won't see much of me at all on
#bitcoin-dev.
|
