Zugg Software :: View topic

Wizard Joined: 14 Oct 2000 Posts: 1368

Reported at http://forums.zuggsoft.com/forums/viewtopic.php?t=33410

Posted: Mon May 18, 2009 1:10 am

Hmm, i'm Having similar problem on a different mud when reconnecting, spamming #con gets garbled messages far more often than spamming #dis then #con.

Not a 3.07 issue for me, i've had it randomly before. Was pretty sure it was something mud server side.

Posted: Mon May 18, 2009 5:07 pm

Yes, this is a known bug in previous versions, so it's not new to 3.07. It's already on the bug list.

Apprentice Joined: 14 Apr 2008 Posts: 105

yeah it's definitely in the old ones too because as I said in that thread I stopped using beta to 2.37 and I still got the errors :(

Posted: Sat Jan 30, 2010 2:50 am

I'm going to bump this because it's pretty annoying. I've wasted several hours on this already, only to come to the conclusion that the MCCP and MXP implementation on DiscWorld is a real mess.

There are multiple times when just reconnecting at the DiscWorld login screen where DiscWorld specifically sends the IAC SB 86 IAC SE telnet sequence to start compression mode, and then sends PLAIN TEXT in the very next packet. Usually this plain text packet contains their MXP ELEMENT definition setup.

So DiscWorld clearly has a bug in their code that either sends the MXP data out-of-sync with their MCCP negotiation, or somewhere they are sending the text directly to the client and bypassing their MCCP code completely.

The reason CMUD would get into a loop with the MCCP error popup is that when CMUD sees a compression error, it tries to send the IAC DONT MCCP telnet sequence to the MUD to tell the MUD to stop sending compressed text. But DiscWorld doesn't seem to recognize this, because it does not respond with the proper IAC WONT MCCP and just keeps sending compressed text, causing more MCCP error popups.

To try and improve this a bit, I have removed the code that tells the server to turn off MCCP when CMUD detects an MCCP error.

But I don't know what to do about the rest of this. I just can't kludge CMUD to handle some MUD that doesn't implement the MCCP protocol properly. There is no way to automatically look at the data stream and decide "oh, this data isn't compressed even though it should be". What I might try doing is to look at the data in the MCCP error handling routine and scan the data for non-text characters (allowing for escape, cr, lf, and telnet option codes). If the data looks like it is ascii, then I can try to send it to the screen and hope for the best.

But somebody really should notify DiscWorld about this issue and get somebody who knows what they are doing to respond to this post so we can try to get this issue fixed. There are a lot of frustrated DiscWorld players out there and we can't just keep tossing blame back and forth.

I'm already a bit annoyed that a lot of DiscWorld players probably think CMUD is crap because of this issue and is spreading incorrect rumors about it.

Newbie Joined: 19 Feb 2010 Posts: 7

I'd love to know how you got ascii after the compression on sequence, because in a few thousand (automated) attempts (not with zmud) it has not happened to me and about a third of the time there's already compressed data waiting on the socket when compression is turned on. (you do copy that to the decompressor i hope, not just the next packets). I do get the occasional zlib error, but it shows binary junk as data being used, so I guess that's either a bug in my client or in libz, no ascii found anywhere!

I've only ever heard people say it doesn't work on CMud as well, zmud seems to be fine, this further suggests the problem is with CMud.

So from what I'm seeing it's not clearly a fault in Discworld. Except arguably the fact that we don't support turning mccp off! (what's the point??)

I can't look at your code, but if the fault is rather common, and you saw ascii going in the decompression, my guess is you decompress the data that has already been received when mccp is turned on twice.

Wodan (admin on Discworld).

Posted: Fri Feb 19, 2010 11:00 pm

What version of CMUD are you using? If you are using the 3.14 version, then you'll never see the ascii data after the "compress on" because of the kludge fix that was added to 3.14 to handle this case. In previous versions of CMUD it happened a lot and people here complained about it all the time.

I know when I was testing previous versions, I could get text to appear after the compress on sequence in the Delphi debugger all the time. It is a timing issue. I could force it to happen by pausing the code any time after processing the "compress on" sequence. Adding this pause almost guaranteed that the following MXP Element definitions would appear uncompressed from the MUD.

My guess is that you are sending the MXP data in a different thread or stream that is not properly synchronized with the main network stream that handles the compression.

The reason people *think* that zMUD was better is just because zMUD ignored the MCCP errors and didn't have the same popup. CMUD has more MCCP error checking in it, so it doesn't just ignore most problems. At least until I added the kludge to 3.14 just to get past this issue for my customers.

Newbie Joined: 19 Feb 2010 Posts: 7

