Communication over only one predefined port

[ryan]

The entire network code system needs to be overhauled; here's how it currently works:

Each client connects directly to each of its peers, selecting a random port to use for communication. This results in a user needing to be either in the DMZ or using Hamachi or a similar VPN client to correctly connect to other clients, since firewalls are everywhere now.

Here's how it should work:

Each client connects directly to each of its peers, selecting only one single port for communication. This port is defined somewhere (registry for now I guess) and is configurable by the user. Now, each user only needs to forward one port for the game to work correctly.

This will entail adding some sort of 'player-id' onto each packet sent.

Ready, set, go.

[ryan]

Status update (yes, I have been working on this):

The client now sends UDP requests to port 3951, but for some reason the other clients are not accepting these packets. The hack itself is done by setting all the UDPRecv structs in each MR_NetworkPort to the same one (listening on port 3951) which is also stored in the MR_NetInterface. The MR_NetMessageBuffer had an 8-bit 'mClientId' field added to specify which client was sending the packet.

It doesn't work yet, but I'm getting there little by little.

[ryan]

Status update:

Clients successfully connect to each other during the pre-game connection phase. However, when the game is started, clients immediately disconnect. Client IDs are probably getting mixed up somewhere.

[ryan]

Status update:

It seems clients sometimes hold a connection, and sometimes they don't. At random the client ID seems to be bizarrely wrong. I have seen a game work properly between two clients but cannot figure out why it does not work sometimes as of yet.

By the way, I'm not putting nearly as much time into this as I really should. This is my first attempt debugging this problem since my last status update...

[ryan]

My attempts at fixing this are found in r144. I will shortly upload a compiled debug version for those who want to test this but do not have a working build environment. If you manage to crash it, it will probably be a "Debug assertion failed!" and I need to know the file and line number where it crashed.

This also needs testing for many clients (more than 2) to verify that it all works fine. I currently don't have enough hosts to do that (I need one system per instance since I didn't bother making the port configurable yet).

[ryan]

Eh, max attachment limit 256k. That'll teach me to read.

You can find a zip file containing everything you need at

http://www.igglybob.com/hoverrace/debug-one_udp_port-r144.zip

Unzip it into C:\Program Files\HoverRace (or wherever you installed it).

[ryan]

Forgot to mention -- the UDP receive port is 9531, so you must make sure UDP port 9531 is forwarded on your machine if you are behind NAT. This should work without the need for Hamachi provided the server has port 9530 also forwarded.

[ryan]

3 client games do not work; however, 2 clients can connect to each other and race apparently flawlessly.

[ryan]

r151 changes a FALSE to a TRUE and apparently allows games with 3 clients. It should work for up to 10 clients. Needs testing!

http://www.igglybob.com/hoverrace/debug-one_udp_port-r151.zip

Unzip it into C:\Program Files\HoverRace (or wherever you installed it).

[ryan]

r152 changes a simple constant and forces the TCP receive ports to be one specified port (port 9531). Now all traffic should be funneled through ports 9530 (for the server) and 9531 (clients). I tested this with one box behind a firewall and another box out in the open.

I will test a couple other cases in the future, with multiple clients, but everything worked correctly between two boxes. Missiles fired correctly, no random crashes.

Here is a link if anyone else wants to test:

http://www.igglybob.com/hoverrace/debug-one_udp_port-r152.zip

After further testing I will merge this branch back into trunk and HoverRace 1.23 should be very close to release (finally).

[ryan]

Testing discovers that a client behind a NAT reports its internal IP; then, another client trying to connect to it (using the client list given by the server at initial connection time) tries to connect to an internal IP, which only works if that system is also on the internal network. Fix: clients no longer report their own IP. (todo)

[Austin]

If a connecting player is on the same network as the host, and the host reports an internal IP, then potentially if the host was responsible for dishing out the client IP's, he'd tell everyone to connect to the internal IP?

Not sure if that makes sense, but that seemed to be the jist of how you planned to make it work Iggly :).

[ryan]

Yeah, that is an issue. I am not quite sure how to deal with that right now. But what I will implement will do this: when a client recieves a list of other clients to connect to, the list will include 2 IPs: the IP that the client reported and the IP that the server saw. The connecting client will first try the IP the server saw, and if that fails it will try what the client reported.

The real solution for this problem is to have each client communicate only with the server, but for now this hack will let us release 1.23.

(getting to work now)

[ryan]

r154 merged back into trunk, this solves everything except for what is documented in #57.