View Issue Details

IDProjectCategoryView StatusLast Update
0000204JamochaMUDMain Programpublic2010-02-14 17:14
Reportermm0qqAssigned Tojeffnik 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.1 
Target VersionFixed in Version4.7 
Summary0000204: ANSI code processing is flaky
DescriptionSometimes JamochaMUD "misses" part of the ANSI code from the Muck. Example, instead of displaying Max in blue letters, it displays ;34mMax in the previous color.
Additional InformationWindows XP SP2
JamochaMUD JAR file dated Jul 6, 2008
TagsNo tags attached.

Activities

jeffnik

2008-07-19 12:35

administrator   ~0000173

JamochaMUD's ANSI parser is in fact very poor; mostly in the effect that it wants the entire ANSI code to be contained in one string, though this cannot be guaranteed by a connection. The MU* server may send half the ANSI code in one string and half in another, which JamochaMUD will disregard as being a malformed code.

This parser should be rewritten.

mm0qq

2008-07-23 06:46

reporter   ~0000175

It's really a connection issue - no matter what the other end sends, the chunks often get split up before arriving, so TCP will fulfill the read with as much as it has. In programs I've written, I have resorted to double buffering input. That way, if a token is split across reads from the TCP socket, my parser can "hold" the partial token token until the rest of it is read.

I would look into this myself, but I am still having problems getting a Java build environment working correctly.

mm0qq

2008-09-03 22:48

reporter   ~0000190

Last edited: 2008-09-03 22:52

I had a thought about the ANSI parsing problem. The mu* servers always send output as lines of text. This means there will always be some kind of "new line" after everything the server sends.

If you wait for a new line before feeding the text to the parser, the problem will go away.

Of course, there is still the issue wil preventing buffer over flows, but the mu* servers very rarely send lines greater than 4096 character, which, I think includes ANSI sequences, so is really 4096 bytes.

So, a buffer of 4100 bytes should be large enough. I not sure about Java, but in C, this would be:

char buffer[4100];
while ( ! feof(fh) )
{
  if ( fgets(buffer, 4100, fh) != NULL )
  {
    parse(buffer);
  }
}

The above code will read the text stream one line at a time with a limit of 4099 characters (actually bytes) per line. (Any line longer than that might get parsed funny, but that should not be an issue.)

jeffnik

2008-09-06 01:03

administrator   ~0000191

Version 3.5 of JamochaMUD will feature partially re-written ANSI parsing. If JamochaMUD encounters an escape character it will buffer input that is received until the escape is either completed or invalid, and then will display the result. This should help to avoid problems where an escape is sent as two separate lines.

This code still requires some testing.

mm0qq

2008-09-26 20:52

reporter   ~0000192

The ANSI parsing enhancement in 3.5 seems to be working fine.

Issue History

Date Modified Username Field Change
2008-07-14 19:51 mm0qq New Issue
2008-07-14 19:51 mm0qq Status new => assigned
2008-07-14 19:51 mm0qq Assigned To => jeffnik
2008-07-15 23:57 jeffnik Status assigned => acknowledged
2008-07-19 12:35 jeffnik Note Added: 0000173
2008-07-23 06:46 mm0qq Note Added: 0000175
2008-09-03 22:48 mm0qq Note Added: 0000190
2008-09-03 22:52 mm0qq Note Edited: 0000190
2008-09-03 22:52 mm0qq Note Edited: 0000190
2008-09-06 01:03 jeffnik Note Added: 0000191
2008-09-06 01:03 jeffnik Status acknowledged => feedback
2008-09-26 20:52 mm0qq Note Added: 0000192
2010-02-14 17:14 jeffnik Status feedback => resolved
2010-02-14 17:14 jeffnik Fixed in Version => 4.9
2010-02-14 17:14 jeffnik Resolution open => fixed