<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0"> <TITLE>RE: [JDEV] im unified</TITLE> </HEAD> <BODY> The TCP / UDP debate raged on for quite a while on the IMPP mailing list.  The proponents of UDP in that debate were those interested in supporting IMPP on WAP devices, but the conclusion completely applies to jabber.  Long-lived TCP connections for client<->server won.  The two major arguments that won it were 1) congestion control and 2) the needed error correction is built in.  It was best summed up by John Strake: > Congestion control is not a per-protocol requirement, it's a per-Internet > requirement.  If any large amount of traffic is not using congestion control, > the entire Internet suffers.  Read RFC-896 for a description of what happens > in a network with no congestion control. [snip] > Any IP-based reliable protocol which behaves as well as TCP [for error correction] will necessarily > be as complex as TCP. > -----Original Message----- > From: Thomas Charron [<A HREF="mailto:tcharron@ductape.net">mailto:tcharron@ductape.net</A>] > Sent: Friday, September 01, 2000 9:58 AM > To: jdev@jabber.org; Thomas Muldowney > Subject: Re: [JDEV] im unified > > > Quoting Thomas Muldowney <temas@box5.net>: > > This disbelief in TCP/IP just doesn't make sense.  I'm very > aware of the > > scaling issues surrounding TCP, but moving to UDP is almost > a fundamental > > flaw > > for an IM system.  IM needs the ability to gurantee > delivery, and keep it > > real > > time.  UDP can't intrinsically give this, and therefore, in > my opinion, is > > flawed. > >   Technically, TCP doesn't provide this either.  It *LOOKS* > and *FEELS* like it > is, but it doesn't.  It merely serves as a buffer to put the > data back in the > right order, and rerequest packets when needed, and after a > given timeout, > closing the socket for one of several reasons.  This is an IP > limitation, *NOT* > a TCP vs UDP limitation.  ATM provides these capabilities.  > TCP looks and > feels, but isn't.  That's the basic counter.  Basically, if > you implement code > the keep track of packets and delivery, or the TCP stack does > it, the end > result is the same.  The catch is, if you can manage to > handle the UDP packets > better (with faster speed, and less memory) then the TCP > stack can.  In some > cases, yes, you can, in others, well, let's not talk about > them, they're > scary.  ;-P  Doing so in an efficient manner also pretty much > requires that you > also have the capabilities of an SMP based machine.  No > arguments that on a > single processor machine, TCP is a better way to go, becouse > you *WILL* run out > of resources before TCP connections.  But on a Sun Enterprise > 6500, the inverse > is true. > > >  Wehn you start writing this ability on to UDP your just creating > > a slower system, and then start to mess with that real time > nature.  The > > other > > major item of interest is that we're not even limited by > the socket count, > > in general your going to find RAM and CPU issues before you > find conn limits. > > I'd be happy to discuss scaling further, as I'm working on > scaling the > > server to 10million users. > >   See above.  To serve up 10 million users, you'd have to > anticipate in the > internet world that perhaps 5-10% of your users will be on > concurrently.  This > brings you between 500,000 - 1,000,000 simo connections.  On > a TCP, non SMP > based platform, this would require 42-84 farmed machines, > without even taking > into consideration reduncy, and having 12,000 users per machine. > >   Now, with a UDP based implementation, you could easily > scale this to 3 > Enterprise 6500's.  Base cost wise, more money will be spent > on the E 6500's, > hands down.  Based equiped, that's gonna run 300,000 - > 400,000 $$, which could > easily buy you 150 Intel Linux boxes.  The issue then becouse > support costs, > administration, repair, cool, electrical consuption, etc.  > Overall, the same > cost is used for either solution.  The only issue is, 150 > machines takes up > alot more space then 3 E6500's. > >   Basically, both sides are right.  It just depends on the > approach you take.  > Big boxes = UDP can handle more.  Many small boxes = TCP. > > --- > Thomas Charron > << Wanted: One decent sig >> > << Preferably litle used  >> > << and stored in garage.  ?>> > > _______________________________________________ > jdev mailing list > jdev@jabber.org > <A HREF="http://mailman.jabber.org/listinfo/jdev" TARGET="_blank">http://mailman.jabber.org/listinfo/jdev</A> > </BODY> </HTML>