[crossfire] Protocol & compression.

[Mark Wedel]

Sebastian Andersson wrote:
> On Sat, Mar 25, 2006 at 01:00:59AM -0800, Mark Wedel wrote:
>>   For other reasons, I still think I'll add animation support to the map2 
>> command.  However, I think it also worthwhile to add something like:
>>
>> S->C: compress <data>
> 
> I've got some experience in this, having implemented it in a mud
> (DUMII) and I suggest a different approach. Have the zlib stream as a
> layer between the socket and the server/client when it is turned on
> and start it like this:

  There are a few likely differences which may or may not effect crossfire in 
different ways:

1) Some data crossfire sends is just not compressible.  The PNG data comes to 
mind - trying to compress it is at best a waste of time, and at worse, increases 
amount of data being transmitted.  The other problem related to this is you'll 
often need to send a bunch of image data at one time (player changes to new 
map), and now there is lots of data you are trying to compress - the time it 
takes to compress that much data could become significant.

2) Latency is a big concern in crossfire, so we really can't add any.  This 
means that for each and every tick, we need to make sure we send all the data we 
have - in lots of cases, this is going to be small data that doesn't compress 
well, so once again, a waste of cpu time (while this may seem trivial, there are 
  certainly times when the server does become cpu bound)

3) The fact that crossfire does queue up data would allow for compressing at a 
higher level (basically, not have send_with_handling actually send data, but 
queue it up, and then at the end of the tick, compress the data).  In that way, 
we can combine several small commands into a larger packet, but still not spend 
time compressing non compressible data.  But doing that adds a fair amount of 
complication - a complete re-write of the socket code would probably be needed 
to reasonable support that.

  while adding a 'compress' prefix (it could be shortened to just gz, so now 
only adding a few bytes), by selectively compressing the big payloads is a very 
easy mechanism to do right now without any real downsides.