[JDEV] UDP vs TCP
Thomas Charron
tcharron at ductape.net
Fri Sep 1 09:12:22 CDT 2000
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. ?>>
More information about the JDev
mailing list