[crossfire] Steam Protocol Proposal

[Mark Wedel]

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).

  But in any case, doing stream compression makes sense, save for the extra work 
needed to do it.

  We also had a discussion on IRC about a separate media server (for 
images/sounds/whatever) - if that is in fact done, that also removes some of the 
issue of the server compressing data it doesn't need to compress (client would 
grab the images from that other server where they are precompressed or not 
compressed, whatever)


> Well, I was thinking of allowing layering different types of streams 
> within eachother, however now I don't really think there is a need for 
> such and hence isn't worth bothering with.

  Ok - that is good.  Otherwise, it does add a fair amount of complication - its 
not just recording which encapsulation methods are in use, but also the order of 
use (ssl inside of zlib is different than zlib inside of ssl).  Supporting only 
a single stream type makes things much easier.

> Agreed. This protocol while suitable for streams in general, isn't 
> suitable for switching to a stream for a specific purpose (i.e 
> password). At that, I'm not completely sure ssl is the best way to send 
> a password for more secure login, however if that is done, some sort of 
> per-packet would be better.

  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.