Re: [Plib-devel] Networking Code

[Steve B. <sjb...@ai...>]

Sam Stickland wrote:
> 
> ----- Original Message -----
> From: "Ben Woodhead" <be...@bg...>
> To: <pli...@li...>
> Sent: Wednesday, August 23, 2000 12:01 PM

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

Well, it depends on what you want.

Take a game like Doom.

Every frame you need to say where the player is - and reply from the server where
all the monsters are.  UDP is great here - if the message get's lost - who cares?
Just wait for the next one.

On the other hand, of you killed a monster - and *that* message got lost then it *is*
a disaster.  To some extent, we don't mind *so* much if the message takes a long time
to get there - but it REALLY MUST get there!

You could get around that by sending the 'live/dead' flag for every monster every
frame - but you'd also need to say which doors were open, how much ammo you have
left, etc, etc.  The amount of data you have to send every frame becomes unacceptable.

So, you NEED a TCP-like protocol where every packet it GUARANTEED to arrive for sending
"one-shot" messages - AND a UDP-like protocol where time-critical - but often-repeated
messages may or may not make it.
 
> 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.

...except in the cases I describe above - where TCP is *exactly* what you want.
 
> 2) Since it's stream orientated packets have to arrive in order - this makes issue 1) even worse.

...well, again, the order of arrival is critical for *some* things. If you open the door and THEN
fire, you kill the monster - if you do it the other way around, you blow a hole in the door.

*SOMETIMES* re-ordering the packages into the correct sequence is *good*.

You can work around this by layering your own TCP-like handshake on top of UDP if you don't
want to open two message streams for some reason.  Just bear in mind though that lots of
people are working on optimising their servers, routers, gateways & firewalls to make
TCP work well - nobody but you is working on making your protocol work faster.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net