[JDEV] UDP vs TCP

[Thomas Charron]

Quoting mark at mjwilcox.com:
> TCP can scale very well, thank you very much. In particular once 
> we start using select and asynch IO on the socket level (which I 
> think jabberd, the next version of Jabber does & it's coming out 
> soon), this will enable a single server to handle an enormous 
> amount of connections.

  TCP can scale well, no arguments there.  Taking a devils advocate approach, 
though, UDP can scale 'easier' then TCP.  No matter what you do, 32,000 and 
change open TCP socket connections is all you're gonna be able to pump at a 
machine.  UDP, on the other hand, is limited really only be processor time.  
I've seen UDP based implementations that can handle up to 100,000 UDP 
connections easily.  There is a downside of UDP, though.  UDP requires much 
more processing time be spent recreating the packets, ensuring sequencial 
delivery, etc.  All of the stuff that that TCP takes care of.  Now, the kernel 
does a good deal of this processing with TCP, however, I've never seen an 
example of a UDP app that can use *less* processor slice taking care of 
sequencial delivery, etc then the kernel does..

  There is also the downturn that even though you can make 32k connections, the 
kernel allocates a hefty sum of memory for each of these connected sockets..

> If that's not enough, jabberd will be able to be server farmed.

  A solution.  Possibly more expensive then UDP, but is a proven solution..

> IM doesn't fall into either one of those categories. You do need to 
> make sure that all of the packets got there and in the proper order. 
> While you could indeed add this capability to your IM application, 
> in the end, you'll just end up re-implementing TCP and probably 
> poorly.

  Not exactly true.  You don't need a full implementation of TCP.  You need a 
partial implementation that is customized specifically twards your protocol.  
Implementing a statefull, logical 'connection' isn't as hard via UDP.  On the 
other side, doing so requires more memory and processing time.  If this takes 
more or less then the overhead of using TCP is an argument that we can persue 
for days..  ;-P  Either way works..

> Also there's no gurantee of the sequence of packets sent via UDP, 
> you have a very hard time implementing standard security 
> mechanisms such as SSL.

  You can hijack SSL by not actually using a socket for the incoming and 
outgoing packets, but a buffer, which you then feed into your UDP layer.  Yes, 
it's a hack, but a way, none-the-less.. ;-P

> That's why most people stick to TCP instead of UDP. If UDP 
> provided more bang for the buck, it would be used. But it doesn't 
> so, we stick with TCP.

  I tend to believe that most people stick with TCP becouse it's simply EASIER 
to implement then UDP.

> I"m not saying you shouldn't try your system. It might be useful for 
> local IM where the network is a lot more reliable than over the 
> general Internet.

  This actually hits the point I was going to say earlier.

  IF someones interested in it, test an implementation!  This is an Open Source 
project.  Submit patches, and try it out!  Heck, even if it's not 100% working, 
it'd be a nice 'proof of concept', for others to go off of.  I believe that if 
implemented, it could work as well as TCP based, but capable of scaling to a 
larger machine (taking into consideration the eventual migration *away* from 
libpth, which is a major limiting factor to running on larger scale machines).

--- 
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used  >>
<< and stored in garage.  ?>>