Re: client/server once again

["Rupert G. Goldie" <rgg@aaii.oz.au>]

> I see three ways of dealing with this:
> - Use Ketjil's character update packet, but with a bit mask for the stats
>   instead of a number.  The server could the send several stats updates in a
>   single packet.
> - Use "block transfer" techniques: several map/stats/animations updates may
>   be chained in a single block, together with the "go ahead" signal, which
>   will be sent in a single "send" or "write" call.
> - Use a special packet for position updates (both X and Y).
> 
> My preference goes to the second technique: this will be more efficient in
> terms of network traffic.

Given the overhead of the underlying network protocols, and the need for rapid
interactive response, I think we have no alternative but to send updates as
blocks. With TCP/IP you're looking at a 40 byte overhead _per_packet_ (see 
"Internetworking with TCP/IP" p 141) so you might as well throw in plenty of
data bytes as well. To get the interactive repsonse you have to tell the OS not
to packetize the data itself with setsockopt and TCP_NODELAY. One other thing to
consider is the time it takes to assemble and disassemble a packet. If we use 
fixed size packets with a set structure it can be much faster than variable 
length with a free-form structure, but the difference in cost may just be noise
compared to other things.

> Well, maybe you're right.  But computing the LOS eats a fair amount of
> processing power in the server.  This is not a problem if there are only a few
> clients on one server, but what will happen if there are 50 players in the
> same game?  But I don't like precompiled clients either...
> 
> -Raphael
> 

I suspect there are plenty of optimisations we can make to Crossfire to speed it
up. At some stage someone has to sit down with a profiler (anyone have Quantify 
?) and see where the slow bits are.


Rupert