I tried using it for a short while (after a player with a slow connection requested it), but ended up removing it because of stability issues (the problems weren't actually caused by the MCCP, but it seemed to increase the frequency of crashes, and I wasn't able to pinpoint the actual problem until much later).
Never got around to putting it back, mostly because I pay for cpu and memory usage and not for bandwidth. If I ever move to a dedicated machine I'll activate it again. I'm guessing most of the muds using it pay for bandwidth?
I don't plan on using it. I don't like what it does.
For example: When MCCP on, I type wizhelp (a long list) and it'll freeze in the middle of displaying it (I assume because it's so much data). I have to hit enter to force it to continue. And no, I didn't have pager on.
You can see where it froze and I had to hit enter. And why I don't like it. [EDIT] Okay, so it doesn't freeze there forever. But it stops there for 16 seconds.
We implemented it because at least half of our players are from overseas and they pay for their bandwidth. We also try to add everything Wintin.NET has because its' author is one of our creators and coders.
Here is a small command I wrote up to keep track of all the protocols, clients, and savings for stuff such as mccp…
I use the protocol obviously as two of the entries in the article are mine :P
I've never seen a problem like the one Zeno describes. If the client matters, I use SimpleMU. I've done the wizhelp output, as well as rapid movement on our overland code. The overland being particularly intensive. Never once has the output frozen in place or corrupted itself.
I've tested my problem out a bit. It's not a client problem (it happens in both MUSHclient and SimpleMU). I tested it on another MUD, and while it wasn't 16seconds (I wasn't using wizhelp either though) I still noticed the freeze.
[EDIT] More debugging. Counting the bytes, this freeze happens after certain intervals of 1024 bytes.
This is probably just a combination of the codebase and how packeting sending is coded though.
I've never seen that problem that Zeno posted either, and I use gMUDix as my client and support MCCP2 on my mud. (both of which have now been added to the article :tongue:)
[EDIT] In fact, Zeno, you should be able to test this problem on the Building School since it's using an essentially stock SmaugFUSS which supports MCCP2.
[EDIT] More debugging. Counting the bytes, this freeze happens after certain intervals of 1024 bytes.
I'm curious if tintin++ is affected given I added some optimizations at the socket level, though it could be a bug in the way the codebase deals with mccp and the mud simply doesn't send out the data in a timely fashion.
From what Zeno was showing me I think the problem is more on the codebase end. He was getting chunks of 4096 bytes each, which is exactly how much data AFKMud sends out at each interval when the buffer fills up. The delay isn't terribly long, less than a second, but it is noticeable for him. I only saw a couple of VERY short "jerks" on one of the command outputs.
The problem may be more pronounced in unmodified bases that only send out 512 byte chunks when the buffers are full.
[EDIT] More debugging. Counting the bytes, this freeze happens after certain intervals of 1024 bytes.
I'm curious if tintin++ is affected given I added some optimizations at the socket level, though it could be a bug in the way the codebase deals with mccp and the mud simply doesn't send out the data in a timely fashion.
Want me to test it out on tintin++?
Samson said:
From what Zeno was showing me I think the problem is more on the codebase end. He was getting chunks of 4096 bytes each, which is exactly how much data AFKMud sends out at each interval when the buffer fills up. The delay isn't terribly long, less than a second, but it is noticeable for him. I only saw a couple of VERY short "jerks" on one of the command outputs.
The problem may be more pronounced in unmodified bases that only send out 512 byte chunks when the buffers are full.
Yep, on AFKMUD you could notice it but it wouldn't be a problem I would care about. The MUD I was originally testing it on had a 16sec delay, ouch.
But I tested it out. It still happens, and it seems to be worse. Instead of a 16sec delay like "normal", the delay lasts about 42sec. Another strange thing is that it stops at a different place.
As for on AFKMUD, I don't notice much of a difference. The delay is still there, but it doesn't seem to be any longer.
Note that this entire problem is not just me. I had a friend on another computer 30mi away test it. He gets the same thing. So it's not my network.
04 Sep, 2007, David Haley wrote in the 19th comment:
Votes: 0
Zeno said:
I had a friend on another computer 30mi away test it. He gets the same thing. So it's not my network.
That doesn't necessarily mean that it's not your network. You could still be on the same ISP subnet, for instance, depending on where you live (i.e. how dense the network is). If you had different ISPs, that would be more of a reason to think it's not the network.