|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Fri Jan 07, 2005 3:20 am
Bugs in zMUD's handling of MCP |
I know this belongs in the developer forum, but my access to that is still pending. I'm trying to test MCP 2.1 on a MUD server I'm building from scratch, and I'm seeing some weird problems on zMUD. It's the only client I've tested with so far, and MCP support is turned on.
When the connection is established, I send:
#$#mcp version: 1.0 to: 2.1
zMUD replies with:
#$#mcp authentication-key: 1409589903 version: 1.0 to: 2.1
I then send the following:
#$#mcp-negotiate-can 1409589903 package: mcp-negotiate min-version: 1.0 max-version: 2.0
#$#mcp-negotiate-can 1409589903 package: dns-com-awns-displayurl min-version: 1.0 max-version: 1.0
#$#mcp-negotiate-can 1409589903 package: dns-com-vgmoo-client min-version: 1.0 max-version: 1.0
#$#mcp-negotiate-end 1409589903
At the same time, I'm getting the same kinds of messages from zMUD, as expected. What's odd, though, is that the first of my mcp-negotiate-can messages is getting swallowed as it should, but then I see the following in the client window:
#$#mcp-negotiate-can package: dns-com-awns-displayurl min-version: 1.0 max-version: 1.0
#$#mcp-negotiate-can package: dns-com-vgmoo-client min-version: 1.0 max-version: 1.0
#$#mcp-negotiate-end
It doesn't matter if I take off the first negotiate message... same thing happens (2nd is swallowed, and the other messages are displayed). I don't get either of the messages that it seems like I should get with that last package, either. Any ideas? |
|
Last edited by maeglin on Sun Jan 09, 2005 12:59 am; edited 4 times in total |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri Jan 07, 2005 9:03 am |
Send them in seperate packets possibly. You might also have to email Zugg to get a solution to the problem
|
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Fri Jan 07, 2005 1:54 pm |
Doesn't seem like it should matter (it's all CRLF-delimited text, right?) but, hey, stranger things have happened. I can try tonight adding a second delay between MCP messages, but I honestly don't think that'll do any good. So far I've tried waiting until the first mcp-negotiate-can from zMUD, as well as until after it sends its mcp-negotiate-end. Same results every time.
If it makes any difference, I've already gotten MCCP working, and that's turned on in zMUD as well. Haven't tried turning it off yet to see if that affects it. |
|
|
|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Sat Jan 08, 2005 12:36 am |
As I thought... MCCP had nothing to do with it. Checked with another client, as well, and my use of the protocol seems to be correct. Apparently it's a bug in zMUD's support...
|
|
|
|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Sat Jan 08, 2005 8:03 pm |
Apparently the problem with mcp-negotiate-can messages isn't the only bug... the package name "dns-com-vgmoo-client" should instead be "dns-com-vmoo-client".
|
|
|
|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Sun Jan 09, 2005 1:09 am |
One last bit of info... even after the screwy display while my server is trying to negotiate MCP packages with zMUD, I can still send messages in packages that zMUD supports and it will process them correctly. That is, unless the authentication key is wrong, then I get the same kind of display I got during the negotiation for the messages in question. The message is displayed, but the authentication key is omitted from the display.
My guess is that, for some reason, zMUD is momentarily forgetting or corrupting its idea of what the authentication key is if the MCP messages are sent without some delay between them. It would be difficult for me to build such a delay into the part of the code that sends these messages but, honestly, I shouldn't have to do that anyway.
I'm willing to send a binary copy of the current build of the server (basically only a telnet server, with protocol discovery and negotiation, and a lot of MCP debugging output) if someone wants to debug and fix this problem in zMUD. It requires Cygwin to be installed, though. An alternative is my putting the server on a machine of mine that can be reached for testing. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Sun Jan 09, 2005 5:30 pm |
I would again suggest emailing Zugg. In zMud you should use the command "#DEBUG test.txt trace.txt" before connecting to generate 2 files containing the raw and semi-raw communication data. Include those along with a screen shot in a zip file. Reference this topic, as well as providing as much of an explanation of the bugs you are noticing.
I really wish I could be of more help, but I simply don't know enough about the protocol and its negotiations to tell where the problem is. You might also put a bug report in the Bug Tracking System. Again supplying enough details so someone else can understand exactly what is happenning. |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
maeglin Newbie
Joined: 31 Dec 2004 Posts: 6
|
Posted: Sun Jan 09, 2005 5:35 pm |
I've already emailed the support email address (I'm guessing that goes to Zugg), pointing to this thread, a couple days ago. That's why I kept adding details to it as I went along. By the time they get back to answering emails tomorrow, they should have what they need in here.
I'll look into the bug tracking system. Thanks. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Jan 11, 2005 9:48 pm |
I took a look at your post and then looked at the zMUD source code for the MCP implementation. And yes, it looks like zMUD has a bug and is only able to negotiate a single package. After the first mcp-negotiate-can command, zMUD then ignores additional mcp-negotiate-can commands.
Looks like this bug was introduced in one of the more recent zMUD updates and that MCP wasn't tested since then.
I will add this to the bug list to be fixed in the next version of zMUD, but I don't have any time frame for this unfortunately. |
|
|
|
|
|