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 ) 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 ; 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: <201107101442.43605.luke@dashjr.org> <201108041629.04130.luke@dashjr.org> Date: Thu, 4 Aug 2011 19:43:56 -0400 Message-ID: From: Jeff Garzik To: Luke-Jr 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.