Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --preliminary
- Original Message - From: Gerhard Wesp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:29 AM Subject: Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --preliminary Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Is there any specific reason not to use human readable messages (i.e., ASCII)? bandwidth and performance I could understand human readable for a limited system, but not for a setup that could potentially be handling 100s of planes, and while for GA sims, it may not be needed, I have a little more than that in mind :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Is there any specific reason not to use human readable messages (i.e., ASCII)? It's a waste of bandwidth. The volume of data is immense and you want to make your data packets as efficent as possible. The smaller you can make your data, the less chance there is of warping, teleporting, etc. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
John Barrett wrote: Here is a quick and dirty 1st cut at a wire protocol definition, and some requirements for the message handling classes that will implement the protocol Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Objection. Use network byte order (ntohl and the like) instead. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
Here is a quick and dirty 1st cut at a wire protocol definition, and some requirements for the message handling classes that will implement the protocolPreliminary FlightGear Server (FGS) wire protocol specification 0xFFEscape prefix for 0xF? bytes in the data next byte is inverted, except for data type prefixes 0xFEBegin message, 8 bit message ID 0xFDBegin Message, 16 bit message ID CodeTypeC/C++ equivalent 0xF0byteunsigned char 0xF1wordunsigned int 0xF2dword unsigned long 0xF3qword unsigned long long 0xF4signed byte char 0xF5signed word int 0xF6signed dwordlong 0xF7signed qwordlong long 0xF832bit float float 0xF964bit doubledouble 0xFAundefined 0xFBundefined 0xFCstring, next byte is length char* unterminated binary data Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Messages are constructed by sending a Begin Message byte, followed by the message ID, and then each data element.. clients/servers that dont understand a given message should be able to skip past to the next start of message marker. the FGSMessage base class will define an array of type/pointer that identifies the type, and location to store each element of a message. Derived classes will load this array with the correct associations for the specific message being sent or recieved. Recieved messages must have the same types in the same order or the message is rejected as invalid. All platform specific data conversion will happen in the FGSMessage base class during packing/unpacking of the message. Message objects derived from the FGSMessage base class will register with base class using static methods to establish a factory style instantiation mechanism such that an inbound message can be passed to a static method of FGSMessage, and the return value will be a pointer to an object of the correct message type. FGSMessage::recieve will be equally able to handle UDP packets with multiple messages, or TCP packets with partial messages, buffering message fragments until the next time the recieve method is called.___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
