[crossfire] Steam Protocol Proposal
alex_sch at telus.net
Mon May 8 07:43:20 CDT 2006
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.
More information about the crossfire