On Sun, 2010-11-28 at 01:38 +0700, Jirtme Prudent wrote:

Hi!

Sorry for the off topic (and the stupidity of the question), but could you briefly explain me what's wrong with the use of UDP?

Thanks!

HTTP is not specified as a UDP protocol and extant browsers don't generally speak UDP. Aside from that, most of the things transmitted by HTTP (coded webpages, client-side programs, and compressed graphics) are prone to catastrophic failure from small errors, and UDP is prone to small errors. UDP does not contain any provision for correction of transmission errors. When a packet is transmitted over the internet, there is a chance that it will be corrupted en route. Electrical noise at a switch, a radio station too near a cable, cosmic rays, etc... these are all things which can cause a bit or byte or word to be different at the recieving end than it was at the transmitting end. TCP/IP is an error-correcting protocol that uses incremental checksums to detect transmission errors, so that the recieving end can say, "wait a minute, could you resend packet number 12?" or something when it realizes that it missed something or got a bad copy of something. This is a good thing because it reduces or eliminates errors, but it introduces roundtrip delays as the sender and receiver negotiate to make sure all the checksums and so on are correct. HTTP is a TCP/IP protocol that introduces several other mechanisms to try to deal with its intensive usage of bandwidth, and one of these was (is) "slow-start." "slow-start" says you don't transmit more than 4 packets before the receiver notifies you about whether the first one was received intact. After the receiver has acknolwedged the first 4 packets, you can assume that it's okay to have 5 packets "in flight" out there. After the receiver has acknowledged the next 5 packets, you can assume that it's okay to have 6 packets "in flight" out there. And so on. This whole thing was an effort not to overrun buffers along the way, not to transmit faster than the receiver could buffer and process the data, and so on. Slow-start was a good thing when it was developed, because at the time network latency was usually a small fraction of transmission time. Waiting for the acknowledgement to arrive usually didn't noticeably delay the transmission of additional packets. But things have changed. The bandwidth of our pipes, the size of our buffers, and the speed of our transmission has gone way up, switching speeds have gone up but have not kept pace, the number of hops on the trip from transmitter to receiver is now one or two jumps longer which eats the gains from faster switching times, and the speed of light has remained obnoxiously constant. So at this point the servers are sending four packets, then twiddling their thumbs for a *LONG* time (relative to the time it takes to transmit them) before the acknowledgement packet gets back and they can send the next packets. Google wants to change slow-start by increasing the initial number of packets to compensate for the increases in buffering capability and pipe length relative to transmission speed. I think this is probably a good idea. Bear _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE