RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Sam,

I will have a look

Cheers, Ben

> -----Original Message-----
> From: Sam Stickland [mailto:sa...@sp...]
> Sent: Wednesday, August 23, 2000 10:42 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Networking Code
> 
> 
> 
> ----- Original Message -----
> From: "Ben Woodhead" <be...@bg...>
> To: <pli...@li...>
> Sent: Wednesday, August 23, 2000 12:01 PM
> Subject: RE: [Plib-devel] Networking Code
> 
> 
> > Ya, I am going to try to implement a version of T/TCP, 
> which is basicly a
> > connection based protocal like TCP except there is alot less error
> > correction, I think this should be perfect for games. (I am slowly
> > understanding what this networking stuff is)
> 
> You should have a look at this article on gamasutra:
> 
> The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
> http://www.gamasutra.com/features/19990903/lincroft_01.htm
> 
> It explains how, somewhat surprisingly (to me at least) the 
> programming team made the mistake of starting with TCP/IP. In the end
> they had to recode it all to use UDP/IP.
> 
> I haven't looked into T/TCP at all - how widely supported is it now?
> 
> As regards the difference between TCP and UDP, *everything* 
> that makes TCP great for file transfer makes it rubbish for streaming
> media and real-time games.  (And vice-versa UDP is great for 
> streaming makes it's rubbish for file transfer).
> 
> Three major issues spring to mind that make TCP unsuitable.
> 
> 1) Every packet is always *guaranteed* to arrive.  This is 
> especially bad for real-time games.  This means that if a 
> packet failed
> to get through it will keep sending it until it does.  I.e..  
> the lost packet that was sent *ages* ago about where a robot was will
> keep being sent until it arrives, by which time it is 
> hopelessly out of date.  Under UDP if a packet doesn't make 
> it through you can
> send a more up-to-date version rather than constantly sending 
> the old packet again and again.
> 
> 2) Since it's stream orientated packets have to arrive in 
> order - this makes issue 1) even worse.  Imagine the 
> following example in
> which "packet" B has trouble arriving.
> 
>     Packet A
> Big bad BSOD moves to 10, 12
> 
>     Packet B                    <---- (This one gets lost and has
> Big bad BSOD moves to 10, 14    <----  to be sent several times)
> 
>     Packet C
> Big bad BSOD moves to 10, 16
> 
>     Packet D
> Big bad BSOD shoots
> 
> Now, you can't even *see* the information in Packets C & D 
> until B has been successfully received - even though Packet C makes it
> completely superfluous.  If you were using UDP you could say, 
> Packet B didn't arrive - so what?  And just get on with it.
> 
> 3) If TCP/IP has trouble sending data it actually sends 
> *less* data.  That's right *less* data.  The idea is that 
> more data will
> make the current data congestion worse.  So when there's net 
> congestion everybody deliberately sends less until the problem passes.
> Great(ish) for file-transfer - absolutely horrid for games.
> 
> Issue 3) affects bandwidth, which is becoming less of an 
> issue as time marching on.  But 1) & 2) are latency issues - 
> and that's
> going to be with us for a long long time.
> 
> There's also all the extra associated latency in processing 
> (TCP/IP batches requests) and wasted bandwidth (in header blocks) with
> TCP/IP but these are minor issues concerned to the others.
> 
> Not having studied T/TCP I don't know how many of these 
> issues it addresses, but I suspect while latency still 
> plagues us only UDP
> will truly cut it.
> 
> (In reality certain parts of the game might will want to use 
> TCP, where data integrity is essential - score updates, and initial
> logins for example).
> 
> Sam
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>