diff options
| author | Mike Hearn <mike@plan99.net> | 2013-05-06 18:34:47 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-05-06 16:34:53 +0000 |
| commit | c80d69f701cf0aac0d7cbaad9a133f620921cf37 (patch) | |
| tree | f7cc5b9dc99e6d5c30e7d774b001ac00f86d1d20 | |
| parent | e21cc5ebf33b45538e313745d99e6f93934b324b (diff) | |
| download | pi-bitcoindev-c80d69f701cf0aac0d7cbaad9a133f620921cf37.tar.gz pi-bitcoindev-c80d69f701cf0aac0d7cbaad9a133f620921cf37.zip | |
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
| -rw-r--r-- | 3f/d64c2da6fe967077593308af7381011d218f35 | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/3f/d64c2da6fe967077593308af7381011d218f35 b/3f/d64c2da6fe967077593308af7381011d218f35 new file mode 100644 index 000000000..27d101e4e --- /dev/null +++ b/3f/d64c2da6fe967077593308af7381011d218f35 @@ -0,0 +1,91 @@ +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 <mh.in.england@gmail.com>) id 1UZONJ-0008UA-Lu + for bitcoin-development@lists.sourceforge.net; + Mon, 06 May 2013 16:34:53 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.45 as permitted sender) + client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com; + helo=mail-oa0-f45.google.com; +Received: from mail-oa0-f45.google.com ([209.85.219.45]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UZONI-0006Ez-S4 + for bitcoin-development@lists.sourceforge.net; + Mon, 06 May 2013 16:34:53 +0000 +Received: by mail-oa0-f45.google.com with SMTP id o17so3636924oag.4 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 06 May 2013 09:34:47 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.47.1 with SMTP id z1mr1195114oem.134.1367858087536; Mon, + 06 May 2013 09:34:47 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 09:34:47 -0700 (PDT) +In-Reply-To: <CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com> +References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com> + <20130506161216.GA5193@petertodd.org> + <CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com> +Date: Mon, 6 May 2013 18:34:47 +0200 +X-Google-Sender-Auth: HiiUrP-Uf3pPRohi6cYpC7-qyG4 +Message-ID: <CANEZrP12xibOx9jm1fgG=A2PzPf+6G+zrhtWC9+FnJjU2-t_NA@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Jeff Garzik <jgarzik@exmulti.com> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: -1.5 (-) +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 + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 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 +X-Headers-End: 1UZONI-0006Ez-S4 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits + for pruned nodes) +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: Mon, 06 May 2013 16:34:53 -0000 + +> > I've noticed on my Android phone how it often takes quite awhile to find +> > a peer that will actually accept an incoming connection, which isn't +> > surprising really: why should a regular node care about responding to +> > SPV nodes quickly? + +I haven't seen that - remote nodes don't have any special code that +knows what kind of client is connecting, so if you're seeing delays I +suspect the issue is elsewhere. For example a seed that is serving +peers which are overloaded, or the general delays inherent to bringing +up a 3G data link from idle (this can take many seconds all by +itself). + +I took out Jeffs seed a few weeks ago in git master because it was +often serving nodes that were full, so that should speed things up a +bit. The other seeds all run dynamic crawlers. + +There are lots other ways to optimise performance beyond having fresh +seeds, for example, the Android app can (and probably will in future) +support putting Bluetooth MAC addresses in the URLs it serves via +QRcode/NFC. We prototyped it before but didn't finish. That means that +the sending side can provide the receiving side with a transaction via +a local Bluetooth socket, which eliminates the need to wait for P2P +bringup on the send side. In a typical merchant scenario the receive +side is more likely to have WiFi access and is more likely to be +talking to the network frequently, so its list of IPs gathered from +addr packets would be fresher, and it can do P2P bringup whilst the +user is confirming/signing/uploading on the sending side. Overlapping +the two buys precious seconds. + + |