Proposed Net Fix

[Hooman]

Hmm, that definately indicates a problem somewhere, and not where I expected. I see two IP addresses in that log mapping to the same player number. Mind you, the issue might only be in the logging code. If those messages are from pre-game setup, then that might make sense.

Did the game play properly?

I'll look into this, but it might not be today.
 

[Hidiot]

The game simply hangs at start up and players are lost.

[Hidiot]

More examinations!

Here's an example:
In a 3 player game, everything ok, apparently:

Player 2 uses port 1
Player 3 uses port 2
Port 3 is 47800

Packet from player 2 ((AF:2) IP1:1) recived on unexpected port (1 instead of 2)
Packet from player 3 ((AF:2) IP2:2) recived on unexpected port (1 instead of 2)
Packet from player 2 ((AF:2) IP1:2) recived on unexpected port (2 instead of 1)
Packet from player 0 ((AF:2) IP1:2) recived on unexpected port (2 instead of 3)
Packet from player 0 ((AF:2) IP2:1) recived on unexpected port (1 instead of 2)

Apart from recived instead of received, there's a noticeable changing of ports between addresses, although the ports stay the same.

I'm not sure it's any useful as extra information, but I thought it was worth a try.

[Hooman]

Hmm. I'm wondering how accurate that port scheme is. It looks a bit odd. You didn't make any typos did you? It seems like ports are being exchanged between players with what you wrote.

I've attached an update:
I updated the logging code slightly to produce more filtered results. It shouldn't print anything if the expected port is 0, which basically means it doesn't know what port to expect yet. I also added some code to output the source player net id. This would be particularly helpful if compared with the "Replicated Players List" section. If that section is not printed, then that is something useful that I need to know. I remember you saying something about having a fairly empty log file. Mine looks like this when joining a game:

[NetFix] ProtocolIndex = 3
[NetFix] GameServerAddr = 68.146.111.58
Search for games: (AF:2) 68.146.111.58:47800
Hosted Game Search Reply: (AF:2) 68.146.111.58:47800
Sending join request: (AF:2) 68.146.111.58:60052
  Session ID: {93e37d88-9413-428b-a96d9c4cf03ebd79}
[NetFix] GameServerAddr = 68.146.111.58
Replicated Players List:
 0) {2, (AF:2) 68.146.111.58:60052, [8586824.0]}
 1) {2, (AF:2) 68.146.111.58:60067, [8591808.1]}
 2) {0, (AF:2) 0.0.0.0:0, [0.0]}
 3) {0, (AF:2) 0.0.0.0:0, [0.0]}
 4) {0, (AF:2) 0.0.0.0:0, [0.0]}
 5) {0, (AF:2) 0.0.0.0:0, [0.0]}

[Hidiot]

Whilst I was sleepy, I made pretty sure to get the numbers correct.

And it's not the first time I've noticed ports being exchanged like that. I've still got an old log I could modify to show precisely the switching in ports (as above).

I'll have more people test with this new version. I really hope the problem can be found and fixed.

[Hidiot]

Ok, we have this new little piece of information.

log. txt said I was using port 1 (not giving the actual port).
The host got an unexpected port number. The line said that it was expecting the packet on the host's port, but it received it on port 1.

Also, the line  also said it was Player 0 who was at fault (me in this case).

Should Player 0 be used normally?

[Hooman]

I'm not sure I understand what you're saying.

If you're not comfortable posting your log file, you can always PM it to me.

Although, I should mention that the port numbers are random anyways, aside from the default 47800 for hosting. I really don't see any security reason to not post it. If you're truely paranoid, you can wait 5 minutes or so to make sure the router will timeout any mappings and remove them, but nothing would likely be listening on those old ports anyways once you're done playing.


Also, the player list section of log.txt would be helpful with this stuff. It tells me how many people were playing, and clearly identifies player ids, IP addresses, and ports.
 

[Hooman]

Slight update here. I added an external address display (IP:port). It will also provide a warning in one specific case where it knows something is definately wrong with your router setup.

This is a feature extension, not a compatability change, so you can continue using older clients. The servers were updated to support the new feature, but will function like before if it's not used.


For people that know they have trouble, I would appreciate if they checked if the problem is detected by this code. It should add a message after the external address in that case. The external address should appear within a second or so of opening up the multiplayer window (the one that lets you join or host a game).
 

[Hooman]

Update attached.


This is a small fix that sets the source player net ID on outgoing packets, which previously could be left uninitialized.

This fix should prevent wild port tracking changes. This will probably improve connectivity issues, and possibly fix some potential lag caused when port tracking is wrong. It should also remove the mass of port tracking change events that are generated in the log file.


Additional events are now logged. If you encounter problems, the additional logging may help determine the source of the problem.
 

[TH300]

I tried the new NetFix in a few games (two 1v1, one 3 players). Games with 2 players work fine when I host (with "ForcedPort" set). Hosting without "ForcedPort" set doesn't work, not even with a direct internet connection.

In games with 2 and 3 players I'm getting many lines like "Received packet with bad sourcePlayerNetID" in logHost.txt.

In the 3 player game I also got "Packet from player 2 ((AF:2) <IP1>:<PORT1>) received on unexpected port (<PORT1> instead of <PORT2>)  [PlayerNetId: <ID>]". The bad thing is that "player 2" sometimes has IP1 and sometimes a different IP2 (which really belongs to the third player). The 3 player game desynced after ~10 minutes and recovery was impossible.

I am sending you the log files in a pm. Unfortunately I have only the host logs.

[Hooman]

Thank you for the log files. They do look interesting.

Do you know if the other players were using updated NetFix clients? It may be related to the repeated bad sourcePlayerNetID messages in the logs. I should probably version tag the output files somehow.

If the other people also send their logs, that could end up being really useful. No one node will really know everything, so having data from multiple nodes can help. Although, just having this one log is quite helpful.


The distinction you've made between 2 and 3 players games is interesting.


I'm wondering a little about the time frame over which those messages were logged. Perhaps I should consider adding a time stamp to the messages. Also, perhaps the log files themselves could be tagged for each game rather than appended or overwritten. Could use the current date, or perhaps the GUID of the game session. That would help for collecting logs from multiple players.


I'll need a bit of time to work with this.
 

[Hooman]

I'd like to bump this topic, especially considering some of the Hamachi changes I've heard about. Have people tried this patch? How has it worked?


After going over the previous log files in more depth, it appears that perhaps not all players were using the latest patch. The current version should be backwards compatible, in that older clients should work as they did before, but that also means the benefits of the latest patch may not be realized unless everyone in the game has upgraded.



Edit:
Ok, subbed74 and bmenrigh have helped me do some testing, and no problems were logged or occurred during our tests. I did a couple of 2 and 3 player games with subbed (who was using two computers from the same IP address), each of us taking turns being the host, and then a 3 player game with all of us. We checked the logs between every game, and everything showed up clean.

I would be very interested if people who have had trouble with the patch in the past could report how things work out when all players have the latest patch, and how many players were in the game. In particular, there are certain problems that are unlikely to crop up until you have at least 3 players. Any reports, positive or negative would be appreciated.
 

[TH300]

Recently, I played some games over NetFix and made the following observations:

1. Hosting doesn't seem to work (for me and others), unless the Host uses the "ForcedPort" option and forwards that port to his computer. Furthermore, if non-Host players use that option (even if they forward the port), they're unable to join (more precisely: they can join, but will immediately stop responding).

2. I played a few games with 3 or more players without any trouble.

3. When playing with Highlander, things didn't work so well and we encountered the same problems that I already described: 2 player games work, 3+ player games don't.

All players were using the very latest NetFix (November 2011). And no, I don't have logs, this time.

[Hooman]

Hmm, good to know. Those problem characterizations may prove useful.

Lack of logs probably isn't a big deal. The last set of logs you sent me turned out to be more puzzling than helpful. It's made me think perhaps I need to add additional logging or something. I remember fighting with the logging code a bit after that.


I've been thinking of ways to possibly remove the ForcedPort option. I believe there are ways to get around using it, which may help simplify the problem. In hindsight, part of the network code relating to that is more complicated than it needs to be.
 

[CK9]

You more than likely already thought of and did this seeing as you are far more experienced than I am, but did you set up error classifications for the log to show in order to spot anything that you might not have accounted for?

[Hooman]

The logging was done in a very manual way, just writing what seemed like it might possibly be of interest to the log file. There wasn't so much data that sorting through is was impossible. It was more likely that something possibly important simply wasn't logged.


So far I've found Outpost 2 runs under Wine, but the minimize, maximize, and close buttons don't work. I've had to resort to editing the ini file to change the window size. Also, the menus have an odd themed title, which matches the native OS feel. Not so much progress on any network code though. But at least it seems I can run and test things from Linux.
 

[TH300]

You can disable the native window decoration by running "wine winecfg" in a terminal and disabling the checkbox that allows the window manager to decorate Wine's windows. I don't know how to make the minimize and maximize buttons work, but I find virtual desktops a rather good means to work around that issue.

I've been thinking of ways to possibly remove the ForcedPort option. I believe there are ways to get around using it, which may help simplify the problem. In hindsight, part of the network code relating to that is more complicated than it needs to be.

As long as some people can only use NetFix with port forwarding, the ForcedPort option should be kept. Otherwise port forwarding will be impossible, because there's no way to tell which port Outpost 2 will use.

Its been some time since I've looked at the NetFix code, but there has to be a way to fix the issue without removing that option.
 

[Hooman]

Its been some time since I've looked at the NetFix code, but there has to be a way to fix the issue without removing that option.

Yes, always attempt to bind to a know port. If it fails, ignore the error and continue on, thus grabbing a random port.

As having a random port makes port forwarding somewhat tricky, the user should probably be informed of what port they have, and possibly get a warning message if the bind failed. Joining should work with a random port, and hosting may also work, depending on router filtering settings.

Most likely though, the bind would succeed, and they would be hosting on a known port. In that case they would just setup port forwarding in their router, and probably wouldn't need to muck with any ini file settings.


Currently there's some mucking about with two different ports. It wasn't until after I'd written it that I realized using just a single port, and treating bind failures as non-fatal would probably have worked at least as well, if not better.
 

[Arklon]

Most likely though, the bind would succeed, and they would be hosting on a known port. In that case they would just setup port forwarding in their router, and probably wouldn't need to muck with any ini file settings.

Or somebody could've bothered to implement UPnP port forwarding

[TH300]

It is very well possible that a certain port cannot be forwarded (but another can). Just imagine the case where two players are behind the same NAT.

So, using a single port is still a good idea, but it should remain customizable via an ini option.

[Hooman]

So, using a single port is still a good idea, but it should remain customizable via an ini option.

I agree, and for the exact example you mentioned.

But I plan to rename the ini option to something simple like "Port", or possibly allow a range of ports to be specified. Using a range of ports would be nice because they can start up both copies from the same install folder, and each instance can just bind to the first port that's available.


UPnP might be nice. I'd have to look into how to do that though. I assume there is some kind of Windows API for that?