No Subject

> > 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.  It's not hard to do; you just do it in a
> library and don't deal with it from then on.

Actually, that is not something which you have to do in your code  
either.  Most socket implementations support options to have the system  
handle things like that.
 

> > If you agrees to switch solely to UDP, I don't think I would have a
> > problem with this.
>
> I think this would be a mistake.  UDP means you have to repeat all of
> the work of transferring sequenced data; with all the chances of
> getting it wrong.  Why not just use TCP and take advantage of years
> of work?

I agree with the basic sentiments.  However, there are some performance  
advantages to UDP and the way the protocol is proposed today, it would  
not be too hard to make it robust to packet reordering i.e. as each  
packet represents not some display instructions but some true fact  
about the world to be entered into the client database, sequence ceases  
to matter very much.  There are still a few sequence dependencies in  
the proposed protocol, but if there is real interest, I'd be happy to  
get rid of them.

	Carl Edman