Zugg Software :: View topic

Beginner Joined: 17 Nov 2004 Posts: 12

Hello again!

I need to debug the MCCP communication between my code base and ZMUD, but am having trouble. The problems appear to be intermittant, and tend to occur only for remote users (meaning, I can't really reproduce it local).

I suspect its a problem with data fragmentation, which is a problem I've seen previously between straight Winsock apps talking to Java servers.

SO, FINNALLY! A Question! Is it possible to turn on binary logging in ZMUD? Something that will show the raw data input chunks it receives during each read, as a stream of integers, before ZMUD does any parsing of it (like sending it to its zlib)? I've checked the zmud.ini file, but saw nothing obvious.

Thanks for any responses,
- Bo

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

There's the #DEBUG command, but I dunno if that will produce what you need to know...

Posted: Mon Feb 06, 2006 3:46 am

#DEBUG test.txt test.raw

the test.txt will only have the text communication (post MCCP), but the test.raw (which is also a text-format file) will show the binary communication between the client and server. Load test.raw into Notepad and you'll be able to figure out how to read it pretty easily.

Beginner Joined: 17 Nov 2004 Posts: 12

Well, that worked like a charm, and it also demonstrated that the problem is precisely what I thought it was.

When MCCP starts up correctly, the moment of truth looks like this:
in ( 5) 02/19/06 17:09:33:031 : <IAC><SB><86><IAC><SE>

When MCCP fails to start correctly, the moment of truth looks like this:
in ( 1) 02/19/06 17:10:40:640 : <IAC>
in ( 4) 02/19/06 17:10:40:640 : <SB><86><IAC><SE>

Fragmentation! Argh!!!

I have seen this behavior in other Java/C++ server/client relationships. Hopefully there is an answer from the server side. Unfortunately, this is an example of what happens when high level languages like Java try to save us from ourselves by abstracting away the very source of our problems...

- Bo

Beginner Joined: 17 Nov 2004 Posts: 12

Looks like there is a tentative answer -- at least enough of one that I was thoroughly unable to recreate the problem locally after applying it. The answer was to use only the most primitive outputstream methods that allow blocks of data to be sent, and under no circumstances send the block bytes at a time (when you flush() the stream is irrelevant) or use higher level outputstream methods that may get torn away by the VM threadding machine.

- Bo

Posted: Mon Feb 20, 2006 6:11 pm

Thanks for pinning this down. zMUD has lots of code to deal with packet fragments in other parts (like ANSI codes, MXP, etc), but you are correct that zMUD currently depends upon the telnet options to be in a single packet (you can have packet breaks between options, but not within a single option).

In CMUD I'll look at the telnet option code and see if I can improve it to deal with packet fragmentation. But for now your advice is good, and it's a good thing for MUD coders to pay attention to since there are many MUD clients that cannot handle packet fragmenting at all.