Alex Schultz wrote: > 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.
It's hard for me to see why compressing per packet would take 50% more bandwidth, but I suppose it could be a matter of grouping those smaller packets together. I don't know the specific test methodology used, but one point is that for real life usage, the server will often need to compress small amounts of data, just so that it gets sent to the client in a timely fashion (the server can't really wait for 6 ticks to gather a good block of compressible data - it needs to send things every tick). But in any case, doing stream compression makes sense, save for the extra work needed to do it. We also had a discussion on IRC about a separate media server (for images/sounds/whatever) - if that is in fact done, that also removes some of the issue of the server compressing data it doesn't need to compress (client would grab the images from that other server where they are precompressed or not compressed, whatever) > 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. Ok - that is good. Otherwise, it does add a fair amount of complication - its not just recording which encapsulation methods are in use, but also the order of use (ssl inside of zlib is different than zlib inside of ssl). Supporting only a single stream type makes things much easier. > 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. And some point, it depends on how paranoid we are. But one consideration also is what external dependencies this puts in. For example, SSL is quite secure, but would require SSL on both server and client. It would probably also require some setup on the server side to properly create a SSL certificate - a self signed certificate could be created, but that also isn't quite as secure. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
