rec.autos.simulators

Detailed technical question about GPL multiplayer

Andrew Lavign

Detailed technical question about GPL multiplayer

by Andrew Lavign » Sat, 17 Oct 1998 04:00:00

Hi.

Does anyone out there (maybe even someone who had development
involvement)
know the exact sequence of events that occur when connecting to a GPL
server?
I'm trying to finally resolve the problem of connecting to a GPL server
behind a
gateway (in this case, my linux gateway).  I know that a GPL server
listens for
UDP connections at port 32766 (or whatever), and then, according to what
I've
read here, "gives a host-assigned port for communications with the
client".  I'm
looking for something a bit less vague.  For example, is the
host-assigned port
number given back in a UDP reply to the source IP/port that sent the
connect
request to port 32766?  Or does GPL send a reply back to a different but
well-
defined port to the source IP (that the GPL client would know/expect)?
And
I assume that the port that is sent back is a port on the Server that
the client must
use?  Or is it something else?

If enough details like this are known , then I think that a combination
of IP masquerading
and IP port forwarding in linux should be enough to allow at least 1 PC
behind
a linux gateway to serve as a GPL server.

Having some sort of message flow diagram would be nice, too.  Like this:

GPL Client                                          GPL Server
1.2.3.4                                                5.6.7.8
--------------------------------------------------
Send GPL-Client-Connect-Request-------------->
to 5.6.7.8:32766 from
1.2.3.4:xxxx

                                                        Send
GPL-Client-Connect-Request-Response
<------------------------------------to 1.2.3.4:xxxx (contains port
                                                        number 'p' for
client connection)

Send GPL-Client-Connect----------------------->
to 5.6.7.8:p from
1.2.3.4:xxxx

<------------------------------------Send GPL-Client-Connect-Response
                                                        acknowledgement
to 1.2.3.4:xxxx

GPL-Client-Data----------------------------------->
to 5.6.7.8:p

<-------------------------------------GPL-Server-Data to
                                                          1.2.3.4:xxxx

etc.....

anyway, let's get this ball rolling, and then all of us with private
networks attached
to the net will be able to connect to and host games (I've noticed a few
other people
out there with the same setup as myself).

Any help appreciated...
...Andrew

Randy Cassid

Detailed technical question about GPL multiplayer

by Randy Cassid » Sat, 17 Oct 1998 04:00:00

SERVER: Open a datagram socket (LISTEN).
SERVER: Bind socket LISTEN to port 32766 (by default) on specified IP
address.
CLIENT: Open a datagram socket (C).
CLIENT: Bind socket C to port 0 on specified IP address.  Specifying a port
of 0 asks the system to choose an unused, untrusted port number (i.e. a
port number > 1024).
CLIENT: Using "sendto", spit a datagram at port 32766 on the server's IP
address.
SERVER: Sees datagram on socket LISTEN.  Extracts port number and IP
address of the client that sent the datagram.
SERVER: Open a new datagram socket for this client (CLIENTn).
SERVER: Bind socket CLIENTn to port 0 on the IP address over which the
server just received this datagram.  This causes the system to choose an
unused, untrusted port number for this socket.
SERVER: Connect socket CLIENTn to the port/IP address of the client.
SERVER: Spit a datagram at the client.
CLIENT: Sees datagram on socket C.  Extracts the port number and IP address
of the server from the datagram.
CLIENT Connect socket C to this port/IP address.

It's a bit more complicated, but that's the general idea.
The client now talks to the server on socket C.
The server now talks to client N on socket CLIENTn.
The server only uses socket LISTEN to listen for new connections.  This
behavior mirrors the "listen"/"accept" functionality that is available with
stream sockets, but is unavailable with datagram sockets.  I used this
mechanism because it's logical, efficient, and matches our multiplayer and
communications architectures perfectly.  I'm investigating ways to maintain
this paradigm, but make it easier to connect through a gateway/firewall.

Randy



Andrew Lavign

Detailed technical question about GPL multiplayer

by Andrew Lavign » Sat, 17 Oct 1998 04:00:00

Great.  Thanks for the info, Randy.

...Andrew


> SERVER: Open a datagram socket (LISTEN).
> SERVER: Bind socket LISTEN to port 32766 (by default) on specified IP
> address.
> CLIENT: Open a datagram socket (C).
> CLIENT: Bind socket C to port 0 on specified IP address.  Specifying a port
> of 0 asks the system to choose an unused, untrusted port number (i.e. a
> port number > 1024).
> CLIENT: Using "sendto", spit a datagram at port 32766 on the server's IP
> address.
> SERVER: Sees datagram on socket LISTEN.  Extracts port number and IP
> address of the client that sent the datagram.
> SERVER: Open a new datagram socket for this client (CLIENTn).
> SERVER: Bind socket CLIENTn to port 0 on the IP address over which the
> server just received this datagram.  This causes the system to choose an
> unused, untrusted port number for this socket.
> SERVER: Connect socket CLIENTn to the port/IP address of the client.
> SERVER: Spit a datagram at the client.
> CLIENT: Sees datagram on socket C.  Extracts the port number and IP address
> of the server from the datagram.
> CLIENT Connect socket C to this port/IP address.

> It's a bit more complicated, but that's the general idea.
> The client now talks to the server on socket C.
> The server now talks to client N on socket CLIENTn.
> The server only uses socket LISTEN to listen for new connections.  This
> behavior mirrors the "listen"/"accept" functionality that is available with
> stream sockets, but is unavailable with datagram sockets.  I used this
> mechanism because it's logical, efficient, and matches our multiplayer and
> communications architectures perfectly.  I'm investigating ways to maintain
> this paradigm, but make it easier to connect through a gateway/firewall.


1. GPL end of practice question, multiplayer

2. GPL Multiplayer: Cable Modem on Network question

3. Details, Details, Details!!!!!!

4. GPL - technical question

5. In my defence, or details, details, details

6. Details, Details, Details! (was 1967 Mustang Hard Top)

7. Technical details for M38A

8. Why is that automakers won't provide detailed technical info over internet

9. Technical details (pin-out definitions) for Volvo external audio amplifiers?

rec.autos.simulators is a usenet newsgroup formed in December, 1993. As this group was always unmoderated there may be some spam or off topic articles included. Some links do point back to racesimcentral.net as we could not validate the original address. Please report any pages that you believe warrant deletion from this archive (include the link in your email). RaceSimCentral.net is in no way responsible and does not endorse any of the content herein.