Re: [Plib-devel] Networking Code

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

> Dave McClurg wrote:
> 
> Hi Ben,
> 
> In adding networking code to plib, I recommend keeping it simple like the code you showed me from tuxkart.  We just need a portable way to setup a connection.  The application code should be responsible for the rest.
> 
> A turn based game doesn't need dead-reckoning so setPos() probably doesn't belong in plib proper.  Things like real-time state management or match-making systems for finding opponents could be placed in an auxillary library.

IMHO, the important thing with networking code is to implement it in layers.

 * The basic OS socket library is the lowest level - but it's not 100% portable.

 * So we build a simple (but portable) wrapper class on top of it that doesn't
   attempt to extend functionality - but DOES perhaps hide irrelevent details
   and restrict you to the lowest common denominator of the lower levels.

 * Then you can get into higher level stuff like timing, dead-reckoning, extrapolation,
   finding opponents, etc.

But under no circumstances should you tangle those three layers.

So, the API I have in TuxKart (which DOES work under Linux and other UNIXen BTW)
is OK as the middle layer.  It needs to be ported to other OS's - and you could
perhaps argue a need for an error-tolerant version - either using TCP instead
of UDP - or based on some higher level protocols built on top of UDP.

Most 'real' games can run on UDP-only if they are running over a local network
(UDP *never* goes wrong on a correctly configured LAN) - but over the Internet,
you'll definitely get into trouble if you rely on UDP for critical messages.

On the other hand, error-tolerant protocols are slow and expensive - so you
certainly don't want to use them for things like "Where is Tux's Kart this
frame" type of messages.  Fortunately, those kinds of messages can generally
be 'lost' and nothing fatal will go wrong.

Hence, real games over the Internet will need *BOTH* UDP *AND* either TCP or
"UDP-with-an-error-correcting-layer".  So our 'middle' layer had
better support both options and know how to mix them in one program.

For high speed comms over an Ethernet LAN, other considerations are important -
you'll need to take care of collisions between two or more machines trying
to talk at once - that can do bad things to performance.  I'm not sure we
should go to the lengths necessary to fix that - it's getting a bit more into
the structure of the game than I'd want to venture.

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