[Flightgear-devel] Multiplayer -- wire protocol implementation
http://www.camelot-software.com/fgfs/fgmps.tar Here is the patch and source files for the preliminary wire protocol implementation -- comments and suggestions welcome -- untar in the directory containing the FGFS source directory, apply the patch, autogen, configure --with-multiserver, and make -- 2 executables (buftest and msgtest) will be created in src/Servers that demonstrate the wire protocol handling, and the base class for managing messages At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? And lastly, which is the best network module to use as a reference for creating the status messages that get sent out every call to process() so that I dont miss anything critical ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote: At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? Take a look at plib/src/net. From the README in that directory: This is a C++ library for making networked games. It includes event-driven channels, support for buffering and pipelining, a monitor server for remote telnet admin, and binary messages. HISTORY Initial work by Dave McClurg [EMAIL PROTECTED] This library is based on from a high-performance internet server architecture for Python called Medusa. http://www.nightmare.com/medusa/medusa.html Added binary messages and PLIB naming conventions Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett writes: At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) The 'loop' is in netChanel.cxx SimGear sockets and are built ontop of PLib/Net as is the FGFS http server, which should make an applicable stress test easy to formulate :-) for a Python based discussion of the methodology used see http://www.nightmare.com/medusa/medusa.html HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) The 'loop' is in netChanel.cxx SimGear sockets and are built ontop of PLib/Net as is the FGFS http server, which should make an applicable stress test easy to formulate :-) ok -- I give up :) total surrender :) Interestingly enough -- the classes are quite similar to mine -- even unto line terminator handling -- prime difference being that my socket instances must register with the server class in derived implementation code, since the core socket code can be used with or without the server loop -- looks like plib handles that automatically Guess I have enuf to do the server framework and initial handshake between client and server ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett writes: From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) Guess I have enuf to do the server framework and initial handshake between client and server Might want to ask any questions or solicit ideas over on the PLib list as this Library has been used before in somewhat similar 'online' gaming apps :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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.
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.
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.
Andy
--
Andrew J. RossBeyond the OrdinaryPlausibility Productions
Sole Proprietor Beneath the Infinite Hillsboro, OR
Experience... the Plausible?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- 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
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 11:58 AM Subject: RE: [Flightgear-devel] Multiplayer -- wire protocol implementation John Barrett writes: From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) Guess I have enuf to do the server framework and initial handshake between client and server Might want to ask any questions or solicit ideas over on the PLib list as this Library has been used before in somewhat similar 'online' gaming apps :-) I think between the http network module and the other modules that actually move a/c data, I've got enough to get the basics in place -- my next question will be how do I add an a/c instance to the current scene and keep it updated but I can likely dig that out of the other multiplayer modules ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
