"As I understand it, usually there is one master port for the initial
connection and a range of ports, one of which is used by each client after
the initial connection is made."
This assumption holds true when dealing with Sockets based Network Code, and
even DX7 DirectPlay netcode. However, it does not hold true with DX8 or
moreso in F12001 (which as far as I can tell without having a direct look at
teh netcode source, it is actually a TCP/UDP hybrid config.).
*Normally* a game will attempt an initial connection with the server/clients
on a timed TCP packet loop (DirectX for example uses a 32 second timeout
value inherit in Windows TCP protocol... hence explaining why it usually
takes about that long before a game will send back a "could not find host"
message.) If that timeout is reached... Windows assumes the host is
unreachable, or is non-existant at the specified IP address. The
fundamentals of how this works is inherit to the TCP protocol, which is a
"guaranteed protocol". Meaning, TCP will cause the client machine to "wait"
until a reply is recieved. This is a good method for "mission critical
packet retrieval", but has costly time issues associated with it. Initial
connection and menu screen navigation is such an area where "time loops" do
not *usually* cause any timeouts, so the guaranteed nature of the TCP packet
is best suited.
Once a TCP connection is made (the original handshake), the game *usually*
uses UDP packets to send game data (since UDP does not wait for a timeout
value... it simply sends and forgets, and whether it reaches the host is
irrelevant [in UDP]). UDP is better for sending game data, since the client
machines do not have to wait for a reply (this is compounded in session
where there are people 500ms away from each other). If a game were to use
TCP packets, it could take 2-3 seconds for each packet from each client to
be "verified". Thus, the lag caused would be extreme.
Condensed: The game will create the initial connection and participate in
Menu-Screen communications through the TCP protocol, and send the positional
data, etc. through the UDP protocol *usually*.
This was fine and dandy in DX7 (which used a port range of 2300-2400 for
game data) and still is in Sockets based netcode, but DX8 now only uses 1
port to send/recieve data. That port is 6163. ALL info is sent through that
port now. Thus making any "Proxy Configs" completely useless, and indeed MS
suggests that you do not use proxies/routers for DX8 Net-based games. This
is because of the fundamentals of how an NAT/Proxy system works. It applies
to the basic rule that only 1 computer can occupy a port mapping at 1 time,
and a specific rule must be in place to solidify this mapping. In a sockets
based netcode, you are capable (if the programmers think ahead) of selecting
which ports you would like to use. Thus, (like in GPL core.ini settings) you
can have different clients using different ports, and map those unique ports
accordingly and successfully in your Proxy Soft/Router.
The #1 issue with online *** (spanning all genres), is player
syncronization. In a LAN environment, you are pretty much guaranteed 99%
packet retrieval. This is due to simple proximity of the computers. However,
in the infinitly unstable (and thus unreliable) beast we call the Internet,
connections are not always (in fact rarely) this cut and dry.
TCP can "verify" retrieval, but has costly timing issues associated. UDP is
a "send and forget" protocol which negates the "timing issues", but
compounds the "quality issues". Meaning, if a number of packets sent are NOT
retrieved by the host, the host can quickly lose syncronization with the
offending party/client. They can "pick up" where they left off once a packet
does arrive, and this is seen visually on the screen as cars "hopping" or
"instant appear".
Now we move onto getting F12001 playable through a Proxy/Router.
Bottomline: Pick a computer to race with... thats the only one you've got
online.
Once you have picked the computer... make it a DMZ computer on your Proxy.
We have found F12001 to be "random" in its port selection (GAWD I WISH it
was at least static 1791, but our investigations have proven that to be
untrue). Meaning... intial connection is done through 6163. However, F12001
will then pick a random port to use for data-transfer. The port sync is
accomplished through the 6163 initial connection, port open/sync is
accomplished, and away you go.
However, we throw a router/Proxy in there, and its next to impossible, since
we know that F12001 uses "random ports". Our experience is that it seems to
like ports between 1000 ~~> 8000, and so far we have not had problems. You
cannot select the ports, do not know a static port, which makes playing
behind a proxy/router on anything other than a DMZ computer, futile.
Alisson, you mentioned that you use Sygate. I would HIGHLY suggest dropping
that and going with Winroute (http://www.racesimcentral.net/) It is worlds
easier to configure, is much higher performing, and is overall just a better
package (I especially avoid Sygate like the plague... horrible
implementation of NAT, and problematic is an understatement...).
We have done up a Network Guide that explains how to properly map your ports
in Winroute at: http://www.racesimcentral.net/
Its also worth noting that Relay can be configured to use proxies and
routers using a variety of methods inside the Network Options.
Hope that helps.
Cheers,
Schumi
