Proposed Net Fix

[Tellaris]

Its up and running. Most of the bugs have been worked out. Just follow the instructions, and go nuts!
If you're looking for other players, because we still use MIRC as our main chatline, you'll have to get it. Hooman is looking at a method to remedy the need to gather on IRC, but it will be some time before he can complete it.
Hes a bit busy right now, so the project's on hiatus.

[Hooman]

Actually, I'd never much planned to integrate chat into the server. I was thinking of listing other online players, but not chat.

There were a few reasons for the decision. One is mainly that I don't want to spend that kind of time working on it. Another is that IRC is used for more than just game chat, and I don't really want to kill it's use, nor do I want to force people to load up the game, and chat through some inferior chat software. But then, I hear Ham has chat, and there's no apparent downside to that (or much of an upside?). Maybe it'd be worthwhile for gamers setting up games, but I probably wouldn't bother until a version 2 or something. Afterall, you'd at least need an online players list before you can consider chatting.

Btw, I've pretty much finished toying with my other side project, so furthur delays on this will mostly be due to laziness.



Oh, and for those that might be curious, the game server has so far used about 365 KB of bandwidth since whenever it was put online. (Check the date a few posts back). During that time, 42 hosted games were listed, of which 32 were cancelled before starting (testing?), and 10 were actually started. Ok, so it doesn't seem to be too hot for people finding games so far. Most of the bandwidth seems to have been used by update requests from people staying connected to the server while idle. (The bandwidth requirements are pretty much nothing, but then so is usage. Wondering if I should consider increasing the timeouts to reduce the number of updates).
 

[Sirbomber]

I'd only bother integrating chat for the purposes of sending messages to people in-game to make it more WONish, but can anybody think of anything that's really so important it can't wait until after a game? And people can always just check IRC during the game.

And I think the server hasn't received much use because it's still new and the word isn't really out yet. I thought it was still limited to 3P games until Tellaris corrected me on that issue. Don't get discouraged Hooman.

[Tellaris]

That and it'll receive far more use if Hacker decides to integrate it into the install, more permanently, and less mod-like

[Hidiot]

Should I have the time I'll start playing again and this'll be what I'm going to use.

Sadly... I might only have time during Easter or in June...

[Sirbomber]

Easter was last week Hidiot.
But yes, you should probably re-add the old Internet button and have it do this instead of replacing the hacking what the Serial button does.

[Hidiot]

Easter was not last week, depending on the country you're in    

[Hooman]

The server was down for a while. The machine lost power for a short while and restarted. I never set it to auto restart or anything, so it was down since whenever that was. It's been manually restarted. Guess I might as well keep it running. No real reason not to. Although I hadn't really planned on leaving the test version up for so long.


Btw, I still haven't gotten around to fixing that symmetric NAT issue (if "fixing" is even the right word). Most routers use a different form of NAT, so this doesn't affect everyone with a router, and it definately doesn't affect anyone without a router. Currently it seems people with symmetric NAT can host games (but not with joining through the server) if they have port 47800 UDP forwarded. Otherwise people with symmetric NAT will need to play games over Hamachi. The patch can work using Ham addresses, provided they are entered manually. The game server won't work on Ham, since the server itself is not on Ham and it tries to inform clients of external addresses, and so it won't list games as hosted on Ham IPs. Also, the patch does no checking to see if everyone is using Ham, or everyone is not using Ham. If some, but not all players are using Ham, then it'll probably drop people as soon as the game starts. If one of the players has symmetric NAT, it should also cause people to drop immediately at game start.


Does anyone think it might be worthwhile to put a game server running on a Ham connected computer?


