RE: [Plib-devel] Networking Code
Brought to you by:
sjbaker
Menu
▾
▴
RE: [Plib-devel] Networking Code
|
From: Ben W. <be...@bg...> - 2000-08-23 11:00:43
|
> -----Original Message----- > From: Steve Baker [mailto:sjb...@ai...] > Sent: Wednesday, August 23, 2000 12:36 AM > To: pli...@li... > Subject: Re: [Plib-devel] Networking Code > > > > 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. I don't think I have 3 layers, meaning that the UDP socket layer from tux kart is how I have been implementing everything. Althought I have not gotten into any extra functionality, so I will keep that in mind for that. > 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 - Ya I am porting it to Mac as we speak, and someone said that winsocks is really close to bsd socks so I don't think that will take alot of work. (Mind you I said that about Mac until I found out they have Open Transport) > 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. I have already completed a TCP version of your code, that should work on linux and other unixs (not been tested yet, although someone is working on it), > > 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. 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) > 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. > I have no idea, when I get this stuff finished, I will look into this. > -- > 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 > > > > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel Later Ben |
