plib-devel

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Sam

I don't have any test programs wrote yet, I am trying to get some mac code
in there but I am lost. Also there are some places in the code that need to
be cleaned up, but it should work for you (I hope). 

Here is the code.
Thanks Ben

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 10:49 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code



----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 1:58 PM
Subject: [Plib-devel] Networking Code


> Hello
>
> I have started to do some work on the portability of the networking code,
> but I don't have a mac, windows or a network for that matter, I was
> wondering if someone would like to help me with this code.
>
> Some of the things I don't know? (Yes I am aware of all the comments that
> could come with that statement)
>
> I have no idea if it runs in windows
> I do know it does not run on a mac (but I am working on the code)
> I don't know how well it works on linux or bsd

I can test the windows and Linux versions - and perhaps Irix as well.

Do you have any test programs to check the code?  If not I can knock a quick
couple of programs that attempt to pass data back and
forth between them and check the validity of it.

Sam



_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hey Sam

If you write a few little test programs for it, can you send them back to
me, I would like to add them in for testing. 

Thanks Ben

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 10:49 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code



----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 1:58 PM
Subject: [Plib-devel] Networking Code


> Hello
>
> I have started to do some work on the portability of the networking code,
> but I don't have a mac, windows or a network for that matter, I was
> wondering if someone would like to help me with this code.
>
> Some of the things I don't know? (Yes I am aware of all the comments that
> could come with that statement)
>
> I have no idea if it runs in windows
> I do know it does not run on a mac (but I am working on the code)
> I don't know how well it works on linux or bsd

I can test the windows and Linux versions - and perhaps Irix as well.

Do you have any test programs to check the code?  If not I can knock a quick
couple of programs that attempt to pass data back and
forth between them and check the validity of it.

Sam



_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks, I have that, and I am trying to read through it, but I am new to c
and c++ so you can amagine how fun it is. Luckly, I have some of steves
code, that uses structures in c++ so I have been able to get passed some of
the problems but its not fun. 
Thanks for the site.
Ben

-----Original Message-----
From: Darrell Walisser [mailto:dwa...@pu...]
Sent: Tuesday, August 22, 2000 11:11 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code


Hi. Below I have some network code that was used to implement the SDL_Net
library for MacOS, using OpenTransport. I didn't write the code, but I think
it will help you a lot.

    http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_net.sit


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] Networking Code

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

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 3:15 PM
Subject: RE: [Plib-devel] Networking Code


> Thanks, I have that, and I am trying to read through it, but I am new to c
> and c++ so you can amagine how fun it is. Luckly, I have some of steves
> code, that uses structures in c++ so I have been able to get passed some of
> the problems but its not fun.
> Thanks for the site.

ACE is built upon on single core class ACE_OS, which provides a single Unix/POSIX like interface to all the standard thread and
socket calls.

This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't really studied it that much, but it might be worthwhile
having a look.

