05 Feb, 2009, Lobotomy wrote in the 1st comment:
Votes: 0
As I near the end of the current rewrite of my codebase's socket code, I've ultimately opted to leave MCCP support in; fixing it up a little as best I can, although I'm wary to tamper with that particular bit of code. However, after reading this article on Mudbytes I'm thinking I'd like to tweak MCCP to use smaller buffer sizes per socket. The question is, though, how low can it go and still work reasonably/at all? Towards the end of the article mention is made of using deflateInit2 to change the default buffer size per connection from 256k to 128k. Optimally, I'd like to reduce the size of the buffer further; assuming that there are little to no negative reprocussions for doing so (different compression rate, perhaps?).

Aside from that, I'm also looking for input on any other sort of tweaks and enhancements (if any) that can be done with MCCP to make it perform better.

Side note: The codebase I'm working with is a small, custom codebase that is derived from C Socketmud and as such gets its MCCP code from there. If anyone has suggestions for sources of better MCCP implementations (in C) that might be better to use instead of the default code I'm open to hearing about them as well.

:thinking:
05 Feb, 2009, Scandum wrote in the 2nd comment:
Votes: 0
My codebase uses: if (deflateInit2(stream, Z_BEST_COMPRESSION, Z_DEFLATED, 12, 5, Z_DEFAULT_STRATEGY) != Z_OK) which is 32K and works just fine.

Also, instead of using a separate buffer for each description to write compressed data to, you can use one central buffer:

descriptor->mccp->next_out = generic_mccp_buf;

if (deflate(d->mccp, Z_SYNC_FLUSH) == Z_OK)
{
length = MCCP_BUF_LEN - descriptor->mccp->avail_out;
write(descriptor->socket, generic_mccp_buf, length);
}


Another improvement is only supporting MCCP2, it'll make the code less cluttered and all clients support it.
06 Feb, 2009, Lobotomy wrote in the 3rd comment:
Votes: 0
Thanks, Scandum. That helped a lot. :smile:
0.0/3