Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
jsravn
Newbie


Joined: 02 Apr 2008
Posts: 2

PostPosted: Wed Apr 02, 2008 11:58 pm   

MCCP on reconnect is broken
 
I wasn't sure how to get access to the developer board, so I'm posting this here.

zMud has a bug in it's MCCP (Mud Client Compression Protocol) implementation.

When zMud reconnects to a mud in the same session window, it incorrectly sends the IAC,DO,COMPRESS2 string *before* it gets IAC,WILL,COMPRESS2 from the mud.

This manifests itself usually by prepending a "V" to the username. So when I type in my username "bob", the mud reads it as "Vbob". This is because the COMPRESS2 byte is equivalent to the V ascii code.

This is easily testable with netcat. Here is the output of netcat when I reconnect with zMud:
Code:
xxxx@xxx:~/devel/circle$ nc -l -p 4300
˙ýV


zMud sends the IAC,DO,COMPRESS2 immediately upon connecting. It is supposed to wait for the IAC,WILL,COMPRESS2 from the server first.

I'm a licensed zMud owner. Any chance this bug will be fixed in a zMud release? It is a major headache, especially to implementors of the server side protocol.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Thu Apr 03, 2008 3:55 am   
 
Unfortunately, the chances of the bug in zMUD being fixed, is slim to none as zMUD is considered feature complete.

You can try the next generation client from Zugg which is CMUD. If the problem does exist in CMUD as well, then submit a bug report and it will be added to the bug list to be fixed in a future release.
_________________
Asati di tempari!
Reply with quote
FiendishX
Wanderer


Joined: 19 Nov 2005
Posts: 53

PostPosted: Thu Apr 03, 2008 4:00 am   
 
Tech wrote:
Unfortunately, the chances of the bug in zMUD being fixed, is slim to none as zMUD is considered feature complete.
Yeah. It's just too bad that "feature complete" doesn't mean the same thing as "without bugs".
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Apr 03, 2008 5:20 pm   
 
Actually, this isn't a bug. The Telnet option protocol is bidirectional. zMUD will respond to IAC WILL to enable/disable options such as MCCP. But MCCP also allows the MUD client itself to send DO/DONT commands back to the MUD to tell the MUD to enable/disable MCCP. So it sounds like your particular MUD just doesn't implement the DO/DONT commands properly.

But I've tested this on many MCCP MUDs, such as the Iron Realms MUDs, and they all work fine. So perhaps you can give us more details on the exact MUD that you are using.

Also, no software is *ever* "without bugs". Anybody who tells you that there software doesn't have any bugs is either lying, confused, or the application is trivial. zMUD is over 1 million lines of code, and no software of that size is ever without bugs. Also, many of the "bugs" are actually problems left over from supporting old versions of Windows, such as Windows 95/98. There is no way to fix them without breaking compatibility with those versions of Windows. That is why CMUD was created instead, so that I could use a new and more modern design that wouldn't have some of these bugs (and would not need to support old versions of Windows).
Reply with quote
ralgith
Sorcerer


Joined: 13 Jan 2006
Posts: 715

PostPosted: Wed Apr 09, 2008 12:57 pm   
 
I agree with Zugg, I've implemented this protocol on 2 different MUDs I coded for, and believe me, it isn't broken :)
_________________
CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate
Reply with quote
jsravn
Newbie


Joined: 02 Apr 2008
Posts: 2

PostPosted: Thu Apr 10, 2008 4:08 pm   
 
Thanks for the response.

You're right of course, the telnet RFC specifies that options can be negotiated in either direction.

The confusion, for me at least, is my interpretation of http://www.zuggsoft.com/zmud/mcp.htm.

Code:
Servers supporting version 2 (this version) of the protocol should indicate they support it by offering the COMPRESS2 option (number 86): IAC WILL COMPRESS2. They may also optionally offer the older version 1 option (number 85) to support older clients: IAC WILL COMPRESS. Servers should offer COMPRESS2 before COMPRESS to allow newer clients to support any extra features added to COMPRESS2 in the future while still supporting COMPRESS.

Clients should respond to the COMPRESS2 option with IAC DO COMPRESS2 if they want the server to enable compression. To support older servers, clients may respond to the COMPRESS option with IAC DO COMPRESS, although it is recommended that the COMPRESS option is refused with IAC DONT COMPRESS if COMPRESS2 has been previously offered by the server.


Then it goes on to summarize the negotiation protocol.
Code:
  version 2 server                      version 2 client
  IAC WILL COMPRESS2
  IAC WILL COMPRESS
                                        IAC DO COMPRESS2
                                        IAC DONT COMPRESS
  IAC SB COMPRESS2 IAC SE
  (compressed stream)


Everywhere in this document it seems to imply that the negotiation is unidirectional, which makes some sense considering the compression is unidirectional.

But on the other hand, I see your point. It does say it is based on telnet option negotiation, which allows for either client to start the negotiation. Maybe it would be worth clarifying this in the document? Or maybe I'm the only person that mis-interpreted it this way... :-).
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net