[crossfire] Steam Protocol Proposal

[Mark Wedel]

  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.

  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.

  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).  Unless you use the SSL stream all the time (enter it 
once, and never exit it), I think you'd be better off with finding out if the 
server can handle SSL at start up via the setup command, and then doing stuff like:

C->S:  ssldata <datablock>

  In fact, given the latency involved in switch modes, you really don't want to 
switch very often.  On the S->C side, not a big deal, as once the server 
receives the request from the client, it can switch to that mode.  But on the 
C->S side of things, if it really wants to send that next packet in SSL mode 
because it has a password, it really can't send anything else to the server 
until the mode is negotiated (the server I don't believe would be happen to 
receive an apply command while it is waiting for a password).

  However, that last problem can be solved somewhat by another patch/suggestion 
I believe which would send the command and password at the same time.