Hi List, Melchior FRANZ schrieb: > There's a TODO message in multiplaymgr.cxx that says: > > // A static map of protocol property id values to property paths, > // This should be extendable dynamically for every specific aircraft ... > > This static list grows and grows and that's becoming a problem. I > hardly ever take part in MP, because the amount of incoming data > is just too big for my connection. And that's no surprise when > even an UFO sends rotor angles, gear compression, tailhook angle, > etc. > > This problem is the cause why I decided to make /sim/model/variant > only an integer. But I agree very much with Syd that a string would > be much better, or rather with Anmaster, that several strings etc. > should be supported. > > I'm not an fgms or MP expert, but as far as I've understood the > protocol is now relative simple. After an initial package containing > e.g. the aircraft path, all further packages always contain all > properties of the static list. There's no response from the clients > necessary.
The current protocol is very simple and very static. We have a few packet types and for every additional property we want to send, we need to modify the sources and make sure we don't send more data than one packet can transmit (the current maximum size of one packet is 1200 bytes). That's one part I'm working on. The library is ready for testing in my drawer and I'm more or less currently working to get it into working code on the server side. But real life is in the way, sometimes. So my progressing is slow. The basic concecpt of my library is to write ID|value pairs to a buffer, and the library takes care about this buffer and automatically creates new buffers if the current buffer can not hold the data. For this, we need a mapping for IDs to properties. This mapping should probably map all possible properties. My idea to those IDs is: the ID encodes automatically the space, this property consumes in a network packet in xdr-units (4-bytes). With this scheme, other applications know how many bytes to skip in the packet for data they are not interrested in or have no knowledge of. An ID<10000 means, the next 4 Bytes is the length of the property. For all others ID/10000 (integer division) is the length of the data. For example, the Position could have the ID "120000", the orientation "120001", etc. Meaning the data consumes 12 bytes in the packet. Anyone is welcome to simply do the mapping. Either via a static map, or within the property tree itself. Volunteers, step forward. > But this method can't be continued ad infinitum. Only the absolute > minimum of data should be transferred, and this should be configurable > on a per aircraft basis. I could imagine these types of data, in > addition to the initial data package containing the aircraft path: > > (1) properties sent in every package without expecting confirmation > > (a) always sent > - position & orientation > - additional properties as configured by the aircraft > > (b) like (a), but only start to send them after they changed to > a non-default value (zero/empty string) for the first time. > This can be predefined so that not every aircraft has to list > them all, but they wouldn't be sent when not necessary. > > /gear/gear[0]/compression-norm > /rotors/main/rpm > > (3) send initially and whenever changed until confirmed > (configurable by the aircraft) > > /sim/model/foo/livery=Aircraft/foo/Models/Liveries/blue.rgb Which should be pretty simple and straight forward. > > Whether we can afford to transfer a livery path already with the > current system in place must be decided by the MP gurus. We can put the livery path into the current protocol, as an intermediate solution. But in the long run head toward a new protocol. Regards, Oliver ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
