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