> I think if two or more people have the same callsign, they should be grouped to the same aircraft.How? whose FDM updates should be taken as real by the server?note that this is connectionless, so maybe some callsign is reusedfrom another machine legitimately? Or do we want some server-sideexpiry of a callsign associated to an IP?Actually, the server can still send the second guy the updates,but just ignore the packets from him.

>This can be a real issue. The server does not know (it simply>can't) which planes a client has installed. And fgfs has no>real chance to handle this. Well, theoretically all connecting clients could provide information about the aircraft/models that are available in their base package, that way the server could recognize clients connecting using unavailable aircraft and deal with this issue accordingly.Game server implementations for other games will often even enable users to optionally download the corresponding files to their machine, so that they don't have to quit the game and manually update their file system.Of course this is not really directly an option for a UDP based server which is mainly meant to synchronize communications and not become a file server.However, the solution to this problem could be as simple as adding a corresponding XML tag to the aircraft definition files that provides information about where a corresponding aircraft (package) can be obtained from, i.e. something like:http://www.flightgear.org/aircraft/a320.bz2at the top of the main *.XML file for each aircraft.That way, all aircraft that may not be available on certain clients could be easily downloaded by other clients using the corresponding URL to it.So, for multiplayer purposes it could become a requirement to provide such a tag, so that all multiplayer clients can easily AUTOMATICALLY obtain any aircraft files.Basically, this would be a very convenient solution to the problem itself, because it could be as simple as:- client connects to multiplayer server- client reports aircraft that's used- server informs all currently connected clients about the new client and its aircraft/model- all connected clients will check their base package for the model- and optionally use a default model or really download the required tarball in the background- and then render the corresponding model as soon as it's downloadedAll clients that are trying to connect to the gameserver with an active aircraft that doesn't provide the corresponding tag could be easily told:"You are trying to connect to a multiplayer server, all clients that connect to a multiplayer server need to provide information about where the files for their active aircraft can be obtained from if necessary. The aircraft you are currently using doesn't provide such information, please edit [PATH/FILENAME] and add a tag to the top of the file."So this would be a pretty convenient workaround because it wouldn't necessarily have to rely on flightgear.org and its mirrors, but would rather also enable individual users to upload their custom aircraft to their webspace and provide download capabilities.Also, the task would rightfully be delegated to the individual clients (fgfs) rather than making this really an issue for the server itself.

>How? whose FDM updates should be taken as real by the server?I was thinking of a direct, peer-to-peer connection between those who joined with the same callsign. The computer of the person who joined first will have the task of handling the FDM. The control parameters from others will be send to this computer.

>It is basically a good idea to keep callsigns unique. But>another client trying to join with an already used callsign>will have no chance to notice that. It will simply get no>packets from the server and say "This crap does not work".>Unfortunatly there is no kind of "handshake" between server>(or another instance of fgfs) and fgfs. And there is no way of>communicating with other clients either.>But these things can be changed, if someone is willing to>modify the networking code of fgfs.Well, unfortunately there were already far too many unsuccessful attempts to properly redo the multiplayer code in FlightGear. Basically, anybody who ever started this challenge, even seemed to have started from scratch rather than looking at existing code, ideas and discussions.So, I'm afraid that any new attempt to hardcode multiplayer support would ultimately also turn out to be hardly maintainable.Hence, the best approach would probably be to look at the total picture:Several users and developers have repeatedly mentioned a strong interest in adding UDP support to the XML configurable protocol subsystem. So, if UDP support was indeed added, it could become pretty simple to implement UDP based protocols by using a dynamic XML encoded format, and thereby implementing the multiplayer protocol using XML.It would mainly come down to abstracting the differences between the various requirements, that way FlightGear would ultimately end up not only supporting XML configurable UDP protocols for all types of purposes, but its own multiplayer system could also make use of this very feature and the code would suddenly become easily and conveniently maintainable and extendable.On the other hand, a more advanced multiplayer subsystem with all its logics and features could probably be hardly implemented easily using XML only. However, theoretically one could add scripting support to these XML encoded PropertyLists, too - that way FlightGear's scripting language Nasal could ultimately provide the logics where necessary.Ultimately, this task is also much more straight forward than redoing the whole multiplayer system statically, simply because it would mainly involve:- add UDP support to XML configurable protocols- implement current hard coded protocol using a XML file- possibly add scripting support to said XML files

>Several users and developers have repeatedly mentioned a>strong interest in adding UDP support to the XML configurable>protocol subsystem. So, if UDP support was indeed added, it>could become pretty simple to implement UDP based protocols by>using a dynamic XML encoded format, and thereby implementing>the multiplayer protocol using XML.But UDP is supported in the XML configurable protocol subsystem, as documented in README.IO. It's ascii only. I guess that it's more efficient, at hight speed, to blast binary data than to blast ascii data.

>>Several users and developers have repeatedly mentioned a>>strong interest in adding UDP support to the XML>configurable>>protocol subsystem. So, if UDP support was indeed added, it>>could become pretty simple to implement UDP based protocols>by>>using a dynamic XML encoded format, and thereby implementing>>the multiplayer protocol using XML.>>But UDP is supported in the XML configurable protocol>subsystem, as documented in README.IO. It's ascii only. I>guess that it's more efficient, at hight speed, to blast>binary data than to blast ascii data.Yes, sorry - it should have read "full UDP support", indeed talking about support for binary transmissions. Sorry about any misconceptions.Usually, you simply won't want to implement an UDP protocol based on ASCII transmissions.

>However, the solution to this problem could be as simple as>adding a corresponding XML tag to the aircraft definition>files that provides information about where a corresponding>aircraft (package) can be obtained from, i.e. something like:>>http://www.flightgear.org/aircraft/a320.bz2>>at the top of the main *.XML file for each aircraft.>>That way, all aircraft that may not be available on certain>clients could be easily downloaded by other clients using the>corresponding URL to it.This would provoke other issues. What if the source link isn't active anymore or 2 clients use the same plane but provide different source tags? Someone with a malicious mind could provide a link to a huge file and the client would download tons of garbage etc.We end up with tons of error correcting code.>So this would be a pretty convenient workaround because it>wouldn't necessarily have to rely on flightgear.org and its>mirrors, but would rather also enable individual users to>upload their custom aircraft to their webspace and provide>download capabilities.I think it would be more appropriate to simply disallow client-to-server connections from clients using experimental (i.e. planes not include with the base package) planes. Of course there should be a message stating that this client is actually ignored.

>There are two ways for fgfs to>survive:>>1) simply ignore a client with an unknown airoplane>2) render a default airoplane>>So 1) would be the first choice to use.I agree with method 1) since I'm used to let programs discard what they don't know. It's easy, it's error proof, it keeps things working when possible and doesn't even try to when not shure. Roberto

