----- Original Message -----
From: "Andy Ross" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Sunday, November 09, 2003 11:59 AM
Subject: Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
> John Barrett wrote:
> > Here is the patch and source files for the preliminary wire protocol
> > implementation -- comments and suggestions welcome
>
> This sounds fun, so I grabbed it and had a peek. One bug report in
> messagebuf.cxx, which has some code that I can't figure out:
>
> > void FGMPSMessageBuf::put(unsigned char byte, bool raw)
> > {
> > if (!raw) {
> > if ((byte & 0xf0) == 0xf0) {
> > buf += 0xff;
> > byte = byte ^ 0xff;
> > }
> > }
> > buf += byte;
> > }
>
> If I read this correctly, if "raw" is false (which is the default
> argument), then values in the range 0-239 are passed normally, while
> values in the range 240-255 cause an extra byte of 255 to be inserted
> in the stream, followed by the bitwise negation of the original byte.
> I don't see anywhere for the extra 255 to be interpreted on read,
> though.
for cooked data, values 0xf0 to 0xff are protocol reserved values and are
escaped by prefixing with 0xff and inverting the data -- you can find the
corresponding decoding in the "get" method
unsigned char FGMPSMessageBuf::get(bool raw)
{
if (pos >= buf.length())
throw FGMPSDataException( "FGMPSMessageBuf: Read past end of buffer" );
if (raw) return buf[pos++];
if ((unsigned char)buf[pos] == 0xff) {
pos++;
return ((unsigned char)buf[pos++] ^ 0xff);
}
return buf[pos++];
}
>
> I'll admit that I have absolutely no idea what this code is supposed
> to do. :) Are you maybe trying to handle 2's complement signed values
> via an escaping mechanism? If so, you need to change the bit test to
> 0x80, and can elide the complement operation entirely. It's best to
> leave signedness determination in the hands of the user code, though.
>
Trying to make the protocol resistant to changes in message structure, and
malformed messages due to transport layer errors (for instance if this
protocol is run over serial lines or modems) -- I thought it desirable that
protocol specific values never appear in the application data and that all
data elements in a message be typed so that malformed messages could be more
easily detected (we used a similar setup over at WorldForge to make the
client/server link more tolerant when the endpoints of a connection had
different application message versions)
> One other nit is a collection of portability bugs in your type
> declarations. A "long" value isn't guaranteed to be 32 bits, on an
> LP64 platform (64 bit unices, but not Win64) it's a 64 bit quantity.
> I also see some locations where you appear to be assuming that an
> "int" is 16 bits, which was true on the PDP-11 and 8086, but nowhere
> else; it's not clear if this extra precision will result in real bugs
> or not.
>
I know -- I claim fatigue as an excuse - I'm packing to move next week while
I work on this -- I'll dig in and find the portable type declarations and
update the code in the next few days :)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
