summaryrefslogtreecommitdiff
path: root/57/33e6e4cb618f72df253ab991d4a9e8c1e14467
blob: 693ff858870ad55e2fc53e0c6c1358f7171e9569 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	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 1R0Xv6-0002vS-3t
	for bitcoin-development@lists.sourceforge.net;
	Mon, 05 Sep 2011 12:04:56 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-vw0-f47.google.com; 
Received: from mail-vw0-f47.google.com ([209.85.212.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1R0Xv5-0007ur-8r
	for bitcoin-development@lists.sourceforge.net;
	Mon, 05 Sep 2011 12:04:56 +0000
Received: by vwe42 with SMTP id 42so5319265vwe.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 05 Sep 2011 05:04:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.112.163 with SMTP id ir3mr4007786vdb.124.1315224289777;
	Mon, 05 Sep 2011 05:04:49 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.157.228 with HTTP; Mon, 5 Sep 2011 05:04:49 -0700 (PDT)
Date: Mon, 5 Sep 2011 14:04:49 +0200
X-Google-Sender-Auth: oMK6wjCQ0yT81Lgu4scttcUcugw
Message-ID: <CANEZrP3Fh=Ffeh5PtcaL4QBKXUzkFYAar4031-wVZOVQOhngrw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: 1R0Xv5-0007ur-8r
Subject: [Bitcoin-development] Adding a pong message to the protocol
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, 05 Sep 2011 12:04:56 -0000

I haven't written a patch for this, I might do so if there's
sufficient interest.

Nodes that are under heavy load exhibit extremely high latency, this
makes downloading the block chain from a node that is itself
downloading the block chain basically useless as it takes 30-60
seconds for the node to respond to clients.

It could be fixed by making nodes not accept connections/advertise
until they feel sure they have the best chain, but a more general fix
is to add a "pong" which is returned by "ping". It could contain some
useful stats about the node for network crawlers, but most importantly
timing the delta between ping and pong would let you order nodes by
responsiveness. Currently if you want to do this, it has to be
indirect, using some message that is guarantee to yield a known
response.

Because old clients ignore messages they don't understand, adding the
pong response would be easy and backwards compatible. Making nodes
prefer responsive servers might need a bit of care to avoid sloshing
load around too much.

Thoughts?