[crossfire] Protocol & compression.

[Alex Schultz]

Mark Wedel wrote:

>Alex Schultz wrote:
>  
>
>>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.
>>    
>>
><snip>
>
>  However, if we were going to go down the idea of adapting what the server does 
>base on available time, there are lots of other things.  Don't swap out maps if 
>busy.  Put off for a few ticks the routine stuff (in do_specials()).  But that  
>also starts getting more complicated - some players may not care much about 
>compression but don't mind using it to help reduce server bandwidth, etc.  Yet 
>others on low bandwidth connections really want that compression - this could 
>lead to things like clients saying how badly they want compression.  Not sure if 
>that complication is worth it.
>  
>
Hmm, this is true. However in my opinion, it shouldn't really be that 
difficult to make a few things like that adaptive to server conditions.

>  The other problem I think with that approach is that the bigger the packet, 
>the longer it takes to compress.
>  
>
True, but the bigger packets are more important/worthwhile to compress, 
and if threshold is moved up, there are fewer packets that will be 
compressed, causing somewhat of a reduction in compression time. Perhaps 
if the server is really lagging behind, the threshold would become high 
enough that it wouldn't compress at all.

>  but the biggest issue is this scenario - player changes maps - loading this 
>new map takes time, so server is now short on time.  Yet because player is 
>changing maps, a lot of map data is changing, so that is the packet you want to 
>compress.
>
Hmm, that is also quite true, however I don't think that problem is 
unsolvable. For example, if the average time/tick of the most recent 10 
ticks is used instead of just the most recent tick, it might not cause 
that to happen so much, and things that cause a more constant system 
load would still make fewer things get compressed. Also, because such a 
packet would be rather large, if it is just the threshold of what to 
compress changing, it could still very well compress if it's a rather 
large one. It might also be possible to measure time used by I/O 
operations and exempt it, however I believe that is overcomplicated.

Yes, some of the 'best' ways of doing this plan are a bit 
overcomplicated, but I do believe that a simple form could still be 
effective.

Alex Schultz