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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
