> 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
