Mark Wedel wrote: >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). > > The testing was done by using my pylibcfclient library that is in development, and putting hooks in for compressing received and sent data with various methods (per-packet streamed (like per packet, but data payload of a special stream packet is part of a stream), and streamed) and totaling up the data sent and received in each mode. Also, I set the compression streams to flush each packet, so smaller packets weren't being grouped together or anything.
> 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. > Well, the insecurity of self signed certificates is only a factor for authenticating that it is who it is. However it is still perfectly secure for, verifying it's the same client or server as before (though you can't be sure of it's identity other than as "same as before"), as well as providing secure encryption. Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
