[JDEV] im unified

[Marty Saxton]

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 [mailto:tcharron at ductape.net]
> Sent: Friday, September 01, 2000 9:58 AM
> To: jdev at jabber.org; Thomas Muldowney
> Subject: Re: [JDEV] im unified
> 
> 
> Quoting Thomas Muldowney <temas at 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 at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20000901/fd70a2b4/attachment-0002.htm>