(One gottcha I should point out is that almost all the higher level ACE applications use recv and send - not read and write (these
calls are supposed to be identical), with the result that ACE_OS::read and ACE_OS::write appear to be broken under Win2000 with ACE
(This might actually be problems with WinSock under Win2K I haven't investigated)).

You could always strip ACE_OS out of ACE (shouldn't be *that* hard), and then you have a bunch of platform independant OS calls for
sockets and threads - and ACE supports a *lot* of platforms.

Sam

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

>> Thanks, I have that, and I am trying to read through it, but I am new to
c
>> and c++ so you can amagine how fun it is. Luckly, I have some of steves
>> code, that uses structures in c++ so I have been able to get passed some
of
>> the problems but its not fun.
>> Thanks for the site.
>
>ACE is built upon on single core class ACE_OS, which provides a single
Unix/POSIX like >interface to all the standard thread and
>socket calls.
>
>This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't
really studied it >that much, but it might be worthwhile
>having a look.
>
>(One gottcha I should point out is that almost all the higher level ACE
applications use >
>recv and send - not read and write (these
>calls are supposed to be identical), with the result that ACE_OS::read and
ACE_OS::write >
>appear to be broken under Win2000 with ACE
>(This might actually be problems with WinSock under Win2K I haven't
investigated)).

I did not realise that you could use recv and send and not read and write
with TCP, I think I  read somewhere that for the TCP section I should use
read and write, I really don't know if there is a difference but I will have
a look at it. 
As well I have not had much of a chance to look at winsocks so I am not
really sure what is the best way to deal with windows but I will be looking
at that. 

Thanks Ben
ps Can you send me a link to where I can find ace. I don't think I ran
across that yet.




_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] Networking Code

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

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 4:01 PM
Subject: RE: [Plib-devel] Networking Code


> >ACE is built upon on single core class ACE_OS, which provides a single
> Unix/POSIX like >interface to all the standard thread and
> >socket calls.
> >
> >This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't
> really studied it >that much, but it might be worthwhile
> >having a look.
> >
> >(One gottcha I should point out is that almost all the higher level ACE
> applications use >
> >recv and send - not read and write (these
> >calls are supposed to be identical), with the result that ACE_OS::read and
> ACE_OS::write >
> >appear to be broken under Win2000 with ACE
> >(This might actually be problems with WinSock under Win2K I haven't
> investigated)).
>
> I did not realise that you could use recv and send and not read and write
> with TCP, I think I  read somewhere that for the TCP section I should use
> read and write, I really don't know if there is a difference but I will have
> a look at it.

Yep, recv and send can be used on TCP sockets - at least I use them without problems.

> As well I have not had much of a chance to look at winsocks so I am not
> really sure what is the best way to deal with windows but I will be looking
> at that.

Well winsock is based on the BSD socket implementation, which is what most Unixes use so these really not a lot of difference so
long as you stick to the basic calls (and winsock requires some init() and fini() calls too.)  Might be that your code already
compiles fine on Win32 once the needed headers are added.  I'll test it tonight.

> Thanks Ben
> ps Can you send me a link to where I can find ace. I don't think I ran
> across that yet.

Yeah sure:

http://www.cs.wustl.edu/~schmidt/ACE.html

Sam

RE: [Plib-devel] Networking Code

[Norman V. <nh...@ca...>]

Sam Stickland writes:

>"Ben Woodhead" writes:
>
>> >ACE is built upon on single core class ACE_OS, which provides a single
>> Unix/POSIX like >interface to all the standard thread and socket calls.
>
>> Thanks Ben
>> ps Can you send me a link to where I can find ace. I don't think I ran
>> across that yet.
>
>Yeah sure:
>
>http://www.cs.wustl.edu/~schmidt/ACE.html

Last time I looked ACE was a rather large package :-(
Though itt certainly is capable of doing anything we would want.

FWIW Have you guys seen Common C++ ?
http://cplusplus.sourceforge.net/

Norman

Re: [Plib-devel] Networking Code

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

> >Yeah sure:
> >
> >http://www.cs.wustl.edu/~schmidt/ACE.html
>
> Last time I looked ACE was a rather large package :-(

Yep, ACE is a *BIG* package as I've mentioned in earlier posts.

> Though itt certainly is capable of doing anything we would want.

Yeah, it does have quite a bag of tricks in it.

> FWIW Have you guys seen Common C++ ?
> http://cplusplus.sourceforge.net/

No, I hadn't seen that before - if I'd had found before ACE I'd had probably
never started using ACE in the first place :)

Sam

RE: [Plib-devel] Networking Code

[Dave M. <Dav...@dy...>]

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.

-- Dave

Re: [Plib-devel] Networking Code

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

RE: [Plib-devel] Networking Code
  ----- Original Message -----=20
  From: Dave McClurg=20
  To: 'pli...@li...'=20
  Sent: Tuesday, August 22, 2000 4:08 PM
  Subject: RE: [Plib-devel] Networking Code


  Hi Ben,=20

  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.

Yes, that's certainly the case.  I hadn't ever really considered making =
the full network library I'm working part of plib - I wanted it to be a =
stand alone affair.  If it uses portable socket code in plib that's fine =
by me though.

I'd personally be in favour of this structure for the socket library.

TCPSocket *mysock_con                  =3D new Socket(1234); // Create a =
new socket on port 1234 on the server

TCPSocket *mysock_client_to_server =3D new Socket('spacething.org', =
1234); // Client attempts to connect to spacething.org on port 1234

TCPSocket *mysock_server_to_client =3D new Socket(mysock_con); // Server =
accepts the client connection

But that's me.  Actually one disadvantage in the above system is that =
you can't easily return errors in constructors without using exceptions =
- ugh.  Best to seperate out the constructor and initialisation code if =
you went with the above.

  Things like real-time state management or match-making systems for =
finding opponents could be placed in an auxillary library.

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

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Dave, 
 
Currently that is what I have been trying to do, just keep it simple, but I
am also trying to make sure that it runs in windows, linux, unix and mac.
And other then that just send and recieve. I am trying to keep it as simple
and general as possible. But thanks for sending it in for me, I will have a
look.
 
Later Ben

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Tuesday, August 22, 2000 12:09 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Networking Code



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.

-- Dave 

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hello Sam,
 
First I want to get everything running and portable before I start thinking
about overloaded constructors. I am trying to keep everything nice and
simple. Also I would like to hear what dave thinks of the idea. 
But I do have good news, I am slowly getting through the OpenTransport stuff
for macs, who ever said that sdl net uses Open Transport, I read the docs on
it and things are moving along alot better now. 
 
Later Ben
ps There are a few things that I don't understand, all the examples are done
in c and a few of the memcopy sections and things like that I have been
having problems with, if someone could give me a hand with thoughs sections
it would help alot. 
 

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 1:11 PM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code


 

----- Original Message ----- 
From: Dave McClurg <mailto:Dav...@dy...>  
To: 'pli...@li...'
<mailto:'pli...@li...'>  
Sent: Tuesday, August 22, 2000 4:08 PM
Subject: RE: [Plib-devel] Networking Code


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.

Yes, that's certainly the case.  I hadn't ever really considered making the
full network library I'm working part of plib - I wanted it to be a stand
alone affair.  If it uses portable socket code in plib that's fine by me
though.

I'd personally be in favour of this structure for the socket library.

TCPSocket *mysock_con                  = new Socket(1234); // Create a new
socket on port 1234 on the server

TCPSocket *mysock_client_to_server = new Socket('spacething.org', 1234); //
Client attempts to connect to spacething.org on port 1234

TCPSocket *mysock_server_to_client = new Socket(mysock_con); // Server
accepts the client connection

But that's me.  Actually one disadvantage in the above system is that you
can't easily return errors in constructors without using exceptions - ugh.
Best to seperate out the constructor and initialisation code if you went
with the above.

Things like real-time state management or match-making systems for finding
opponents could be placed in an auxillary library.

 

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

I had a look at common c++, but it is really big as well. But it may help
with the Mac code. I have some of the code finished, basicly with mac you
have to rewrite everything. OpenTransport is alot different then BSD
sockets. They even have there own variables, instead of just using int.

Later Ben

-----Original Message-----
From: Norman Vine [mailto:nh...@ca...]
Sent: Tuesday, August 22, 2000 5:26 PM
To: pli...@li...
Subject: RE: [Plib-devel] Networking Code


Sam Stickland writes:

>"Ben Woodhead" writes:
>
>> >ACE is built upon on single core class ACE_OS, which provides a single
>> Unix/POSIX like >interface to all the standard thread and socket calls.
>
>> Thanks Ben
>> ps Can you send me a link to where I can find ace. I don't think I ran
>> across that yet.
>
>Yeah sure:
>
>http://www.cs.wustl.edu/~schmidt/ACE.html

Last time I looked ACE was a rather large package :-(
Though itt certainly is capable of doing anything we would want.

FWIW Have you guys seen Common C++ ?
http://cplusplus.sourceforge.net/

Norman


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

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

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

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

Re: [Plib-devel] Networking Code

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

----- Original Message -----
From: "Curtis L. Olson" <cu...@me...>
To: <pli...@li...>
Sent: Wednesday, August 23, 2000 3:05 PM
Subject: Re: [Plib-devel] Networking Code


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

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

Heh, it happens.

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

Actually while we're on this subject I am concerned about the accuracy of my network engine over true internet links.  It's somewhat
harder to test these yourself than it is to run tests on LANs.  Are there any *cheap* (read free :), WAN simulators out there.  Or
maybe just some 30 day trial ones I can use to knock the code up into shape after I've done all the testing I can do.

All the ones I've found are commerical and way outside of my price range, for what is, essentially a hobby.

Sam

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

Re: [Plib-devel] Networking Code

[Michael K. <neg...@ea...>]

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

If a UDP packet is critical then set a flag in your packet header requesting
an ACK be sent back. This will of course mean you need to design a method of
knowing which packets you sent required an ACK, clearing ACK'd packets,
knowing which ones haven't been ACK'd yet, and resending the packet.

Obviously this should not be used to replace TCP, but in the case where you
want to send *most* of your packets to the winds and just require a few of
them to be acknowledged this should work well.

Re: [Plib-devel] Networking Code

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

Michael Kurth wrote:
> 
> > 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.
> >
> 
> If a UDP packet is critical then set a flag in your packet header requesting
> an ACK be sent back. This will of course mean you need to design a method of
> knowing which packets you sent required an ACK, clearing ACK'd packets,
> knowing which ones haven't been ACK'd yet, and resending the packet.

...coping with ACK packets that get lost - resulting in retransmitted packets
appearing twice at the destination...etc, etc, etc.  Notice that the probability
of an ACK getting lost are identical to the probability of an outgoing packet
getting lost.

...coping with an ACK that refers to a packet you already retransmitted.

...realising that packets can now arrive out of sequence (actually, that was
always possible - even with UDP).

There are a lot of nasty little traps you can fall into.

I think that in the end, you are just better off using TCP where it's needed
and UDP when it isn't.  I believe that's what Quake does.

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

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Sam,

I will have a look

Cheers, Ben

> -----Original Message-----
> From: Sam Stickland [mailto:sa...@sp...]
> Sent: Wednesday, August 23, 2000 10:42 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Networking Code
> 
> 
> 
> ----- 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
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Networking Code

[Darrell W. <dwa...@pu...>]

Hi. Below I have some network code that was used to implement the SDL_Net
library for MacOS, using OpenTransport. I didn't write the code, but I think
it will help you a lot.

    http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_net.sit