Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R0aE6-00032a-H5 for bitcoin-development@lists.sourceforge.net; Mon, 05 Sep 2011 14:32:42 +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 1R0aE5-0006OB-PQ for bitcoin-development@lists.sourceforge.net; Mon, 05 Sep 2011 14:32:42 +0000 Received: by vwe42 with SMTP id 42so5457453vwe.34 for ; Mon, 05 Sep 2011 07:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.106 with SMTP id hb10mr459803vdb.459.1315233156313; Mon, 05 Sep 2011 07:32:36 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.52.157.228 with HTTP; Mon, 5 Sep 2011 07:32:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 16:32:36 +0200 X-Google-Sender-Auth: 6Z_S9Gow0MLN55ILmhT5oPqebT0 Message-ID: From: Mike Hearn To: Gregory Maxwell 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: 1R0aE5-0006OB-PQ Cc: Bitcoin Dev Subject: Re: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 14:32:42 -0000 > I'd rather see effort spent on the root issues, e.g. having nodes > gauge their own suitability (working inbound port, reasonably current > block chain, etc) before becoming advertised listeners. They can't always judge it, eg if the link between you and that peer is saturated then you may have connectivity, but it may be very slow yet appear fast to the node itself. This really has two parts: (1) Making it easy to determine latency (2) Using that data to make better connection decisions Adding a pong message is fairly trivial and can help solve (1). For instance we can start building latency histograms of nodes to see how performant the network is, without risking any issues. Then that data can be used to inform simulations of what happens if the measurements are used by the node software. It also lets us experiment with less critical software like Android clients.