Adding a pong message to the protocol

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?

On Mon, Sep 5, 2011 at 8:04 AM, Mike Hearn <mike@plan99•net> wrote:

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

[snip]

> Thoughts?

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.

Or more importantly— figuring some way of setting up network simulations which could be used to actually _validate_ proposed changes in this area.

I, or many other people, could spout endlessly about attractive sounding network enhancements (e.g. move-to-front peer prioritization, tweaks to peer selection, etc.) but it's all just arm waving without a way to measure it, and the real network is far too slow to upgrade (and important) to test things in situ while testnet is far too small and unlike the real network for useful testing.

> 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.