[crossfire] Steam Protocol Proposal

[Alex Schultz]

Mark Wedel wrote:

>Alex Schultz wrote:
>  
>
>>Mark Wedel wrote:
>>
>>    
>>
>>> Some general quick thoughts:
>>>
>>> As stated before, selective 'per packet' compression has the nice advantage 
>>>very easy to do - no need for extra buffers on the client or server side needed.
>>>That said, if someone is willing to write that extra code, sounds good to me.
>>>
>>>      
>>>
>>It is simpler to do selective 'per packet', however given some tests I 
>>did, it can easily take up to 50% more bandwidth, so I think for 
>>compression that streams are the way to go.
>>    
>>
>
>  It's hard for me to see why compressing per packet would take 50% more 
>bandwidth, but I suppose it could be a matter of grouping those smaller packets 
>together.
>
>  I don't know the specific test methodology used, but one point is that for 
>real life usage, the server will often need to compress small amounts of data, 
>just so that it gets sent to the client in a timely fashion (the server can't 
>really wait for 6 ticks to gather a good block of compressible data - it needs 
>to send things every tick).
>  
>
The testing was done by using my pylibcfclient library that is in 
development, and putting hooks in for compressing received and sent data 
with various methods (per-packet streamed (like per packet, but data 
payload of a special stream packet is part of a stream), and streamed) 
and totaling up the data sent and received in each mode.
Also, I set the compression streams to flush each packet, so smaller 
packets weren't being grouped together or anything.

>  And some point, it depends on how paranoid we are.  But one consideration also 
>is what external dependencies this puts in.  For example, SSL is quite secure, 
>but would require SSL on both server and client.  It would probably also require 
>some setup on the server side to properly create a SSL certificate - a self 
>signed certificate could be created, but that also isn't quite as secure.
>
Well, the insecurity of self signed certificates is only a factor for 
authenticating that it is who it is. However it is still perfectly 
secure for, verifying it's the same client or server as before (though 
you can't be sure of it's identity other than as "same as before"), as 
well as providing secure encryption.

Alex Schultz