Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- 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