* [Bitcoin-development] Adding a pong message to the protocol
@ 2011-09-05 12:04 Mike Hearn
2011-09-05 13:30 ` Gregory Maxwell
0 siblings, 1 reply; 3+ messages in thread
From: Mike Hearn @ 2011-09-05 12:04 UTC (permalink / raw)
To: Bitcoin Dev
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Adding a pong message to the protocol
2011-09-05 12:04 [Bitcoin-development] Adding a pong message to the protocol Mike Hearn
@ 2011-09-05 13:30 ` Gregory Maxwell
2011-09-05 14:32 ` Mike Hearn
0 siblings, 1 reply; 3+ messages in thread
From: Gregory Maxwell @ 2011-09-05 13:30 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Adding a pong message to the protocol
2011-09-05 13:30 ` Gregory Maxwell
@ 2011-09-05 14:32 ` Mike Hearn
0 siblings, 0 replies; 3+ messages in thread
From: Mike Hearn @ 2011-09-05 14:32 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-09-05 14:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-05 12:04 [Bitcoin-development] Adding a pong message to the protocol Mike Hearn
2011-09-05 13:30 ` Gregory Maxwell
2011-09-05 14:32 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox