[Flightgear-devel] multiplayer patch #3
Hi List, I released a new patch which can be found here: http://www.o-schroeder.de/fg_server/mp-os3.patch It is mainly an intermediate patch. I've restructured the network code. You can savely remove the following files from src/Multiplayer after the patch: multiplayrxmgr.cxx multiplayrxmgr.hxx multiplaytxmgr.cxx multiplaytxmgr.hxx They are implemented in the new files multiplaymgr.hpp and multiplaymgr.cpp The cleanup is not finished yet. Please submit the patch to cvs. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jpeg-factory in simgear and flightgear
Am Thursday 27 October 2005 16:55 schrieb Curtis L. Olson: Oliver Schroeder wrote: Hi list. I just stumbled over the jpeg-factory again. Simgear defaults to build with jpeg factory enabled, while flightgear defaults to build without it. So one either has to supply --without-jpeg-factory to simgears configure or --with-jpeg-factory to flightgears. This should be harmonised. I experienced it under Linux and didn't look into it. Maybe the defaults are correctly set under other environments. I believe the defaults are correctly set to both build without, but once you build and install simgear with it, the header file is installed so flightgear autodetects it. If you later build simgear without, that header file will still be installed and flightgear gets confused. You just need to remove the installed simgear header file for jpeg factory and you should be good from that point on. Your are right. Deleting the header file solved this problem. Just for the record, it's $(INLCUDEDIR)/simgear/screen/jpgfactory.hxx regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] jpeg-factory in simgear and flightgear
Hi list. I just stumbled over the jpeg-factory again. Simgear defaults to build with jpeg factory enabled, while flightgear defaults to build without it. So one either has to supply --without-jpeg-factory to simgears configure or --with-jpeg-factory to flightgears. This should be harmonised. I experienced it under Linux and didn't look into it. Maybe the defaults are correctly set under other environments. regards, Oliver. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Multiplayer, the next steps
Hi List, after some discussions here on the list, but most of the time on irc, I have drawn some conclusions on how to improve the multiplayer mode. So, here they are. Feel free to flame me on any part which might be awfully wrong. 1) I'm currently restructoring the network code. There will be no MultiplayTxMgr and MultiplayRxMgr anymore, but only a MultiplayMgr. That will simplify the network code alot and support sending and receiving on the same socket, which should finally avoid NAT configuration for most people. 2) Support multiplayer mode without a server in the middle. So people will be able to connect multiple instances of flightgear directly. Step 1) and 2) are already on the way and I hope to finish them in the next 2 weeks (depends on how much time I'm able to invest into it) The next steps take care of sending abitary (but well defined) properties over the wire. 3) sending properties for the carrier (Nimitz) In order to prepare flightgear to send abitary properties, I think the carrier is predestined. Everything we need is almost already there. What we need is a method in FGAICarrier which I can call from the network code and is able to extrapolate position, speed etc from network data. As far as I know, it should be sufficient to send position, speed and rudder angle. There is possibly more to say (eg. how to elect the feeder and what happens when the feeder dies etc). I have ideas on that, but we will see how to cope with that when we know how we actually handle carrier properties. 4) map multiplayer clients to AI objects Here we have a lot of things to do. At least I have to read more source code more carefully :) I _think_ something like FGAIAircraft with a few modifications might just work. So every multiplayer client should be represented as a FGAIAircraft(-derivative), which is able to fly the aircraft for a short period of time, based on the data received via network. Any help on this is very welcome. So far this time, any comments welcome, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
Am Saturday 15 October 2005 11:30 schrieb Jim Campbell: Anyone transmitting un-encrypted data across a world wide internet (as opposed to a private intranet) needs to think ahead a little. Every hacker will be rubbing their hands with glee before trying to hit you on these ports you have just announced. A server/client or even peer-to-peer client can implement TLS/SSL fairly easily. For those with restricted firewalls you can tunnel through SSH port 22 if you want to keep it simple. Firewall/NAT configurations are difficult enough for admins to configure without having to allow special FlightGear port rules to allow access to ports on machines in-the-clear which may then get hacked thus compromising the security of everyone behind the firewall. You are addressing serveral security issues at once and suggest encryption as one solution to all possible threads. First we have to differentiate between possible security issues and provide a solution for every single issue. A hacker who wants to threaten flightgear multiplayer users can easily read the source code and may find several possible bugs he can exploit, either for a denial of service attack or for gaining access to the remote machine or whatever. Encryption does not help at all, the bugs (if there are any) are still in the flightgear source and can be exploited. Additionally the encryption itself may be buggy and can lead to exploits. In case of distributed denial of service attacks, we (either the server or a client) are on the wrong end anyway. There is nothing we can do about it at all. The only way encryption can help is, if we use any kind of authentication to participate in multiplayer sessions, to prevent unregistered users to join. Which is something we possibly will implement if there are really a lot of people joining multiplayer sessions, and too many of them don't apply to any rules. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was README.multiplayer update
Am Saturday 15 October 2005 23:45 schrieb Arnt Karlsen: ..we're not re-inventing pcproxy, are we? No, at least I surely won't. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Sunday 16 October 2005 19:20 schrieb Andy Ross: Oliver Schroeder wrote: So the server has to reread the port from the UDP header everytime it reseives new data from the client and recreate a socket for it (and clse the existing one of course). Er, no. Check the man page of sendto. :) The server only needs one socket for its whole lifetime. Of course, but this solves only part of the problem. The main problem is, that a NAT router may decide to not accept (ie. forward to the client) any packets we send back to it. It may work with more than 80% of current existant NAT routers, but it still does not work for the other 20% or so. However, I think I should implement it anyway and the remaining 20% should be able to provide a receive port (just like it is today) and manipulate their NAT config accordingly. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Freitag 14 Oktober 2005 19:28 schrieb Andy Ross: James Turner wrote: This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing This is a mischaracterisation. All consumer NAT routers of which I am aware do automatic port forwarding of UDP connections. The problem you are having is a misfeature in the MP server. It should be replying to the source port address, and not to a hard-coded standard UDP port on the client (which may have been munged by intervening routers). Properly done, UDP works just like TCP -- the client connects to a well-known port on the server and the server replies to the same connection. No client port needs to be specified. You are basically right. But nevertheless it isn't that easy and I try to explain why. The server receives a packet from a client and can read the senders port from the UDP header and start sending back data to the client using the ip and the port to the client. But what happens on the server side is: the server opens a socket fo the client using clients IP/port and stores the scket into an internal list. Whenever the server wants to send data to this client, it reuses the stored socket. So far, everysting is fine. If the server uses the port from the UDP header, everything works, without alterating anything on the firewall. Most of the time... The NAT router will create a temporary IP/port combination for the client, and this combination is what the server will see when receiving data. The server assumes that this combination will not change. But this assumption is wrong, especially with UDP as there is no connection. So the server has to reread the port from the UDP header everytime it reseives new data from the client and recreate a socket for it (and clse the existing one of course). That will result in multiple create/close socket operations per second for every client. And that will simply result in multiple already in use errors per second. You can argue that you've never noticed such NAT behavior, and you are possibly right. But it will really only work with a so called cone NAT router, which will make IP/port combination persistent. Interesting reading, although not directly connected to this discussion, is: http://gnunet.org/papers/nat.pdf regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A revised README.Joystick.html
Am Friday 14 October 2005 10:23 schrieb [EMAIL PROTECTED]: At the company where I work as an IT guy if we update someone's work we add ourselves as the author so that people can see who are the authors and ask questions about the document to the new author also. So It was not my intention to dusrupt the copyright or do it wrong but I just did what I thought was right. Maybe I was wrong I'm sorry. How do you guys do this? Then I'll adapt to that. The correct way is to leave copyright and author statements untouched and simply add a line with edited by John Doe, 11/10/2005. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 10:37 schrieb James Turner: It would be better to pick a port range that is entirely unused, for two reasons: There is no unused range of ports, but see below. - I think there's an implicit assumption that if the TCP port is well- known, the UDP port is reserved for your use I take well known as a well defined term, refering to ports 1-1024, assigned by the IANA. In that case your assumption is wrong. It is either defined or not used. All other ports (1024) are free for use for any application. All we have to take care about is, that these ports are unlikely used by other applications at the same time. A good example of what will _not_ work is using port 6000+ for incoming connections, since it is used by X-Servers. - This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing; a much better approach is to have a 'try UDP, fall back to TCP approach', since TCP traversal from inside the firewall to out 'just works' with most NAT boxes. In case of multiplayer, there is no alternative to UDP. Well, there is of course, but you definatly don't want TCP for MP-data. If a user is not permitted to alter the NAT tables, he is probably not permitted to fire up flightgear as well. But I do admit, that it might be a huge barrier for a user to alter firewall rules as needed. But anyway, using a fallback mechanism leads to everyone using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. - As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and I'm sure there is other meta-info that should be reliably delivered. In case you really need a reliable transmission, there is no alternative to TCP. But there are simple ways to ensure that UDP data arrives its target. But that is out of scope here. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 13:54 schrieb Martin Spott: There are what I'd call two types of well-known port numbers. Think of common database servers for example. Nobody would chose port 5432 for their application although it's not below 1024. A fine explanation and a set of the respective files is collected here: Actually, there are 3 port ranges defined by IANA: 1) The Well Known Ports are those from 0 through 1023. - these are assigned by IANA 2) The Registered Ports are those from 1024 through 49151 - they are not assigned by IANA, the IANA lists these ports only as a convenience to the community. 3) The Dynamic and/or Private Ports are those from 49152 through 65535 - they are not assigned by IANA, and they are meant for temporary use only But anyway. It's up to the server operator to decide which port to use. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 12:54 schrieb James Turner: I simply don't agree with that statement - many Windows games offer both options, for this exact reason. The notion that using TCP for multiplayer games is inadvisable is simply unfounded in my experience. It is certainly 'conventional wisdom' that TCP is evil / bad / slow, and for sure it offers a performance and overhead cost, I don't call TCP evil / bad / slow. I just think that TCP is not usable for out purpose. Please note that I'm talking _only_ about the transmission of multiplayer data (position, actions, etc). but TCP works perfectly acceptably providing you have a faster-than- modem connection and low packet loss rates, which is the case for virtually everyone with a DSL or cable connection these days. It's a bit snooty to think that no one is using a modem connection anymore. But anyway, the discussion about TCP vs. UDP in multiplayer environments is very old (and still ongoing), and nobody can give a (serious) answer, which is valid for all environments. It simply depends on the needs of the application. A turn-based game is for sure better served with TCP. As for roleplaying games, some use TCP and others UDP. For action based games there is almost no way around UDP (well, depends on the number of users, too). In a real-time scenario TCP is a no-go. TCP is a good, solid protocol, however it simply isn't up to the task of real-time games. With TCP, even if you have received a packet, the kernel/stack will witthold that packet until all previous packets have arrived - this means that while more up to date information is available, your code may never see it until the TCP stacks decides you can. This may include a 3-second retransmit timer in the case of lost packets. Back in the days of QuakeWorld and Tribes 1, for sure this was more critical, but we've using nothing but plain TCP in WorldForge for years, in a interactive environment, and the response is pretty good. For sure we will move the 'lossy' position update data to UDP in the future to get smoother updates, but it's purely an optimisation, and we will always keep TCP as a fallback, since so many people are NATed. I hope you don't plan to mix UDP/TCP transmission. It sounds tempting to send updates via UDP and use TCP for serious data. But you will end up with frustrating timing problems and funny effects within your virtual world. So my perspective is that amount of code added is trivial, the usability benefit is high, the people who can make UDP work see no change, and a large group of people who previously would be completely unable to use MP can give it a go. The only real argument against UDP is the firewall configuration issue (at least in our case). Btw, good reading on the subject is the source code of Quake3 and John Carmacks comments on it (especially the network part of course). Have fun, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 16:03 schrieb Curtis L. Olson: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I hope we don't need to change anything code-wise I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. Actually I was thinking about VoiP applications which can be used as real comms. I'm not familiar with multimeadia things and thought /dev/dsp is used directly without any wrapper which then blocks other applications. However, I will try to use some sound daemons. But does it work on all supported plattforms? regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Am Thursday 13 October 2005 16:33 schrieb Martin Spott: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: which would be a good start. So we have voice ready to use now, even if we currently have to set up frequencies (channels) manually. I was planning (and therefor testing) to use a point-to-point VoiP client, sending data to fg_server, which knows about a players position and can know players frequencies, so it can send VoiP-data to all clients in reach. But, as said, this needs more thoughts and testing. Meanwhile I think, that your approach is more suitable (and usable!) now. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible MP Server problem
Hi, Am Monday 10 October 2005 00:28 schrieb Lee Elliott: I had problems at first with FGMultiplayRxMgr not being able to bind the receive socket but I was still able to see myself on the web map display at pigeond.net That normally means, that another process is already using the port. Note that you can use any port you want. Once I seemed to get connected properly, and saw a message about Vivian being 'initialised' on my terminal I then found that I couldn't start the engine on any of the _single_ engined YASim a/c I tried. Multi-engined a/c would start ok but I don't know yet if they caused Vivian any problems. That is strange. Can you verify that everything is working if you are not connecting to the server? The message initializing USER... means, that you are correctly connected to the server and receive data for the remote user. I'm still not sure if I was connecting properly because it was displaying me as [EMAIL PROTECTED] instead of showing my IP address, which I suspect has something do with IP masquerading. The map shows what the server sees. [EMAIL PROTECTED] means, that the user Lee is connected to the server you are querying. On pigeons map you can select which server you want to observe. If you switch to o-schroeder.de while connected to pigeons server, you will see [EMAIL PROTECTED] (the IP of pigeons server). That is because my and pigeons server exchange their user data, so that both servers see one world. That is possibly changing in the future, but that's the way it is atm. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
Am Monday 03 October 2005 23:00 schrieb Ampere K. Hardraade: On October 3, 2005 07:35 am, Melchior FRANZ wrote: (C) which features need to be completed? MultiPlayer. Currently, the MP still lacks the capability to transfer animations or radio messages across the network. However, since MP can boost FlightGear's popularity immensely, we should get these aspects of the MP sorted out, so that we can advertise loudly about our mutliplayer capability. I'm personally very content with a new release at the current stage of development (regarding MP functionality), since MP is basically working now. We should make sure that it is really working on all supported plattforms and stick with it for now. The next steps for Multiplayer are huge and have to be discussed with the community first, which I will start in the next few days. cheers, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Am Tuesday 04 October 2005 09:26 schrieb George Patterson: The cockpit view of other planes need to be fixed. For those that aren't aware of it. If you view another players/pilot's plane, you only see the cockpit panels and perhasp part of the tail or insignia. This is because the property list isn't send over the network. I think I have explained it right. I was not aware that it is possible to switch to another clients cockpit. However, if this really depends on properties which get not transmitted over the network yet, we should disable this in the upcoming release. Sending properties over the net is more complicated than sending some values. I will address this in a seperate thread in the next days. Also can we add a ping function to flightgear which requests the server to send a packet back to the user's client. This will make is easier to debug people's MP setup. The MP server will not send the player's packets back to itself, fair enough decision except if there is only one player connected. I'm not sure what we gain if you (fgfs respectively) can ping the server. If you only want to debug the transmitted data you can simply connect 2 clients directly, without a server in the middle. Note that you can only connect 2 clients directly, not more. If you only want to know if the server recognises your (or any other) connection, you can simply telnet to the server and see the list of it's clients. The telnet port is commonly CONNECT-PORT +1. cheers, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] type conversion problem for amd64
George Patterson wrote:
Could you test the latest version in CVS, there was some restructuring
of this code and I think this is solved now.
Erik, I hate to to say it but No cigar, same problem, same errors :-/
I'm not quiet sure what changed.
George Patterson
In simgear/source/simgear/misc/stdint.hhx:
old ---
#if (SIZEOF_LONG_INT == 8)
inline void sgEndianSwap(unsigned long int *x) { *x = sg_bswap_64(*x); }
#else
inline void sgEndianSwap(unsigned long long *x) { *x = sg_bswap_64(*x); }
#endif
--- old ---
should be changed to
--- new ---
inline void sgEndianSwap(uint64_t *x) { *x = sg_bswap_64(*x); }
--- new ---
the same applies to:
inline void sgEndianSwap(unsigned short *x) { ulEndianSwap(x); }
inline void sgEndianSwap(unsigned int *x) { ulEndianSwap(x); }
which should be:
inline void sgEndianSwap(uint16_t *x) { ulEndianSwap(x); }
inline void sgEndianSwap(uint32_t *x) { ulEndianSwap(x); }
regards,
Oliver
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Am Mittwoch 21 September 2005 10:23 schrieb Erik Hofman: AJ MacLeod wrote: Swapping #include byteswap.h instead of tiny_xdr.hpp I get exactly the same result here.. That's odd. This *should* indicate that it still would work with our own definition of these functions ??!? I'm lost here :-( The problem lies in XDR_encode_double() and XDR_decode_double(). Making all arguments const did the trick. You can find my updated version here: http://www.o-schroeder.de/fg_server/tinyxdr.tgz please test it. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Hi Erik, Erik Hofman wrote: Secondly I've updated the code to use the ulEndianSwap() function instead of defining our own (my system doesn't even define byteswap.h). There's something really odd with byteswapping. Using your modified version does not work. Using my own byteswap functions does not work. Using byteswap.h (ie. remove both bswap-functions and #include byteswap.h instead) does work. So far I did not find out what it is. I guess it is some compiler side (implicit) type conversion or something. Or I do something really stupid. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] new multiplayer patch
Hi list. I have prepared a new patch for multiplayer, which fixes endianess issues with multiplayer code. It's basically identical to the patch I sent before my vacation, but contains minor fixes. Multiplayer should now be working under all unix-like environments and windows native. The basic trick is to let configure check for endianess of the host system. It will not work on system not using configure in the build process (excluding windows), ie. possibly MACOS. For those system we should provide #ifdefs in tiny_xdr.hpp. The patch is available at http://www.o-schroeder.de/fg_server/patch.php The patch has proven to be stable during my vacation, so I suggest to put it into cvs. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] BUG: current cvs does not compile under linux
Hi list. The current cvs version of flightgear does not compile under linux. The error message is: cut g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -c jpg-httpd.cxx In file included from jpg-httpd.cxx:46: jpg-httpd.hxx:38:43: simgear/screen/jpgfactory.hxx: No such file or directory In file included from jpg-httpd.cxx:46: jpg-httpd.hxx: In constructor `HttpdImageChannel::HttpdImageChannel()': jpg-httpd.hxx:69: error: invalid use of undefined type `struct trJpgFactory' jpg-httpd.hxx:53: error: forward declaration of `struct trJpgFactory' jpg-httpd.hxx:73: error: `init' undeclared (first use this function) [...] cut A quick fix is to use an undocumented configure option: ./configure --without-jpeg-factory (this option should show up when ./configure --help is called) regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] BUG: current cvs does not compile under linux
Am Sonntag 18 September 2005 11:03 schrieb Oliver Schroeder: A quick fix is to use an undocumented configure option: ./configure --without-jpeg-factory Ok, another fix is to configure simgear: ./configure --with-jpeg-factory So, the defaults in configure should be changed. Either for simgear or for flightgear. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
Hi. [EMAIL PROTECTED] wrote: Hi all! Yes, I know this topic has already been discussed and I know also that someone of you is working on the FG multiplayer code... anyway I think that it will be an advantage to the FG comunity to interface to IVAO and/or VATSIM networks. To implement VATSIM at least one of us has to sign a Non-Disclosure Agreement, which is simply a no go. One way to provide compatibility with other simulations and improve multiplayermode in general is e.g. DIS (Distributed Inteactive Simulation) protocoll, or HLA (High Level Architecture) or similiar. However, Flightgear isn't ready to implement such protocolls due to lack of nessecary infrastructure. Other clients in multiplayer mode are not part of the simulation, they are only displayed. Flightgear has a long road to go, before real protocolls can be implemented. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] multiplayer patch for enianess
Hi, I've written a patch that _should_ solve issues with endianess in multiplayermode, which can be found at: http://www.o-schroeder.de/fg_server/patch.php Please try it out. Multiplayermode will still be broken on non IEEE-encoding platforms (eg. Motorola 68XXX, vax, some DEC-alphas). Since I have no access to those machines I can't help it. If you have such a computer you may be able to provide the nessacary information (ie. internal representation of floats/doubles), so I can fix this, too. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Andy Ross wrote: Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. The term binary is in fact not precise enough in this context. We need a way to encode the data in a host independent format, regardless of what data is send. XDR is a generalization of functions like ntohl(3) and htonl(3). If we implement it ourself with exactly what we need, it isn't bloated at all. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. I don't understand exactly what you mean here, but as mentioned above: XDR is just an encoding standard for data. We can send whatever data we want and we should think about what data should really go over the wire. But that's a different story. Regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Mathias Fröhlich wrote: On Mittwoch 27 Juli 2005 14:55, Vivian Meazza wrote: It's a quick and dirty hack. Oliver and Norman are working on a proper fix. It compiles on gcc 3.4.4-1. If Cygwin users want to use multiplayer, then this patch allows it. It certainly should not find its way into cvs. With help from Norman I fixed the alignment in the used headers. The patch is available at http://www.o-schroeder.de/fg_server/patch.php But this patch again fixes only symtoms, not the problems. I suggest to put it into cvs anyway, as it will enable the majority to get experience with the multiplayer mode. Norman, Oliver, you might be interrested in that xdr stream implementation I have attached. Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission is the way to go, as it will fix problems with endianess and platforms not using IEEE-format for floats/doubles. That way multiplayer mode will even work on a VAX ;) I will look into it next week. Where this implementation is not 1000% waterproof (long doubles cannot work in the way they are implemented), it might serve as a very good starting point. Long doubles are not used, at least in multiplayer code, so this should not be an issue so far. More interesting is, if it will compile on the different platforms. I'm considering looking at XTL, too. (see http://xtl.sourceforge.net/) Any comments welcome. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Vivian Meazza wrote: This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked under Cygwin. Norman Vine did a bit of quick diagnosis last night, and came up with a cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as standard. Apperantly gcc under cygwin uses a different alignment for structs than gcc under linux (I don't know which gcc version is used under cygwin). At home I use gcc 3.3.6, and it reports: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 120 Under cygwin it reports: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 124 I attach Norman's diff against cvs/head. Norman tried to get cygwin do the same alignment which other gcc do. That's this (commented out) _attribute_ thing for, but didn't succeed. So he made an ugly hack which let you use multiplayer-mode anyway. But this hack fixes symtoms, not the cause. I don't have the right anwser, either. We must check this out and improve the used structures and their alignment. greets, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns in Viewport
Paul Kahler wrote: All this multiplayer chat stuff has me thinking game. It would probably be more in line with simulation if chatting took place on a simulated radio. You'd not only have to be close enough to someone, but you'd have to be on the same frequency in order to talk to them. The idea of having little on-screen identifiers might be OK as long as it can be turned off. I really like that FGFS focuses on simulation and not game play. If you want to be highly realistic, mutiplayer voice chat with proper radio frequencies would be ideal. Bandwidth might be a problem for large groups, but small ones should be no problem. Of course it's much more complicated too ;-) This should'nt be too hard to implement and I was thinking of it already. Most of the needed functionality can be ripped out of sox, see http://sox.sf.net There are only a few steps to get 'real' radio working: 1) recording voice input from a microphone into a buffer (for radio 8KHz, mono should be sufficient) 2) encode the buffer with any codec to save diskspace and network bandwith 3) wrap the encoded buffer by a (fgfs-) network header, containing position, frequence and range. The range reflects power of the sender, a tower has a greater range than a pilot in his cessna. 4) the receiver decides wether to play the received data or not based on position, frequence and range. 5) decode and play the data Recording and playback functionality should be part of plib's sound library (i.e. only the recording part has to be added). The de-/encoding can be done by any selfmade routine. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 10:46 schrieb Vivian Meazza: Oliver Schroeder I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. Yes FG is big, and would have unused functions. Against this has to be balanced the time and risk in developing and maintaining a stripped down version. I don't have a handle on the size of that task or the risks involved. I didn't mean to develop or maintain another version of FG, i guess an appropriate configure can do the trick. Something like configure --without-opengl --without-ATC ... I suggested some time ago that the first player's system might handle all the admin tasks - that way you get the AI traffic, carrier movements etc. virtually free. However, there are significant questions surrounding that idea: in particular what happens when the first player leaves. It ought to be possible for the 2nd player to take up the task, because both systems should be aligned. There is also the load on the individual client to be taken into account. I guess this will raise more problems then it will solve. That's why I thought of injectors. They are (read: would be) player independent. I'm not sure exactly what you mean by a scriptable client. Does this mean that it has pre-scripted AI traffic, carrier movements, weather etc.? Something like that, yes. If you are saying that the server should have as little knowledge as possible, then I would go along with that. I think the server probably needs to coordinate the network time but beyond that ... there is a case for the server to filter by range, but this could also be done by the client. The idea is to disburden the clients as they will already have enough work to do with rendering etc, especially with a gowing number of additional clients at the scene. I have no strong view on how this should be achieved. We should build on what we already have in order to achieve a fully coordinated environment. We should not be re-inventing wheels, flaps or anything else :-) Dacor, I'm always a friend of recycling ;) Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 20:14 schrieb Andy Ross: Josh Babcock wrote: Right, it would be silly to send all that data to the server when all it needs to know is where your are and what you can see. Plus the position data could be sent at low resolution. The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. This way your wingman always gets updated, and a burning/turning dogfighter will get frequent updates, but a jetliner moving in a straight line is nicely optimized and receives very few updates. You can also handle orientation error this way, by giving the object a radius and figuring that a 180 degree orientation different produces an error of that size. I am sure that I don't understand this. Anyway: Sending updates based on importance would improve rendering of nearby objects, as a client would get more/better information of objects of its interrest? In that case: can the server decide what is important to a client? Either way the server would have to be able to handle multiple instances of the same callsign. Otherwise an invisible observer could silently prevent a flier from connecting. Better would be to assign a prefix or suffix to duplicate callsigns, so that the second andy to connect becomes _andy or andy-0, etc... Actually the server doesn't care much about callsigns. It simply checks Sender-Callsign == Currentplayer-Callsign and Sender-IP == Currentplayer-IP (Currentplayer = current player when walking through the list of clients) and thus preventing sending packets back to the sender. Also, I'd suggest defaulting the callsign to the USER (unix, cygwin) or USERNAME (winnt) environment variables where available, to avoid the problem of zillions of identical flightgear-user planes flying around. Sane defaults are always good. This should be easy to implement in the client. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 19:27 schrieb Harald JOHNSEN: Oliver Schroeder wrote: 1) out of reach [...] I think the range should be user configurable. So it's possibly a good idea to include a similar check in the flightgear client. The server does a precheck, i.e. does not send packets from clients which are for sure out of reach, and flightgear decides for itself if it is worth building up a property tree and display the other client or not. This would mean that flightgear is capable of building a property tree on the fly. But that way we can improve the multiclient capability of flightgear. It does not need to do any rendering of clients which are not in sight, but can bravely display them eg. on radar. The other way would be to implement special network packets which tell the server the, erm, range of reach of the client (and possibly other values which might be usefull). But for these packets we need a data-received-confirmation mechanism to make sure the server really got that value(s). 2) chat messages [...] As Pigeon said, make that a separate window, because the ATC line is allready nearly impossible to read ;) It should not be hard to code but the atc code is not good for that (anyway it does not queue messages). I don't think it's a good idea to handle chat messages in another way then messages from ATC (or any other type of conversation). There should be one interface for all types of messages and every module (currently ATC and maybe chat messages in the near future) should use it. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: Oliver Schroeder 3) artificial life at airports [...] Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding knowledge to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 03:46 schrieb Pigeon: I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. I was thinking about oberservers, too. So it will be possible to build radar stations (human operated) and tower controll etc, without disdurbing the other clients (which would try to render the observer). Using the callsign observer to mark observers is possibly the best approach for the moment, as it will work with the current client (unless there are more then other 10 clients). But then again the question about reach arises. Does an observer only get information about clients in its reach or about all clients connected to the server? For generating a map of current clients connected to the server this way is not appropriate. The map generator would have to listen some seconds to the server in order to get information of (hopefully all) clients. A better way is to implement some kind of admin protocol in the server based on TCP rather then UDP to get (and maybe set, too) information on connected clients. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
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_mesgforum=198topic_id=913mesg_id=934page=) 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
[Flightgear-devel] suggestions/questions regarding multiplayer
Hello List, some of you may already have taken notice of my multiplayer server for flightgear (http://www.o-schroeder.de/fg_server). It's working quite well in sane environments but I want to improve it and therefor have some questions you may be able to answer. 1) out of reach The server receives position information of clients and thus should be able to calculate the distance of two given clients (measured in nautical miles, disregarding height) so it is able to decide if it has to send packets to a client or not. In case it is out of reach, i.e. all actions of client A do not affect anything for client B, the server can stop sending packets between those two clients. So it is possible for the server to handle hundrets of clients even though each client does only see a couple of them (at least if the clients are scattered around the world). So the question is: How can I easily calculate the distance and how many nautical miles are out of reach (thinking of e.g. radar systems) ? 2) chat messages The server (in fact every client) should be able to send messages to clients which get displayed on the screen (i.e. the flightgear window), just like ATC messages. So the server can send state information to the client. After reading some source code and discussing this on the irc channel I've noticed that the necessary infrastructure is already there but not used. The network protocoll supports chat-messages and the ATC-module has functions to queue and display them on screen. So it should'nt be too hard to combine them and enable chat-messages. Somebody willing to give it a try? 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's own airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. so far, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 13:43 schrieb Pigeon: Also I'm wondering if the server should take control of who's logged on and off. At the moment the client is taking care of that by adding a player if it gets udp packets that it doesn't already know about, and removing player if it hasn't got anymore packets from a player with a timeout. I thought of the server generating a chat message like Player1 joined the at KSFO or something, spreading it to the clients which display it to the user. And possibly other messages which reflect the state of the server. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
