Am Friday 15 July 2005 23:34 schrieb Ampere K. Hardraade: > I think it will be more flexible if the networking portion of FlightGear > can be modified to exchange properties. For starter, the > nodes /accelerations, /positions, and /surface-positions can be exchanged > among users. Properties under /accelerations can allow one client to > interpolate the position of others, thus eliminating jitters. Properties > under /position are basically what being exchanged right now. As > to /surface-positions, the properties inside this node can allow one to see > the animations of others correctly.
The existing code only needs some minor modifications to allow any kind of property to be send over the wire. There are only a couple of functions to modify in order to do this. That way it is possible to "configure" the network protocoll via XML-files and let NASAL do the logic (as suggested by hfitz on the AVsim forum, see http://forums.avsim.net/dcboard.php?az=show_mesg&forum=198&topic_id=913&mesg_id=934&page=) NASAL "only" has to fill a message structure and let the network-code send it over the wire. There are, however, some issues with networking. To actually send diefferent kinds of properties over the wire, you have two possibilities: 1) "chain" properties in one packet 2) send each property in its own packet In case 1) it may be possible to blast the capacity of packets (MTU) in which case the packet becomes splitted. And it may be difficult to handle splitted packets. In case 2) you possibly interfere with the "frequency" used to send packets and thus make it very difficult to keep clients in sync. > To cut down the amount of data being sent/received, a client only have to > broadcast the above nodes once, and resend individual properties when > needed. In general you don't want to send large amount of data using UDP. You will eihter have to deal with lost data (which is getting worse with every additional client) and have to calculate approximations for values in the property tree or have to use some kind of "data-received-confirmation" machanism producing overhead. And it may be unnecessary to broadcast the tree. Assuming a normal startup of clients, every client can be initialized as they were local. This should give already a good approximation of its status at startup. And as packets arrive with updated property values, the data becomes more and more "right". And calculate approximations for the property tree of other clients is necessary anyway to 1) deal with lost packets, 2) deal with low frequency rates of network packets and 3) temporary performance leaks of the local instance of fgfs. just my 2c, Oliver _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
