Re: [Plib-devel] Networking Code

[Curtis L. O. <cu...@me...>]

Sam Stickland writes:
> 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?

Never heard of T/TCP myself ... I think there is a ttcp utility for
unix that helps you bench mark raw net performance but I doubt that's
the same thing.

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

First let me say I don't disagree with anything you have said here.  I
just want to fill in a little bit bigger picture.  In my mind anyway I
think there are places where both TCP and UDP type sockets are
important to have.  A more complex game/simulation might find itself
needing both at the same time (meaning multiple open connections.)

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

The flip side of this is that a simulation or game might need to send
a single packet or message that must arrive at it's destination.
Here's a couple examples:

Pretend we are syncing several displays/views over the network for a
flight sim.  The latest weather report comes in and the new visibility
for our area is 1.5 miles.  We need to notify all the views of this
change and we need to do it reliably.

My day job involves supporting and developing driving simulations.
Our simulations are composed of several pieces running on separate
machines that communicate via the network.  If the gui sends a "reset
position to x,y,z" message to the simulation engine, it had better do
it the first time.

I could bore you with many other examples ... :-)

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

Again, for certain types of "command" communication, order is actually
important.

> (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).

Now that I've finished my message I see this little add on at the
bottom of yours ... oh well ... :-)

I guess the point I'd like to still emphasize is that a network
library really needs to be able to support both TCP and UDP socket
protocols.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org