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

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Reply via email to