No Subject

>     Philip Brown <philb@soda.berkeley.edu> writes:
>     > [ largest amount of changes when lots of monsters ]
>     > 

>     > If they are getting updated here and there, let's say 10 pieces
>     > of information in one packet, with tcp packet overhead, that
>     > generates a hell of a lot of overhead.
>     

>     THe easiest way to deal with this is to batch up each of the
>     packets which you conceptually send to the client.  Instead of
>     sending a separate tcp packet for each update, you just keep
>     putting data in a buffer, and when the server finishes processing
>     a turn, it flushes all of the connections.
> 

> Exactly. Except Carl said he is firmly against the idea of "turns".
> Go figure.

I'm so happy to see that my words are taken as gospel now even in  
partibus infidelium. :-)  What I think Eric means is not turns in any  
game mechanical sense, but rather that a clever algorithm will not send  
all data it is handled immediately but will wait a little to see if it  
gets more data quickly so that it can make a larger packet.   
Fortunately most of the smarts you need already are in all good TCP/IP  
implementations.

> [ A few accurate points deleted ]

> So when calculating required bandwidth to sustain a fast game with
> TCP, you've also got to allow packet acknowledgement for TCP. This is
> what makes for bad net lag (as opposed to just "mild" net lag with
> udp ;-)

That I think is misleading.  The really slow connections (which is  
those we need to worry about -- any reasonable protocol will do well on  
even medium speed connections) are all full duplex (like modem links or  
57.6 kbps leased lines).  Sending acknowledgments on the back channel  
doesn't subtract any bandwidth on the forward channel.

	Carl Edman