[crossfire] Steam Protocol Proposal

[Alex Schultz]

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.

>  A quick question is - are multiple simultaneous stream types supported?  For 
>example, suppose I'm using zlib stream all the time.  But for passwords, SSL is 
>used.  Does that mean the SSL data is encapsulated in the zlib stream, or does 
>it mean that the zlib stream ends, and the ssl stream starts, ssl stream ends, 
>then zlib restarts?
>
>  I'm personally thinking that it is much easier to only support a single stream 
>at a time.
>  
>
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.

>  I actually don't think the mechanism proposed would work really good for SSL 
>and password data - this is because of the latency involved in the negotiating 
>the stream type (client has to wait for the server to respond that it is OK to 
>send SSL data before it can actually do so, which means the round trip time from 
>the server to client).
>
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.

Alex Schultz