[crossfire] Steam Protocol Proposal

[Alex Schultz]

Hi,

Recently, elmex and I did some tests regarding compression, we found 
that zlib stream compression is better than selective per-packet 
compression, and also better than than a "hybrid" that I thought of, 
which allows packets to selectively be part of a compressed stream. 
AFAIK, the only drawback to zlib stream compression is CPU usage (which 
shouldn't be very bad really). It's true that you don't get good 
compression on png data and such, but it seems  that the overhead of any 
sort of system to selectively decide if it should compress a packet or 
not, outweighs this in terms of bandwidth.

Also, I was thinking that partially for purposes of password exchange, 
some users may like it if the stream was encrypted. So perhaps 
supporting ssl streams might be an interesting feature.

To accommodate for such things in an expendable manner, I think it would 
be a good idea to have a protocol to have a generic protocol for 
encapsulating itself in a stream of some sort. I propose that a protocol 
such as the following be implemented (with a english translation tabbed 
to the right of what each side is "saying"):

(When the client wants the server to start sending in stream format foo, 
where foo can be something such as 'zlib', 'ssl' or 'plaintext')
C->S: req_recv_stream foo          "May you send me data in stream 
format foo?"
S->C: ack_send_stream foo          "Sure. Here, sending it in format foo 
now"
S->C: <steam in format foo>

(When the client wants to start sending the server data in stream format 
bar, where bar can be something such as 'zlib', 'ssl' or 'plaintext')
C->S: req_send_stream bar          "May I send you data in stream format 
bar?"
S->C: ack_recv_stream bar          "Yes, I can receive data in stream 
format bar."
C->S: ack_send_stream bar          "Ok, here's data in stream format bar."
C->S: <steam in format bar>

Also, requests for a stream format may in a space separated format 
specify multiple stream types, for the server to encapsulate within 
eachother (i.e. ssl encrypted zlib stream). A streamed format may be 
exited by a "req_recv_stream plaintext" or "req_send_stream plaintext". 
Also, when a format is requested that the server does not support, it 
tells the client this by sending an "ack_recv_stream <previous format>" 
or "ack_send_stream <previous format>".

Also, there is never any "ack_recv_stream" from the client, because it 
is assumed that the client requesting to receive in a format implies 
that it understands it.

Even if ssl encryption is not worth implementing, I believe that using 
this format for encapsulating the protocol in any other generic data 
stream protocol would be both clean and easily expendable. If anyone has 
any objections to or suggestions, please speak up :)

    Alex Schultz