>>However, the solution to this problem could be as simple as>>adding a corresponding XML tag to the aircraft definition>>files that provides information about where a corresponding>>aircraft (package) can be obtained from, i.e. something>like:>>>>http://www.flightgear.org/aircraft/a320.bz2>>>>at the top of the main *.XML file for each aircraft.>>>>That way, all aircraft that may not be available on certain>>clients could be easily downloaded by other clients using>the>>corresponding URL to it.>>This would provoke other issues. What if the source link isn't>active anymore the most reliable source for such aircraft tarballs would probably be flightgear.org or any of its mirrors, to ensure that aircraft are indeed being made available generally.So, it would require max. ~20 lines php script to simply allow something like:http://www.flightgear.org/aircraft.php?ac=c172ppossibly also using arguments to search for a specific version or even do a CRC calculation to ensure identical aircraft tarballs:http://www.flightgear.org/aircraft.php?ac=....0&crc=xxxxxxxxThe script could then reply with any matches or a corresponding error message. After all this would not need to be over engineered at all - it would merely be ONE possibility to allow users to conveniently obtain missing aircraft.>or 2 clients use the same plane but provide>different source tags?Well, a simple checksum would again come in handy.But all aircraft under $FG_ROOT/Aircraft are assumed to have unique names anyway, that is their respective names could be used to track down identical aircraft that are mirrored in different locations.>Someone with a malicious mind could>provide a link to a huge file and the client would download>tons of garbage etc.thinking about linking to libcurl or similar libraries, it would be very straight forward to allow users on the CLIENT side to configure "trusted" mirrors and maximum file sizes/bandwith usage for any such downloads.For example, as a FG user I could definitely expect FlightGear.org and its mirrors to contain only valid tarballs - downloading from other non-trusted webpages would then be up to the individual user.Apart from that, a CGI based solution would optionally even provide the possibility to request only the 3d models themselves to be downloaded from the corresponding tarball, that way it would of course not be usable by the user, but the multiplayer system would only have to download some small files and could easily render the model. Basically, one could even apply generic textures to such models, too.>We end up with tons of error correcting code.well, there's no such thing as 100% perfection, but as long as one is willing to make a few assumptions and generalizations it could be kept pretty simple:- only FlightGear.org and its mirrors are automatically "trusted"- allow users to configure not to download tarballs > xxx kbytes- aircraft are not guaranteed to be available via flightgear.org>>So this would be a pretty convenient workaround because it>>wouldn't necessarily have to rely on flightgear.org and its>>mirrors, but would rather also enable individual users to>>upload their custom aircraft to their webspace and provide>>download capabilities.>>I think it would be more appropriate to simply disallow>client-to-server connections from clients using experimental>(i.e. planes not include with the base package) planes. Of>course there should be a message stating that this client is>actually ignored.right, as a beginning that makes of course sense and simplifies the whole thing extremely:- allow only aircraft that are officially available at flightgear.org to be used for multiplayer purposesthis would also ensure that they have a certain development status and can be considered "usable".however, later on it might be worth to consider some of the other features - or at least allow the server to be configurable enough to dynamically adjust such requirements, so that people can set up their own servers to play with their own aircraft.