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
Oliver Schroeder wrote: Andy Ross wrote: 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 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. I think the ratio is more like 1000:1, honestly. I have never seen a piece of consumer hardware that is broken in that way. Is there a particular model you are worried about? Note that most internet games would also fail across such a device, so it would be unlikely to be successful in the marketplace. The whole idea of port forwarding is to enable exactly this kind of code. Simplicity is important. Junk the connected socket and just use recvfrom/sendto, you will be much happier. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
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. Andy ___ 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] [PATCH] README.multiplayer update
On 14 Oct 2005, at 08:33, Oliver Schroeder wrote:Finding the "right" port isn't easy, since we have about 32 thousand (64 thousand on newer OSes) to choose from ;) However, I decided to use port 5000 on the server-side (and 5001 for telnet), both ports are configurable but these are the defaults. Both ports are only used by the free internet chess server (fics), which uses tcp. The udp ports are not used, yet. (AFAIK) Although a client can choose any incoming port he prefers, my personal predilection is to use the same port as used for outgoing. (=5000) It would be better to pick a port range that is entirely unused, for two reasons:- I think there's an implicit assumption that if the TCP port is well-known, the UDP port is reserved for your use- 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. (One solution to using UDP is to implement Microsoft's UPnP system for asking the firewall to set up a dynamic port forward, but we looked at doing that for WorldForge and it's horrible. Really big spec. Nasty.)- 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.HHJames-- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ___ 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
On Fri, 14 Oct 2005, George Patterson wrote: [snip] Gawd, I don't belive that I am commenting on a patch. Thanks for your comments! (I'm having similar feelings every time I am sending a patch, esp. to a minor thing like the docs...) I'm fairly certain that the selective positioin forwarding based on the players' position is already in the logic of the FG server. This was fixed in 0.0.6 of FG server. Here is an addition against the current CVS (I also threw in the GPL-ness): Index: ../data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.2 diff -u -p -r1.2 README.multiplayer --- ../data/Docs/README.multiplayer 13 Oct 2005 13:42:35 - 1.2 +++ ../data/Docs/README.multiplayer 14 Oct 2005 10:31:32 - @@ -58,13 +58,13 @@ For use with a server: -- Oliver Schroeder has created a server for multiplayer flightgear use. The server acts as a packet forwarding mechanism. When it -receives a packet, it sends it to all other active players. -Future versions might be more scalable, only forwarding information -on the planes in the receiving player's vicinity. +receives a packet, it sends it to all other active players +in the vicinity (the server is configured to use 100nm by default). Check out the server homepage http://www.o-schroeder.de/fg_server/ for the current status. You can either download the server for -some local use, or join the developers on the existing servers. +some local use, or join the developers flying at the existing servers. +As with flightgear, the server is free software, released under GPL. Pigeon http://pigeond.net has created a web page monitoring two such servers, showing the traffic in a Google map environment. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On 14 Oct 2005, at 10:27, Oliver Schroeder wrote: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. 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, 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.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.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. Anyway, I'll resume lurking now.James -- Java is, in many ways, C++-- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
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. Why are we talking about 6000 anyway? The README.multiplayer never talked about anything except 5000-5002 and 5500-5501 AFAIK. 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. Hear, hear. If a user is behind a firewall and can't have it configured the way he wants for the UDP traffic to come through, it's a problem of the user's relations with the local admin and/or the ISP. 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 Are you talking about the textual ATC datalinks in the modern cockpits? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Oliver Schroeder wrote: Am Friday 14 October 2005 10:37 schrieb James Turner: - 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. 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: http://www.sethwklein.net/projects/iana-etc/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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] [PATCH] README.multiplayer update
On Freitag 14 Oktober 2005 15:20, Oliver Schroeder wrote: 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). Well, UDP is just aprioriate for realtime applications. Professional simulation codes I know combining real hardware together with simulations together in a single loop, use udp or udp like protocols. Where with 'udp like', I think of protocols just pushing the data onto the wire and not waiting for an ack of the other side. Whatever you may experience with tcp in *your* special case, the only way to *guarantee* that you will not block or hang the simulation because of lost ethernet frames which will past a timeout be retransmitted and block the stream for that whole time, is *not* using tcp. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
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. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Vassilii Khachaturov wrote: Sure. Here comes a new version, with an explicit further reading. Thanks Vassilii, I've committed it to CVS. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wed, 12 Oct 2005 02:27:08 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 ..this works ok with X in lan's? (X uses port 6000 too.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
+ +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Thu, 13 Oct 2005 22:36:43 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. ..aouch. Ok, the first X session on any box will use port 6000, the next 6001 etc, similarly 5900, 5901 upwards for vnc etc. ..how about putting the server on 5500 like we have done, and commandeer 5501 upwards for all clients? (Assuming they're vacant? Excluding non-FG app ports, I suspect METAR fetches has an established procedure, with ports and all.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wed, 2005-10-12 at 20:22 +0200, Vassilii Khachaturov wrote: Sure. Here comes a new version, with an explicit further reading. Index: ../data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.1 diff -u -p -r1.1 README.multiplayer --- ../data/Docs/README.multiplayer 21 Aug 2004 08:57:29 - 1.1 +++ ../data/Docs/README.multiplayer 12 Oct 2005 18:19:50 - @@ -54,19 +54,72 @@ is the sort of implementation that we ar visual simulator. -For use with a server (when one is created): - +For use with a server: +-- +Oliver Schroeder has created a server for multiplayer flightgear use. +The server acts as a packet forwarding mechanism. When it +receives a packet, it sends it to all other active players. +Future versions might be more scalable, only forwarding information +on the planes in the receiving player's vicinity. Gawd, I don't belive that I am commenting on a patch. I'm fairly certain that the selective positioin forwarding based on the players' position is already in the logic of the FG server. This was fixed in 0.0.6 of FG server. Apart from that the rest looks good. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Thu, 2005-10-13 at 23:30 +0200, Arnt Karlsen wrote: On Thu, 13 Oct 2005 22:36:43 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. ..aouch. Ok, the first X session on any box will use port 6000, the next 6001 etc, similarly 5900, 5901 upwards for vnc etc. ..how about putting the server on 5500 like we have done, and commandeer 5501 upwards for all clients? (Assuming they're vacant? Excluding non-FG app ports, I suspect METAR fetches has an established procedure, with ports and all.) Better would be server on 5000, with the telnet admin port on 5001. I'm not sure of the benefit of each client having it's own port. (Perhaps i have misread something) George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wednesday 12 October 2005 01:27, Vassilii Khachaturov wrote: I've updated README.multiplayer to reflect the recent changes. I'm not addressing the released/cvs incompatibility issue in there, hopefully this is fine. You might also note that there's an up-to-date multiplayer howto on the Wiki which should provide a little more help for those who need it... save us trotting out the same old routine on the IRC channel... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
I've updated README.multiplayer to reflect the recent changes. I'm not addressing the released/cvs incompatibility issue in there, hopefully this is fine. You might also note that there's an up-to-date multiplayer howto on the Wiki which should provide a little more help for those who need it... save us trotting out the same old routine on the IRC channel... Quoting the Wiki multiplayer docs at http://www.seedwiki.com/wiki/flight_gear/flightgear_multiplayer_documentation.cfm?wpid=203209 This document can be found at http://www.o-schroeder.de/fg_server/ Please check there for later versions. I did point to the latter URL though. Do you think I should point to the Wiki from the README.multiplayer as well nevertheless? Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wednesday 12 October 2005 16:30, Vassilii Khachaturov wrote: Quoting the Wiki multiplayer docs at http://www.seedwiki.com/wiki/flight_gear/flightgear_multiplayer_documentati on.cfm?wpid=203209 This document can be found at http://www.o-schroeder.de/fg_server/ Please check there for later versions. As far as I know that comment's wrong - I wrote the Howto that's on the wiki and it isn't on OS' site as far as I can see (his site points to the wiki entry). I'll remove the comment from the Wiki for the sake of clarity unless anyone has reason to object? I did point to the latter URL though. Do you think I should point to the Wiki from the README.multiplayer as well nevertheless? Definitely - the howto covers quite a few things that have been tripping up an awful lot of people without requiring a very great deal of knowledge of networking issues, etc - which is why I wrote it :-) Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Sure. Here comes a new version, with an explicit further reading. Index: ../data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.1 diff -u -p -r1.1 README.multiplayer --- ../data/Docs/README.multiplayer 21 Aug 2004 08:57:29 - 1.1 +++ ../data/Docs/README.multiplayer 12 Oct 2005 18:19:50 - @@ -54,19 +54,72 @@ is the sort of implementation that we ar visual simulator. -For use with a server (when one is created): - +For use with a server: +-- +Oliver Schroeder has created a server for multiplayer flightgear use. +The server acts as a packet forwarding mechanism. When it +receives a packet, it sends it to all other active players. +Future versions might be more scalable, only forwarding information +on the planes in the receiving player's vicinity. + +Check out the server homepage http://www.o-schroeder.de/fg_server/ +for the current status. You can either download the server for +some local use, or join the developers on the existing servers. + +Pigeon http://pigeond.net has created a web page monitoring +two such servers, showing the traffic in a Google map environment. +See http://pigeond.net/flightgear/fg_server_map.html. + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player1 Player2: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5501 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player2 -Playern: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5502 ---callsign=playern +... -The server would simply act as a packet forwarding mechanism. When it -receives a packet, it sends it to all other active players. +PlayerN: +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 +--callsign=playerN + +Note that if every player using a particular server, such as one of those +listed on the Pigeon's page, needs to have a unique callsign, not +already in use on that server. + +If you are sitting behind a NAT'ting firewall, then you need to forward +the incoming traffic on the firewall outer (visible to the internet) +address arriving at the UDP port you use (5002 in the case above) +over to your private LAN address. In this case, use your PRIVATE LAN address +as myaddress. Example (if your private LAN address is 10.0.0.1, +in order to play on pigeond.net): + +fgfs --multiplay=in,10,10.0.0.1,5002 --multiplay=out,10,pigeond.net,5002 + --callsign=...UNIQUE callsign here... + +If you and the server are in the same address space (i.e., both have a public +IP address or both are on the same private LAN), you hopefully don't need to +mess with any firewalls. + +If you don't see other players playing on the same server in your flightgear, +check that you have followed the above router configuration guidelines. Check +that you don't have any LOCAL firewall running on your computer preventing the +flightgear network traffic flow. + +Finally, use ethereal(1) or tethereal(1) to capture the UDP traffic on the port +that you are using, and see if you observe both incoming and outgoing packets. + +It's a good idea to talk to the IRC channel #flightgear on irc.flightgear.org +while flying on one of the public servers. Also, it makes sense for every user +on the same server to use the same weather setup, e.g., the real weather +METAR feed, selected by setting to true the real-world-weather-fetch and +control-fdm-atmosphere properties. + +Further reading (a must if you have a problem): +--- +[1] The flightgear server homepage http://www.o-schroeder.de/fg_server/ +[2] The flightgear wiki multiplayer howto http://www.seedwiki.com/wiki/flight_gear/flightgear_multiplayer_documentation.cfm +[3] If everything else fails, ask for help on +the IRC channel #flightgear on irc.flightgear.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] README.multiplayer update
I've updated README.multiplayer to reflect the recent changes. I'm not addressing the released/cvs incompatibility issue in there, hopefully this is fine. Index: data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.1 diff -u -p -r1.1 README.multiplayer --- data/Docs/README.multiplayer21 Aug 2004 08:57:29 - 1.1 +++ data/Docs/README.multiplayer12 Oct 2005 00:23:45 - @@ -54,19 +54,65 @@ is the sort of implementation that we ar visual simulator. -For use with a server (when one is created): - +For use with a server: +-- +Oliver Schroeder has created a server for multiplayer flightgear use. +The server acts as a packet forwarding mechanism. When it +receives a packet, it sends it to all other active players. +Future versions might be more scalable, only forwarding information +on the planes in the receiving player's vicinity. + +Check out the server homepage http://www.o-schroeder.de/fg_server/ +for the current status. You can either download the server for +some local use, or join the developers on the existing servers. + +Pigeon http://pigeond.net has created a web page monitoring +two such servers, showing the traffic in a Google map environment. +See http://pigeond.net/flightgear/fg_server_map.html. + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player1 Player2: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5501 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player2 -Playern: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5502 ---callsign=playern +... -The server would simply act as a packet forwarding mechanism. When it -receives a packet, it sends it to all other active players. +PlayerN: +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 +--callsign=playerN + +Note that if every player using a particular server, such as one of those +listed on the Pigeon's page, needs to have a unique callsign, not +already in use on that server. + +If you are sitting behind a NAT'ting firewall, then you need to forward +the incoming traffic on the firewall outer (visible to the internet) +address arriving at the UDP port you use (5002 in the case above) +over to your private LAN address. In this case, use your PRIVATE LAN address +as myaddress. Example (if your private LAN address is 10.0.0.1, +in order to play on pigeond.net): + +fgfs --multiplay=in,10,10.0.0.1,5002 --multiplay=out,10,pigeond.net,5002 + --callsign=...UNIQUE callsign here... + +If you and the server are in the same address space (i.e., both have a public +IP address or both are on the same private LAN), you hopefully don't need to +mess with any firewalls. + +If you don't see other players playing on the same server in your flightgear, +check that you have followed the above router configuration guidelines. Check +that you don't have any LOCAL firewall running on your computer preventing the +flightgear network traffic flow. + +Finally, use ethereal(1) or tethereal(1) to capture the UDP traffic on the port +that you are using, and see if you observe both incoming and outgoing packets. + +It's a good idea to talk to the IRC channel #flightgear on irc.flightgear.org +while flying on one of the public servers. Also, it makes sense for every user +on the same server to use the same weather setup, e.g., the real weather +METAR feed, selected by setting to true the real-world-weather-fetch and +control-fdm-atmosphere properties. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