Edit: Just noticed the server IP has changed to: 68.146.114.178
(Yes, it's on a machine with a dynamic IP address)
You'll have to make the adjustment in the Outpost2.ini file for the game server address.
 

[Sirbomber]

That dynamic IP could cause problems if you aren't around to tell us about changes Hooman.

So when is this going to be included in a new OP2 patch/update (presumably adding the Internet button back to the multiplayer menu)?

[Hooman]

Yeah, I don't plan to continue running the server on that machine. This is just a testing phase. I made the server IP easily changable by putting it in Outpost2.ini for a reason.


There aren't any specific plans to add the button back to multiplayer yet. Probably have to bug BlackBox a little more. It should probably be an easy edit though. I just specify the button index to hook it, so we'd just need to make that old button visible again, and change the text on it.


Also, I still haven't gotten around to a few planned symmetric NAT fixes. I was thinking if they just setup port forwarding, that should be enough. Currently it will work if they're the one hosting (direct, not through the server), but it won't otherwise. Still, I've only run into two players so far with this issue.

[Sirbomber]

So, how much use has the server been getting lately?
If not much, have OPU|Bot spam an annoying message about using the new server anytime the word "game" is said. Then people will use the server just to shut OPU|Bot up.

[Hooman]

Heh, almost none.

I'm sure it'll get more use if it becomes part of the download package. Probably want to move the server first. It can't stay on one with a dynamic IP and receive general use. Maybe put it on the same machine as the forums? It compiles on at least one variant of Unix, and Windows, so hopefully it shouldn't be too hard to get running there. (Not that C++ is nearly as portable as it always claims to be).

It also needs a few tweaks. Mainly in regards to symmetric nat and port forwarding. I continue to procrastinate on these changes.
 

[BlackBox]

Ice has written an excellent guide for users who are completely lost in setting up the net fix. It has been integrated into the main site and can be found at:
http://www.outpostuniverse.net/netfix.php
 

[Hooman]

The IP has changed again. It is now: 68.146.111.58
 

[Hidiot]

So, when's it going to be static?

Not that I mind the IP changing, but I'm not the only user

[BlackBox]

Hopefully by the next OP2 update, we can work out all the kinks and host the game server on OPU's server (probably make it use DNS to figure out the IP instead of just inputting an IP, that way we can move it around in case of outages and whatnot without having to get everyone to type in a new IP).

[Hooman]

If I recall correctly, it should do a DNS lookup if the address is not in the dotted decimal IP form. It's just a matter of moving the server software to a machine with a static IP. If you're interrested in putting it on the OPU server, I can send it to you.


Which reminds me that it's not exactly feature complete. It works, but there were a few security measures I wanted to implement to prevent people from interfering with other people's games. It does do some checking, but if packets have spoofed source addresses, then you could cancel someone else's game fairly easily. There might have been a few other hardenings I was planning on too, but it's been so long I can't really remember.
 

[Savant 231-A]

you are doing some very nice work, and i have to say i am very happy because of that.

/me hugs Hooman

[Hooman]

For those who are interested, the game server has been restarted today. I made a few changes to the code to provide better logging. Some people seemed to be having trouble seeing games, so I added some logging output that should better let me determine what's going on. There are no visible changes on the client end.

For the curious, over the last 100 days or so of uptime, there was about 300 games hosted, of which 149 were started, and 150 were cancelled. The server received about 960 KB of data, and sent out about 380 KB of data. There was also 20 new games that got dropped before being listed on the server due to slow reponse time with game info.

Btw, I increased the allowed response time for new games from 2 seconds to 4 seconds, and made the server check for dropped hosts at a much slower rate. This might help prevent some games getting dropped.

The server IP is still: 68.146.111.58
 

[Hooman]

Hmm, some people have had trouble getting it to work, and I suspect they may all have been doing the same thing. The Server Address box doesn't default to the port used by the server, so you *need* to specify the port number there. I believe it defaults (if at all) to the port clients tend to host games on.


Use Server Address: 68.146.111.58:47777
when searching for games.


<Boring Story as to why>
I suppose these really should be the same. I set clients to host games on port 47800 by default, since this is the one port than anyone using previous nat patches would definately have forwarded already. This meant they could host without the help of the game server, and the needed port forwarding would already be setup. It has little relevance when hosting through the game server unless you have an unfriendly router.

The server however defaults to port 47777. I think I choose that so it wouldn't conflict with 47800 (and was a port typically used by OP2). I did it mainly because the server was running on a different computer than I played through. I didn't want to change my port forwarding settings that allowed me to play just because I was running the test server. If I forwarded port 47800 to the game server machine, then I wouldn't have been able to play through port 47800 on the other computer using the older nat patches.
</Boring Story>


Anyways, I'll probably change the server default the next time the IP changes or something. That would make it a little more user friendly.
 

[Hooman]

Old news:
Upon further examining of the source, it automatically checked the game server periodically, and on the correct port, provided you at least had the IP address set in the .ini file. Having to append the port was only needed if the .ini file was not set correctly.

At any rate, that's old info now. The 1.3.5 Beta 2 package I put together has a newer version, and port 47800 (UDP) is used for all the default ports. I'm currently running two copies of the game server at the moment. One on port 47800, and the other on the older port 47777. Note that this means people using the older version won't see the same list of games as people using the newer version. Of course, the newer version is packaged with a newer copy of Outpost 2 that isn't compatible with the older copy, so people using different versions wouldn't have been able to play anyways. Eventually I'll shut down the older server once the newer version becomes the standard (non-Beta) version.


Join now works much better, so if you had trouble joining games before, try upgrading. From what I've heard of people using it, it's working good now. Before, joining a game through the server only worked for the kindest of routers ("full cone NAT"?). Now it should work for all but the most troublesome routers ("symmetric NAT").

There have also been .ini settings added for people with problem routers ("symmetric NAT"). There is a ForcedPort setting that can be used in conjunction with port fowarding. This should allow people with problem routers to still play. Just forward a port, and set the ForcedPort line in the .ini file. Example (see last line):

Code: [Select]

[NetFix]
Dll = "NetFix\NetFixV3.dll"
GameServerAddr = "68.146.111.58:47800"
ProtocolIndex = 3
ForcedPort = 47800

There is also a HostPort parameter. This might be useful if two computers behind a router want to host games without using the game server. You can forward a different port to each of them.


The ProtocolIndex parameter is used to control which button on the multiplayer menu leads to the new network code. A value of 3 will replace the "Serial" option. The default value replaces the SIGS button, however that button is currently disabled and not visible in the current download packages. It will be re-enabled at some point, and then that line from the .ini file will be removed.


I also cleaned up a small memory leak in the older version. (Some code was left with a ToDo marker that I hadn't gotten around to implementing at the time). If games were listed when the window was closed, then the memory for the listed games wasn't freed. It was a really small leak, and of little impact. It's been cleaned up now though.


Oh, and best of all, op2ext.dll was upgraded too. There is now a new module loading system, which means you don't need to play around with making funny /loadmod shortcuts to get the new version to work. Just add a few lines to Outpost2.ini to always load new modules. This has already been setup for the current net fix in the 1.3.5 Beta 2 download package. Basically, this all works out of the box now.

[Hooman]

I've updated the NetFix code slightly. It should still be compatible with the 1.3.5 Beta 2 release. The change includes some additional logging that may help spot trouble with problem routers. There is also a small chance the updated code could fix issues in a small number of cases, which may increase the usability of the patch.


The patch will log unexpected source port numbers to the log file. People who are sending packets from an unexpected port number would have problem routers that the patch has trouble with and would need to setup the ForcedPort option along with port forwarding. These people with problem routers will appear in the log file of other players (but not their own log file), so if you experience problems, you can all check your log files to figure out where to point the finger.  

Note that you still have to receive packets from the person to detect an unexpected port number, which means your router can't be filtering on both IP address and port. It should be fine if it filters on IP address only, which is the industry recommended setting for router manufacturers. Also, if you're the game host, you will likely always receive packets on the expected port number, so there isn't much chance the host will ever detect anything.


This patch also changes the expected port number to that of the actual source port number seen on received packets. This should change the address that resent packets will go to, which could cause connection problems to correct themselves after a short delay during game startup (during which a few packets will get lost). This should increase the usability of the patch to people who had problems with it before.


Previously, the patch would fail at game start if a non-host player had a router that sent packets to different players using different port numbers. This implies at least a 3 player game. Now, the patch will fail at game start if a non-host player has a router that sends packets to different players using different port numbers, and those non-host players who receive these packets also have routers that filter by IP address and port number.

 

[Leviathan]

Nice work. Thanks

[Hooman]

Btw, please post if this works for you. I don't exactly have a pile of hardware to test this with, so I'll need a bit of help from other people. Particularly if you have a problem router. If you're using this, could you please check either log.txt or logHost.txt in your Outpost2 folder afterwards to see if there are any messages about unexpected ports.

Problems with game joining would also be of interest.
 

[Hidiot]

Yes, Hooman, yes there are problems.

I await the occasion of finding you on IRC to discuss about them. logHost has some data for you


Also, I would like to take this occasion to draw the following to attention:
The location of Outpost2.ini