03 Sep, 2007, Guest wrote in the 1st comment:
Votes: 0
This is the discussion thread for mccp
03 Sep, 2007, KaVir wrote in the 2nd comment:
Votes: 0
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?
03 Sep, 2007, Zeno wrote in the 3rd comment:
Votes: 0
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.

This is what it looks like:
Quote
[LEVEL 60]:
aassign bestow bset bestowarea elevate
formpass hotboot immortalize instazone immhost
makewizlist rreset reserve setboot snoop
setclass scatter setweather strip s

etrace
split-form saveall users vassign wizlock

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.
03 Sep, 2007, Splork wrote in the 4th comment:
Votes: 0
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…

User protocols
————–

User |Terminal |NAWS |MCCP |MXP | MSP
————————————————————————————
Doc |zmud |102x 43| |
Mandos | | | |
Ferrum | | | |
Kynde |WINTIN.NET 2.09 |110x 31|V2(I: 200393,O: 13875,S:94%)|MXP |
Gaea | | | |
Shazuko |zmud |109x 35|V2(I: 66352,O: 10137,S:85%)|MXP | MSP
Mullah |WINTIN.NET 2.10 |148x 40|V2(I: 204767,O: 38514,S:82%)|MXP |
Aife |mushclient | 80x 46|V2(I: 303426,O: 25161,S:92%)|MXP |
Arde |cmud |138x 66|V2(I: 283483,O: 29402,S:90%)|MXP | MSP
Splork |WINTIN.NET 2.10 |125x 38|V2(I: 223976,O: 35109,S:85%)|MXP |
Akasha |zmud |153x 64|V2(I: 238862,O: 26122,S:90%)|MXP | MSP
Doink |zmud |125x 54| |
Ly |WINTIN.NET 2.04 |154x 40|V2(I: 238911,O: 35596,S:86%)|MXP |
Burock |zmud |121x 38|V2(I: 780954,O: 60467,S:93%)|MXP | MSP
Atwell |TINTIN++ | 89x 45|V2(I: 896634,O: 161824,S:82%)|
Rackot |zmud |204x 67|V2(I: 930161,O: 96487,S:90%)|MXP | MSP
Kirdox | | | |
Brand | | | |
Yinao |WINTIN.NET 2.10 |104x 40|V2(I:1985775,O: 196601,S:91%)|MXP |
Firon |ANSI | 80x 41| |
Cleruk | | | |
Autolycos |zmud | 97x 39|V2(I: 948487,O: 100948,S:90%)|MXP | MSP
Trup | | | |
Piper | | | |
Sheng |WINTIN.NET 2.10 |118x 40|V2(I:3814448,O: 340443,S:92%)|MXP |
Whiff |zmud |154x 37|V2(I:1298622,O: 130941,S:90%)|MXP | MSP
Kull |WINTIN.NET 2.03 |122x 38|V2(I:1428755,O: 149109,S:90%)|MXP |
Far |WINTIN.NET 2.10 |135x 26|V2(I:1181733,O: 114815,S:91%)|MXP |
Redneck | | | |
Shyla | | | |
Annie |WINTIN.NET 2.10 |100x 54|V2(I:2346835,O: 206253,S:92%)|MXP |
Clink |zmud |125x 51|V2(I: 121246,O: 12734,S:90%)|MXP | MSP
Gater |WINTIN.NET 2.07 | 77x 27|V2(I:5756850,O: 541070,S:91%)|MXP |
Mahkra |WINTIN.NET 2.10 |139x 41|V2(I:8900567,O: 858308,S:91%)|MXP |
Shimbo |cmud |112x 56|V2(I:3624537,O: 664994,S:82%)|MXP | MSP
Truth |WINTIN.NET 2.10 |157x 52|V2(I:12430999,O:1048888,S:92%)|MXP |
Alias |WINTIN.NET 2.10 |157x 40|V2(I:6870695,O: 605948,S:92%)|MXP |
03 Sep, 2007, Guest wrote in the 5th comment:
Votes: 0
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.
03 Sep, 2007, Zeno wrote in the 6th comment:
Votes: 0
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.
03 Sep, 2007, Conner wrote in the 7th comment:
Votes: 0
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.
03 Sep, 2007, Zeno wrote in the 8th comment:
Votes: 0
I showed Samson what I meant, he saw it.

I don't think I can test it on FUSS, there is no way to toggle MCCP on the MUD.
04 Sep, 2007, Conner wrote in the 9th comment:
Votes: 0
You have to toggle it to be able to see if large lists generate the bug for you?
04 Sep, 2007, Zeno wrote in the 10th comment:
Votes: 0
Not really, but if I can't compare MCCP to no MCCP on the same MUD it's hard to tell (some servers lag normally without MCCP).
04 Sep, 2007, Conner wrote in the 11th comment:
Votes: 0
Ah, I can see your point.. guess we need to get Remcon to write us a compress command or a config option to toggle MCCP off… :wink:
04 Sep, 2007, kiasyn wrote in the 12th comment:
Votes: 0
you could tell your client not to respond to mccp requests :)
04 Sep, 2007, Scandum wrote in the 13th comment:
Votes: 0
Zeno said:
[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.
04 Sep, 2007, Guest wrote in the 14th comment:
Votes: 0
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.
04 Sep, 2007, Scandum wrote in the 15th comment:
Votes: 0
If the codebase compresses and sends 512 bytes at a time I guess it could clog things up on the client side, especially on a slow computer / client.
04 Sep, 2007, Zeno wrote in the 16th comment:
Votes: 0
Scandum said:
Zeno said:
[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.
04 Sep, 2007, Scandum wrote in the 17th comment:
Votes: 0
Zeno said:
Want me to test it out on tintin++?

Sure, go ahead. I'm curious if it experiences the same problems given I optimized it to deal with packet fragmentation efficiently.
04 Sep, 2007, Zeno wrote in the 18th comment:
Votes: 0
Not sure if WinTin++ is fine to use.

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.
04 Sep, 2007, Zeno wrote in the 20th comment:
Votes: 0
Good point. You're far away, want to test this out? :P
0.0/27