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. :)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.)
--
+
+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.
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
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:
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
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
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
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
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
24 matches
Mail list logo
