[crossfire] Protocol & compression.

[Alex Schultz]

Mark Wedel wrote:

>  General notes - small map packets are not worth compressing.  The cut off to 
>be worth while is probably around 200 bytes.
>  
>
One note, usually, map packets are larger than that unless they are 
animation ones.

><snip>
>  Note that 1000 µsec = 1 ms, and by default, there is 120 ms/game tick.  So 
>spending a few milliseconds on compression doesn't seem to likely add much to 
>the load (get enough players it adds up, but then so does the overall bandwidth 
>compression).
>  
>
Perhaps system load could be measured in determining what threshold of 
what packet size should be before it is compressed, with a hard minimum 
size set as well (so, if the system load gets high, only compress the 
REALLY big packets, which should be rarer). This isn't the simplest to 
implement, but perhaps if reading the system load directly doesn't work 
well, perhaps measuring how close the ticks are to actually hitting 120 
ms/game tick, and if they start taking too long, then scale the 
compression to back to be used on fewer packets.
Neither of these methods is the easiest ways to do it, but IMHO it would 
be the 'smartest' way to do it.

>  I'm personally think zlib is better in this case, as it is faster, and for big 
>data, is smaller, and the interface is simpler.
>  
>
Agreed.

>  For other reasons, I still think I'll add animation support to the map2 
>command.
>
Also note, one thing that would be interesting, would be how much the 
map2 command differs, in terms of how well it will compress.

>However, I think it also worthwhile to add something like:
>
>S->C: compress <data>
>
>  Where data is the block of compressed data.  The length of data can be 
>determined from the packet header (a shorter command, like comp or something 
>could be done).
>
>  <data> would get uncompressed on the client, and just contain normal protocol 
>commands that the client then processes.  By abstracting at a higher level, it 
>allows us to compress any other protocol commands (think itemcmd for a large 
>inventory.  Or it would involve more work, but a long list of drawinfos, like 
>from a shop listing).
>  
>
This makes sense to me. Perhaps the server should compress automatically 
for ALL packet types where the packet is big enough unless:
1) Otherwise flagged (png data)
2) Server load is becoming too high (perhaps measure by measuring the 
actual number of ms between ticks).

Alex Schultz