On 03/23/2013 11:24 AM, Jeff Garzik wrote: > On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr <l...@dashjr.org> wrote: >> On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: >>> Introducing super-nodes with thousands of connected peers can greatly help >>> here. >> >> UDP is connectionless. >> I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ > > It depends on the usage. Simply broadcasting a TX or INV to a remote > peer does not require a connection, clearly... but you probably want > to signal acceptance of those messages somehow. > > But other uses, like subscribing to a broadcast, does require some > notion of an association. > > In the rough draft, a parallel TCP connection with version/verack > sequence is required, and you may make use of it if a connection is > needed. > > But that is just one approach. A more robust, heavyweight UDP P2P > might be a hole-punching TCP alternative. It's up to the community > and results of experimentation. > > Bittorrent has evolved a full transfer protocol over UDP, to get > around firewalls and the like. >
Bittorrent uses UDP in 2 ways and for different reasons. The tracker protocol is now UDP because large trackers are under such enormous strain from short lived HTTP connections (40Gb/s) that there have been instances of upstream routers becoming overloaded from the storm of SYN, ACK and FIN messages. UDP helps solve that. The inter-peer protocol is now UDP because TCP does not play nice in the context of bufferbloat and Bittorrent needs lots of active TCP connections to work, exacerbating the problem. In this instance Bittorrent uses a full userspace TCP stack which just sends w/ UDP. +1 for experimenting with UDP, we might learn some interesting things. It's worthwhile to actually speed test UDP v. TCP because the time to send an INV on an established TCP connection with Nagle disabled may not be significantly longer than that for sending with UDP. Also +1 for experimentation with sending a small transaction instead of an INV, if INVs are not being grouped because we want the fastest possible network propagation, they are mostly overhead anyway. If b/w is more important than propagation speed then of course TCP/Nagle is the way to go. Thanks, Caleb ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