I didn't use CMud, I used my own client (coldbeer) not quite as versatile as your clients, but it does have mccp and mxp, and like I said, I could not get it to happen, at all.
mxp is sent the same way as everything else, and it's all compressed after we turn it on. Unless we have a bug that only shows with CMud!

You can check the server side code in the driver if you like, comm.c in http://www.fluffos.myzen.co.uk/fluffos/fluffos-2.19.tar.bz2

Newbie Joined: 19 Feb 2010 Posts: 7

I didn't say it clearly wasn't discworld's fault, I said it's not clear that it's discworld's fault, that's different! Anyway, I downloaded CMud and I'll try that with a packet sniffer.

Newbie Joined: 19 Feb 2010 Posts: 7

I'm confused now, it showed what you saw, so I tried with coldbeer and it sniffer showed the same thing! But it all just works, guess libz handles this for me (which makes me wonder what you use). I'll have to figure out how this happens.

Newbie Joined: 19 Feb 2010 Posts: 7

It seems that particular problem is the packet sniffer recognizing compressed packets, turning that filter off actually shows what I expected, compressed data only for both CMud and coldbeer. I checked the mud side for any possible problems, but it flushes everything before turning on compression, and it's single threaded, so it just doesn't seem to be possible.

So if you're really seeing ASCII coming in, I'll go back to my previous suggestion, check if you decompress it twice!

Posted: Mon Feb 22, 2010 5:56 pm

Can you email me the log from the packet sniffer to sales@zuggsoft.com so I can see this happening?

Apprentice Joined: 14 Apr 2008 Posts: 105

Just thought I'd say I actually did speak to wodan (or was it woom? one of those) about this in-game about a year ago but he didn't really care and would not talk to anyone at zuggsoft even when I asked because apparently you had some argument with the admins before and hate discworld or something (zugg)... I don't know, just nice that this is finally getting looked at (haven't been playing but friend poked me) after all this time, I think you are both as to blame as each other really, since you could have easily got hold of each other if you tried

Beginner Joined: 04 May 2005 Posts: 12

I'm pretty sure I've never had an argument with Zugg. I wish I knew where that rumour started :)
(Hi Zugg!)

Posted: Thu Feb 25, 2010 5:31 pm

Who knows where these rumors get started. I've never had any argument with anybody at Discworld that I'm aware of. And I'm trivially easy to get a hold of via these forums or via email.

I'll admit that I get just as frustrated as anyone about MUD-specific problems. They are very hard to debug, as this thread (and related others) have shown. I'd much rather be spending my time debugging problems that effect all users rather than just individual MUDs. But I don't think I've ever let it get personal with anybody.

In any case, I received the packet log from Wodan (who is Woom??) and am still looking into this issue.

Posted: Fri Mar 26, 2010 9:49 pm

I've looked into this a bit more. There *is* a case in the CMUD source code that can cause it to decompress twice. However, I can't see how DiscWorld would be triggering this case.

The case in which CMUD will decompress twice is if it receives the IAC SB COMPRESS code within a packet that is already compressed. CMUD will decompress the entire packet, and then when it parses the IAC SB COMPRESS code it will decompress the data following this code.

However, sending the IAC SB COMPRESS code within a compressed packet is not legal within the MCCP spec. So I don't think this is happening with DiscWorld. I am modifying the next version of CMUD so this doesn't happen, so I guess we should just wait for the next release and test it again.

I will remove the kludge that I added to the previous version that was suppressing the MCCP error if the data already looked like normal text so that we can continue to debug this properly.

Posted: Fri Mar 26, 2010 10:04 pm

Actually, this *IS* what is happening. Here is the packet I am receiving from DiscWorld with the MXP setup data. This packet is received as a compressed packet. CMUD decompresses the data, and here is what it gets:

Newbie Joined: 19 Feb 2010 Posts: 7

Posted: Fri Apr 09, 2010 3:34 am

Send me an email and we can talk about getting you a copy of CMUD.

Yes, I completely confirmed this. Look in the data packet that contains the initial MXP setup data. You'll see the raw bytes in that packet that I mentioned above. And this is being sent as compressed data. The byte codes I displayed above were from a dump after zlib had processed the initial compressed data packet.

Newbie Joined: 19 Feb 2010 Posts: 7

Ok, that was easy, it only goes wrong on reconnects, and it does because for some reason you start the connection with DO 86, without the server even mentioning that it WILL, the server then sends that it will as part of the usual connection setup, to which cmud replies with a DO 86 again, which the server is just fine with, so it sends a second compress message...

I think both ends violate the protocol in that sequence. FluffOS will ignore compress requests on compressed connections in the next release so that should fix our end, at that point it shouldn't matter if you stop sending the unrequested DO 86 or not.

problem solved!

Posted: Mon Apr 12, 2010 11:59 pm