Print Page - Proposed Net Fix

Projects & Development => Outpost 2 Programming & Development => Topic started by: Hooman on January 24, 2008, 11:52:36 PM

Title: Proposed Net Fix
Post by: Hooman on January 24, 2008, 11:52:36 PM

I've been having some ideas for a new net fix.

Previously, we attempted to patch a few bytes here and there to make the network protocol work from behind NAT routers. The patch dealt with the issue of the encapsulated IP, but not with the issue of ports. Basically it let people play, provided they could properly setup port forwarding. Actually fixing it so port forwarding wasn't required would have been a much larger patch.

Seems the port issue was fairly important though, as most people have resorted to using Hamachi to play. It also seemed to make patching less critical, since pretty much everyone could play now, they just needed to install Hamachi. Of course some people refuse so use Hamachi and have stopped playing, so maybe this still needs to be addressed after all.

Anyways, I think we might finally know enough about how the network system in OP2 works to actually replace the core component that is responsible for all the NAT problems, including both the IP and port translation. This can mean two things in particular. One, that unassisted, people could play direct IP, where only the game host needs port forwarding, (and only 1 port would need to be forwarded). Two, that we could design a new networking component to make use of some sort of game matchmaking system. With that in place, not even the host would require port forwarding. Basically anybody would be able to play without any configuration using the match making system, and if that ever goes down, or this site ever dissapears over time, then simple port forwarding for the host would be enough for anyone with the fix. (The fix being required by all players of course).

As for how this could be done....

At the multiplayer menu, where you choose the type of network game (TCP/IPX/Modem/Serial/SIGS), each button activates some object that takes the user through all the screens to start the network game, and in so doing, also creates the underlying network object to transport all the messages between clients, and establishes all the connections. Now this first initial object is very simple, with only 4 virtual functions, and no member variables. As such, it's very easy to replace. Also, the objects are assumed to be statically constructed, and an array of object pointers is used to access them. We could simply overwrite one of the pointers in that table to install a new object that would take the user through a different set of pre-game setup windows, and create a different network object.

Now, the game Join/Host window is fairly simple, and can be reused since it's not tied to any one protocol and it not responsible for creating any of the network objects that need to be replaced. (It already is reused by the different protocols). However the code that controls the following screens gets fairly dependent on the network component that needs replacement, and as such would probably need to be replaced as well. This would include the broadcast/search for games, and the create game screen. But since these screens sort of suck anyways, why not just replace them all? Well... ok, that's a bit much work. The pre-game setup window, where you can chat with opponents, choose color, etc., is fairly independent of the underlying network type. Once you've reached that screen, the needed network object is already created and functioning. We could just use that screen as is, since we'll need to create a network object that's compatible with Outpost 2 anyways, so we can save a bit of work here. At least for now anyways.

It would be nice to somehow combine the max player setting, and the game type with the pre-game setup screen, so the host doesn't need to abort and remake to change those settings. But that's quite a bit bigger of a project. It would also have been nice to do better checksumming of files and actually dermining who and what file is different, and it would also have been nice to allow auto downloading of missing files. But again, too big of a project for now. (Btw, definately need some sort of security confirmation before downloading any DLLs, and maybe tech tree files as well).

So, the proposed change then is to replace the object that controls the sequence of windows to setup a game, (and install that object in the required table), to replace the intermediate windows, and to replace the underlying network object that is responsible for making all the network connections where all the NAT troubles lie.

Ok, so how big of a project would this be? Well, initially I thought this could be done with a couple days of hard work, which means I've already spent about a week on it, and it'll probably take at least a month.

Currently, I've replaced the object that controls the sequence of windows, and replaced one of the table entries to install this object. I've created an intermediate window layout using the dialog editor in MSVC, and I'm able to get that displayed in game nicely skinned. There's pretty much no code behind that user interface yet, but it does pop up the pre-game setup window when you click create or join, and the cancel button will take you back. I've got just enough of an underlying network component written to keep the pre-game setup window happy and not crash or behave too oddly. Create actually makes it looks pretty normal, but join just sort of leaves it waiting to receive settings from some game host, which of course will never come because the underlying network component is not even close to finished.

Most of the work needed is in getting the new GUI to work, and writing the network protocol to search for and join games, as well as start the game (i.e., the whole "Replicating Players List" part). That will probably end up being a fairly substantial amount of code. After that, we might also consider writing some sort of game match making system.

Here's what the current intermediate screen looks like:
(in-game, skinned)
(http://www.hooman.outpostuniverse.net/images/MiscOP2/OPUNet.PNG)

(in MSVC, unskinned)
(http://www.hooman.outpostuniverse.net/images/MiscOP2/OPUNet%20(unskinned).PNG)

I was also thinking that clicking cancel at the pre-game setup window should bring the user back to this window, rather than all the way back to the main menu.

Anyways, let me know what you think of the user interface. Or better yet, if you have suggestions, make the changes yourself. I'm attaching the .rc file that contains the dialog resource. You can edit it yourself in MSVC, or any other dialog editor that understands .rc files.

Title: Proposed Net Fix
Post by: Leviathan on January 25, 2008, 07:13:22 AM

Very nice work indeed. If you want to do this project then good luck to you and im sure we all look forward to the results and information.

Ive allways thought Hamachi is a good enough fix for us and now that we have it we should spend time on other projects instead of making out own hamachi. Just my opinion tho.

But yes there are some problems with the interface such as it going back to main menu on cancel and having to go back to change the max players etc.

Looking good but I know there is a long way to go. Thanks Hooman.

Title: Proposed Net Fix
Post by: Arklon on January 25, 2008, 02:53:18 PM

Hmm... looking at the server browser, I think you should space out the window a bit more, make it bigger, and move the manual connect thing to the bottom and make it a dropdown like what's already in 1.3.4.

Quote

Ive allways thought Hamachi is a good enough fix for us and now that we have it we should spend time on other projects instead of making out own hamachi. Just my opinion tho.

I disagree. Hamachi is, quite frankly, a pile of s***. Remember the IP shuffling bug from not too long ago? Plus, the whole thing about us having to have tons of networks and having to know which network a game is hosted on (and who the host is if broadcast is broken for you), etc.

Title: Proposed Net Fix
Post by: Sirbomber on January 25, 2008, 06:17:45 PM

Hmmm...
Hamachi... WON Replacement... Hamachi... WON Replacement...
I hate tough decisions, so I'm glad this is an easy one.
I'd have to say a potential WON replacement SantaWalks all over Hamachi.

Title: Proposed Net Fix
Post by: Hooman on February 01, 2008, 02:42:59 AM

Slight update. I changed the GUI a tiny bit.

(http://www.hooman.outpostuniverse.net/images/MiscOP2/OPUNet%20(update%202).PNG)

There has also been some progress on getting it to actually work. Still buggy though, and needs more work. But, I finally got a two player game working. It hangs when I try three players though. Have to drop someone before it can continue.

The whole game server idea hasn't been worked on at all yet. But the current protocol should hopefully make that support easy to add later.

Finally, after so many days of not quite being able to get Join to work. Then a brief hiccup where game start wouldn't work. But, that was an easy fix once I got that far. Now I just have to find all my other mistakes, and why 3 player games aren't working. That and why quit didn't seem to work during the pre-game setup. The host ended up dropping the quit player for not responding. But, like I said. It's still a little buggy.

Title: Proposed Net Fix
Post by: Hooman on February 02, 2008, 05:18:34 AM

Ok, I've got a working version that so far appears to be fairly stable. I'm attaching it for anyone who wants to test. I'm using the /loadmod parameter to test it out. Copy the DLL into a subfolder in the Outpost 2 folder, say /NetPatch, and then use "Outpost2.exe /loadmod NetPatch" to load it. If you're doing this from a destop link, make sure the parameter /loadmod appears after the closing quote for the filename of the executable, as in:
"C:\SIERRA\Outpost 2 Divided Destiny\Outpost2.exe" /loadmod NetPatch
The new user interface is found under the "Serial" option in the multiplayer menu. I figured it was a good place for testing, since serial is an unlikely option for anyone to use anymore.

For the curious:
Seems I ran into a problem that I'd only ever read about previously. I had mixed New from my DLL with Delete from Outpost2.exe. It was trying to free memory from a different heap from which it was allocated. Very bad. But, it was an easy fix once I realized this and the memory problem I'd run into went away. Previously when starting games the tech file would get loaded over one of the network objects, thus corrupting it's memory. It was initially very disenchanting to see a text string over the network object, as I was fairly sure it wasn't a pointer error on my part. I wasn't exactly looking forward to debuggin that problem after all the other ones I'd gotten through. But, turns out it wasn't that bad. Plus it gave me an excuse to look a little more into new/delete. :)

Oh, and I fixed the minor bugs I had earlier. Some slight efficiency loss, but it all seems to work now. Any bugs you find I probably don't know about yet, so be sure to tell me.

It's still not feature complete though, and I may have taken some slight shortcuts along that way that might be a bit odd at first. (Like it saves the player name, and the address list when the dialog box is closed, such as when a game is starting, or even if it's closing because cancel was clicked).

Since there is no game server working yet, the host needs to have port 47800 fowarded to host from behind a (NAT) router. Nobody else should need to worry about port fowarding at all though.

Enjoy. Hope it works for you. :)

Title: Proposed Net Fix
Post by: Sirbomber on February 02, 2008, 01:35:14 PM

Well, the entire process seems much faster, now. Creating, finding, and joining games is faster, the initialization stuff is faster, and the game plays faster. But that was only with two people, so...

Title: Proposed Net Fix
Post by: Arklon on February 02, 2008, 02:11:40 PM

This seems to work using Hamachi IP's and regular IP's, even with Hamachi on and the advanced network settings fix applied. It even shows the IP's as regular/Hamachi in the in game net stats.
Perhaps you should add a status bar at the bottom of the OPU net dialog that tells you what it's doing and can tell you if something goes wrong.

Edit: It may be that the host ignores Hamachi altogether. I'll need to do some more testing (and 3 player testing), though.

Title: Proposed Net Fix
Post by: Leviathan on February 02, 2008, 06:32:41 PM

Why would the game be faster Sirbomber? Its the same network code?

Nice work Hooman.

Title: Proposed Net Fix
Post by: Sirbomber on February 02, 2008, 06:43:55 PM

Quote

Why would the game be faster Sirbomber? Its the same network code?

I'm just telling you my observations.
Try it yourself if you don't believe me.

Title: Proposed Net Fix
Post by: BlackBox on February 03, 2008, 11:43:01 AM

Quote

Why would the game be faster Sirbomber? Its the same network code?

Nice work Hooman.

It's not the same network code. The network object gets replaced.

By the way, one of the bugs I noticed, if you clicked Join and there was no game listed in the box, it caused a crash. That should be trivial to fix.

Title: Proposed Net Fix
Post by: Hooman on February 03, 2008, 03:18:17 PM

Ahh yes, thanks for the reminder.

I don't get a crash for that, but I'll look into it. I did put some code to check if a game was selected or not, but it never seemed to work. Was supposed to pop up a message box, but it never did. Since it didn't crash for me, and there were other bigger problems at the time, I just didn't bother to look into it.

The network code was replaced, so it's possibly a bit faster. I'd be surprised if it was noticable though. There's no extra layer of buffering with the network packets anymore, or stupid linked list traversals that like to touch lots of pages, so it should be a little more cache friendly. I figure if the winsock API already buffers the packets, why bother doing it myself? (There might still be unreplaced code higher up that does stupid linked list traversals like that though).

It will likely have an artifically inflated ping time during game join though. Mainly because I'm not using a seperate thread to check for and reply to certain network packets. Instead it has to wait for a timer to fire before doing any network transactions. A little sick, I know, but it was quite a bit easier than the alternatives. Plus, I definately didn't want to add extra threads for such a simple task. Seems uneeded and wasteful. Besides, you'd still have to pay for a context switch to do any network processing. Currently the timer is set to 50 ms. The ping time displayed during game join may jump by about as much as that, but it shouldn't affect gameplay at all. The timer is only used to search for games (and hence to calculate that ping time).

Oh, btw, (in regards to Hamachi testing), I noticed something about part of the network code that didn't get replaced. During pre-game setup, the clients only send packets to the host, and then the host periodically broadcasts the current game setup to everyone else. So if the host is on ham, then either ham or direct IP may be able to join the game (I'm a little uncertain), but you'll likely have trouble once a game starts if some people are using direct IP and others are using Hamachi. The people using direct IP probably won't be able to communicate with people on Hamachi. (The Hamachi IPs will be invalid to people not using Hamachi, and so they won't be able to send packets to them).

At any rate, one of the ideas behind this patch is so people don't need to use Hamachi. The only reason to use it, is if the host can't forward ports. In which case, try and find someone else who can host, or everyone should play using Hamachi.

Edit: I found and fixed the Join bug. Seems I checked for a null pointer, but I didn't check if the value being casted to that pointer was valid.

Edit2: I also remembered some of the message boxes are graphically ugly. I'll have to look into that.

Also, self reminder to make sure the info from the list of games get's freed when it's no longer used. I'm pretty sure it just clears the list view (which actually holds the pointers), and so the memory is never reclaimed. This needs to be done both when the list view is cleared when searching for games, and when the window closes.

Oh, and I haven't done anything to reorder the list of saved IPs. So, BlackBox, if you feel like posting the code you used to do that, I'd appreciate it.

Title: Proposed Net Fix
Post by: Arklon on February 04, 2008, 08:12:49 PM

Hooman, what happens if the host fails, drops, or quits? You probably want to add code that selects a new host, one of the players that are left that have port 47800 forwarded and have the lowest average latency between all the players.

Title: Proposed Net Fix
Post by: Hooman on February 04, 2008, 08:29:20 PM

Host is irrelevant at that point. By then everybody has everyone else's real external IP. They continue normally. The designation of Host is only really relevant during the pre-game setup. Maybe during resynchronization as well, in terms of organizing the resynch and setting the new state, but the higher level protocol that wasn't replaced would be responsible for that. Port forwarding should be irrelevant for resynchronizing, as no new "connections" are formed at that point.

(* I use the term connection lightly, as UDP doesn't really use connections).

Actually, the only person that doesn't know their own external IP is the original game host. Not that it matters, since they won't send network messages to themselves.

Title: Proposed Net Fix
Post by: Arklon on February 04, 2008, 08:44:29 PM

Ah, I see. Glad that's not a problem.

Title: Proposed Net Fix
Post by: Hooman on February 05, 2008, 05:22:45 AM

I'm attaching a new version. I made a few slight bug fixes, and some user interface improvements. (Basically, I completed some, but not all of the things I was originally planning to do).

There has been no (real) net changes, so this version should work with the previous posted version. No need for other people to download this version just so you can try it out.

The following changes were made:
The server address list will now remember new entries, and will move the most recently used entry to the top of the list
Hot keys were added for all options
The tab order has been corrected
The Search option has been made the default action (just press enter)
The games list now uses full row select
Double clicking a listed game will attempt to join it
Clicking join without a game selected can no longer cause crashes
A status display was added at the bottom of the window (let me know about what messages you'd like to see there, as it's not very developed yet)
The server address can now accept both address and port numbers (* see note below)

Example Addresses:
192.168.1.2 [Send request to 192.168.1.2, on the default port (47800)]
127.0.0.1:777 [Send request to 127.0.0.1 (localhost) on port 777]
localhost:777 [Send request to localhost (127.0.0.1) on port 777]
:777 [Broadcast to the LAN on port 777]

Either address component can be missing. If the port is not specified, or the string after the ":" converts to the integer 0, then the default port of 47800 is used. If the address part is missing, then it defaults to broadcasting over the LAN. Also, if the address string isn't an IP address in numerical format, then a host lookup is performed. (But that's old news).

* Note: I have not yet upgraded the user interface to allow hosting on a port other than 47800. (But the code underneath allows it).

As I said earlier, this is mostly just user interface improvements. I haven't gotten around to working on a game server yet. It's probably going to need some slight user interface changes to accomodate additional options. (Such as specifying the host port, and making advertising to the game server optional).

[Random reflection, mainly aimed at BlackBox for comment]

I'm also slightly tempted to use a seperate socket to listed for game search queries. Then it wouldn't need to recreate the main socket to remove the binding if the game is cancelled. If this is done, then the reply from the game host would of course be sent on the main unbound socket, and the client would use the return address on that packet for all further communications. That way NAT still won't be an issue. The main reason why I'm thinking of the change is to do with how the game server will be integrated. Once a game server is in place, the host won't need to bind at all, and can just use the regular socket. In which case, I see no reason to have a bound socket around. Plus, the bind can fail if the port is already in use, so if it's not needed, it should probably be avoided. Also, when the game is advertised, there will be some latency if the game server is to respond. If the server is down, then the client won't be certain for some time. The host will then need a bound port to accept client connections. If the decision is made early, then (if the client doesn't bind) the client would be left waiting to realize the game server was down before it would bind and actually be able to host without the server. If the client does bind, then the bind could fail, even though it could potentially have hosted the game using the game server (if it's up) anyways, and it would also be stuck using a bound port when an unbound one would do. Of course sending data out on the socket will implicitly bind it, so maybe I'm being a little anal about all this. Of course, since the socket gets implicitly bound when data is sent out, this means recreating the socket when going into host mode, as it'll get bound when the search query is sent out, as it automatically is when the new window opens.

Basically, I'm tempted to create a main socket once, which never gets recreated, and then create an additional socket for hosting, which only listens for game search queries, but isn't used for the replies.

[End reflection]

Title: Proposed Net Fix
Post by: Hooman on February 23, 2008, 05:13:48 PM

Some people are reporting problems at game start. I had some logging code to dump the players list when I was testing, but I disabled it in the previous two released versions since it seemed to be working fine at the time. I've re-enabled it for anyone doing any testing. If you have problems, be sure to send me a copy of Log.txt, which should appear in the Outpost2 folder. Make sure you do this immediately after the problem, since the log file is overwritten each time you start Outpost2.

I've also made a few small changes, but again, nothing that breaks compatibility with earlier versions. I mixed this version with previous ones in a recent test.

Changes include eating spaces and tabs at the start of server addresses, so it won't fail if you accidentally paste a space or tab in there. It also updates the number of packets and bytes received, so it won't always display as 0 in the net stats.

Oh, and some rudimentary support for a game server was adding using settings from the .ini file. But I haven't gotten a game server done, so no sense yet in making the changes to enable it. By default it will remain disabled.

Title: Proposed Net Fix
Post by: Hooman on March 10, 2008, 03:02:22 AM

Well, I spent a few hours working on this project today, and I got a game server working. It still needs a bit of work before I try opening one to public testing though.

In particular it was compiled and tested under Windows, but any 24/7 game server is likely to be running on some unix based machine. It also seems to have higher CPU usage than I expected. I had a Sleep call in it, but it didn't seem to do anything, so I might need to rework a small part to keep to CPU usage down to a reasonable level. (Probably using select, or something like that). It also doesn't release memory after claiming it, so it'll use whatever memory it needed at peek usage until it's shut down. It does recycle memory that's been claimed though, so it shouldn't be too bad.

I'd also like to finish a few hacker hardening features, so it'll take more than just some random script kiddie to bring down the server should someone want to cause trouble. It's got a number of security features built in already to help prevent some of the more common attacks, but some are incomplete, and I'd like to check for more possible problems.

I'd also like to add some extra performance counters, and a way to remotely check them, so I can make sure the server is running as expected when it's put into use.

Title: Proposed Net Fix
Post by: BlackBox on March 10, 2008, 11:02:05 AM

I'd probably be willing to help with a Unix port of this if you want. About CPU usage and nonblocking IO, even though this is probably not a huge concern due to the low number of open sockets there will be (when compared with larger servers out there), kqueue or epoll would be a faster way to go than select() (there is a library out there called libevent which has some sort of standard API that will try and use kqueue or epoll, and fall back to select if the OS doesn't support either of those).

As far as performance counters go, it would be fairly straightforward to link it up to the web server (from there the server could be controlled using the web as well, would save the trouble of having to write administrative commands directly into the interface with the client).

Title: Proposed Net Fix
Post by: Hooman on March 11, 2008, 02:54:19 AM

Ok, I've got the CPU issue worked out, and it's now up and running on a unix based machine.

Btw, what OS does the server use? I figure I should do a bit more testing on different flavours of Linux or other Unix variants, since I ran into more trouble than I expected. I figured with winsock being based on a Unix API, porting shouldn't be too bad, but it seems there are more subtle differences than I really cared to know about.

Btw, does that library you mentioned work on Windows? I've heard about those alternatives before, but I don't remember much anymore. Although, I probably won't bother to change anything now without reason. It only needs to wait on 1 socket, and maybe do a few periodic updates, and it's working just fine with select. It shows up as 0% CPU usage on Windows in Task Manager, and the total system load on my Unix machine is less than 1% (and it's running other things too, which are active).

I wouldn't be too sure how to go about integrating the performance counters with a web server. I was sort of thinking of just mem copying a counter struct to a network packet, and send it off. I would need to add a few extra messages to do it, but that's no problem (query/response). Probably just make a simple command line client to fetch and dump the values to the console. Although, it might be nice for people to checkup on some of the stats (number games played, etc.).

Anyways, I needed to make a few changes to the client (bug fixes), so there will be a new version up for download in the near future. It truncated some of the address strings if they were too long when loading from the .ini file, and it was also stripping the port number from them before saving them to the combo box. It also had no default port specified for the game server (or address family either, which was a bigger issue).

Edit: Oh, btw, I forgot to mention this earlier. But the problems people have reported seem to be associated with symmetric NAT. Currently, my changes will not do much to help people whose router uses Symmetric NAT. I had a few ideas to help with this, but Symmetric NAT is actually quite a nasty beast, so I might not come up with a perfect solution. (I'm half tempted to suggest people with it get a new router :P ). When I first read about the different types of NAT, I read that Symmetric NAT is rather uncommon and usually only found in large corporate networks. This doesn't seem to be the case after all. Some home routers do use Symmetric NAT. I've also heard that some routers have a "Gaming Mode", and for one model that I read about, it uses Symmetric NAT if that option is turned off. If you enable Gaming Mode, then it uses Cone NAT, which shouldn't be a problem for this patch. At any rate, I'll try to tackle the problem later on down the road. (Btw, how does Hamachi deal with it?) I suppose we could always use the game server as a relay if we really needed to. (Although I'd rather use other players if possible).

Title: Proposed Net Fix
Post by: BlackBox on March 12, 2008, 11:36:00 AM

The server is running a Linux 2.6.x kernel on standard 32bit x86 hardware so if you stick to standard Unix API's and headers the program should work fine. (Yes, that's right script kiddies... I just divulged some "important" information about the server's OS. Now hack us).

Linux does support both epoll and kqueue I believe if you were gonna use that (though looking now at it you probably wouldn't get that much of a performance gain by using it, if you only have 1 socket).

Libevent does work on windows but I don't think it uses the winsock2 features like overlapped socket IO, etc. (Looks a lot like it was one of those unix libraries that was quickly ported to windows just so unix programs that used it would work on windows without major changes). It probably falls back to select() on windows, is my assumption.

As far as the stats thing goes, probably just have a fastCGI daemon listening on a unix domain socket (or maybe a couple of them). One of them is for the webserver (the web side of things), the other one could be used for the game server to communicate with the fastCGI daemon. (Or perhaps just integrate the web daemon into the game server itself).

Regarding hamachi, they don't release any information on how it works. (Well, for symmetric NAT, they might just relay stuff thru the server. There is capability for that in hamachi).

Title: Proposed Net Fix
Post by: Hooman on March 15, 2008, 11:30:12 PM

Ok, here is a slight bug fix version. I've been busy writing a game server, and it seems to be working. This latest client update will be needed to connect.

Like earlier versions, copy it into a "NetPatch" folder inside the Outpost2 folder, and start OP2 with the usual "/loadmod NetPatch" parameter. To enable the game server support, you also need to add the appropriate entries to Outpost2.ini. I'm running a test server on one of my machines currently. Don't expect it to stay up for very long. This is just a short testing phase. Anyways, the settings to add to the Outpost2.ini file (just at the end of the file is good), are:

Code: [Select]

[GameServer]
GameServerAddr=68.146.70.0:47777

Note that the address is dynamic, so it's pretty much guaranteed to change eventually.

Please post if this works for you, or any issues you may experience. (Excessive lag? Quirky behavior? Crashes? etc.)

Edit: Just a reminder, this works under the "Serial" option in the multiplayer menu. I didn't want to overwrite any of the more useful multiplayer options until some more testing and development is done.

Edit2: For the host address, you can enter the game server's name (68.146.70.0:47777), or the host's name. That was that small change I was forgetting to make.... Have the client auto check the game server's address for a list of games, rather than simply broadcast to the LAN. It'll send back a list of all hosted games. Make sure someone has a game hosted on there first, or you won't be able to see anything.

Edit3: Updated the download slightly. It'll now check the game server for a list of games automatically when you open the serial option. (If the Outpost2.ini file settings are not entered, then it'll fall back to a LAN broadcast). Just make sure you enter in the Outpost2.ini file settings.

Edit4: Attachment updated. Fixed a bug that was causing trouble when joining games listed by the server. (They appeared in the list fine, and if you typed the server address in manually, join would work. Turns out the address family field of the address was wrong, causing errors when trying to send the join request. This field is now correctly initialized.)

Title: Proposed Net Fix
Post by: Tellaris on March 20, 2008, 06:06:51 PM

Found a bug for ya, Hooman. If you don't refresh, but leave it, and somebody keeps recreating the game, the new games get listed... but underneath the old one. A minor issue, cleared up by searching again, but just throwing it out there

Title: Proposed Net Fix
Post by: Hooman on March 20, 2008, 09:12:17 PM

Yeah, I'm aware of that. I've been meaning to put some sort of timeout there to remove old entries, or do some sort of host address comparison, and limit it to 1 per unique (ip, port) pair.

I also want to make sure the protocol is reasonably secure against hacker attempts to bring the system down. Such as someone spamming the server with false hosted games, or trying to remove someone else's hosted games from the server.

I was also thinking of adding some sort of connected players list, so people don't feel so alone when nobody has a game hosted, and so they aren't left to wonder if the server is even working. I might leave that for a version 2 or something though.

The biggest issue I think I need to tackle right now though, is symmetric NAT. It works with cone NAT, or for connections without a router, but there are still issues with routers that use symmetric NAT. I've run into two people on IRC with such routers, so it's not quite a non issue (as I originally hoped it'd be). Right now, it seems such a person can host a game if they've forwarded 47800, and the client looks for their IP explicitly. It doesn't work if they try to join using the game server. (Although, the game server would at least tell you their IP, you just couldn't double click to join). The simple solution might be to require such routers to forward a known port (such as 47800). It would require a few minor protocol changes, so more downloads. I've also thought of a few ideas to try some sort of punch through using narrowed port scanning based on the other known external port numbers that other clients see. (They tend to clump together).

... but for now, I'm immediately distracted by another project that has nothing to do with OP2. :P I'll probably get back to it once people start asking me about it on IRC or something.

Title: Proposed Net Fix
Post by: OriginalOP2 on March 29, 2008, 07:28:26 AM

So this game is still kicking? Thats good :)
This game was my life for a few years when it was hot. It better not die!
I am very excited about this Net fix. I got my lan buddys playing op2 a few weeks ago and they love it.

Title: Proposed Net Fix
Post by: Tellaris on March 29, 2008, 04:11:07 PM

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.

Title: Proposed Net Fix
Post by: Hooman on March 30, 2008, 02:03:16 AM

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. :P

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).

Title: Proposed Net Fix
Post by: Sirbomber on March 30, 2008, 07:18:04 AM

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.

Title: Proposed Net Fix
Post by: Tellaris on March 30, 2008, 02:17:44 PM

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

Title: Proposed Net Fix
Post by: Hidiot on March 30, 2008, 02:18:23 PM

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...

Title: Proposed Net Fix
Post by: Sirbomber on March 30, 2008, 08:21:08 PM

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.

Title: Proposed Net Fix
Post by: Hidiot on March 31, 2008, 02:20:05 AM

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

Title: Proposed Net Fix
Post by: Hooman on April 12, 2008, 03:43:28 AM

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.

Title: Proposed Net Fix
Post by: Sirbomber on April 19, 2008, 07:02:43 AM

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)?

Title: Proposed Net Fix
Post by: Hooman on April 19, 2008, 07:22:46 AM

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.

Title: Proposed Net Fix
Post by: Sirbomber on April 21, 2008, 08:35:09 AM

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.

Title: Proposed Net Fix
Post by: Hooman on April 21, 2008, 04:33:41 PM

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.

Title: Proposed Net Fix
Post by: BlackBox on June 27, 2008, 08:31:18 PM

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 (http://www.outpostuniverse.net/netfix.php)

Title: Proposed Net Fix
Post by: Hooman on August 02, 2008, 04:53:02 PM

The IP has changed again. It is now: 68.146.111.58

Title: Proposed Net Fix
Post by: Hidiot on August 03, 2008, 12:44:15 AM

So, when's it going to be static?

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

Title: Proposed Net Fix
Post by: BlackBox on August 03, 2008, 10:44:41 AM

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).

Title: Proposed Net Fix
Post by: Hooman on August 05, 2008, 04:40:37 PM

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.

Title: Proposed Net Fix
Post by: Savant 231-A on August 13, 2008, 03:50:33 PM

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

/me hugs Hooman :D

Title: Proposed Net Fix
Post by: Hooman on September 08, 2008, 05:09:37 PM

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

Title: Proposed Net Fix
Post by: Hooman on September 25, 2008, 05:03:41 PM

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.

Title: Proposed Net Fix
Post by: Hooman on October 15, 2008, 11:07:47 PM

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.

Title: Proposed Net Fix
Post by: Hooman on July 11, 2009, 08:56:34 PM

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.

Title: Proposed Net Fix
Post by: Leviathan on July 12, 2009, 04:13:34 PM

Nice work. Thanks :)

Title: Proposed Net Fix
Post by: Hooman on July 12, 2009, 05:05:13 PM

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.

Title: Proposed Net Fix
Post by: Hidiot on August 02, 2009, 12:23:40 PM

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

Title: Proposed Net Fix
Post by: Hooman on August 02, 2009, 03:15:54 PM

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.

Title: Proposed Net Fix
Post by: Hidiot on August 02, 2009, 03:22:21 PM

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

Title: Proposed Net Fix
Post by: Hidiot on August 10, 2009, 04:53:05 PM

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.

Title: Proposed Net Fix
Post by: Hooman on August 11, 2009, 12:58:59 AM

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:

Quote

[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]}

Title: Proposed Net Fix
Post by: Hidiot on August 11, 2009, 02:29:01 AM

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.

Title: Proposed Net Fix
Post by: Hidiot on August 12, 2009, 01:29:33 PM

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?

Title: Proposed Net Fix
Post by: Hooman on August 12, 2009, 10:59:09 PM

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.

Title: Proposed Net Fix
Post by: Hooman on September 20, 2009, 07:25:59 PM

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).

Title: Proposed Net Fix
Post by: Hooman on November 18, 2011, 01:55:18 AM

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.

Title: Proposed Net Fix
Post by: TH300 on March 22, 2012, 10:31:17 AM

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.

Title: Proposed Net Fix
Post by: Hooman on March 23, 2012, 03:30:26 AM

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.

Title: Proposed Net Fix
Post by: Hooman on April 10, 2012, 09:32:16 PM

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.

Title: Proposed Net Fix
Post by: TH300 on January 14, 2013, 05:50:54 AM

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.

Title: Proposed Net Fix
Post by: Hooman on January 15, 2013, 02:29:52 AM

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.

Title: Proposed Net Fix
Post by: CK9 on January 15, 2013, 07:28:59 PM

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?

Title: Proposed Net Fix
Post by: Hooman on January 16, 2013, 05:35:11 AM

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.

Title: Proposed Net Fix
Post by: TH300 on January 16, 2013, 07:00:30 PM

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.

Quote

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.

Title: Proposed Net Fix
Post by: Hooman on January 17, 2013, 01:12:54 AM

Quote

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.

Title: Proposed Net Fix
Post by: Arklon on January 18, 2013, 01:37:19 PM

Quote

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 :P

Title: Proposed Net Fix
Post by: TH300 on January 18, 2013, 05:35:40 PM

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.

Title: Proposed Net Fix
Post by: Hooman on January 19, 2013, 01:23:36 AM

Quote

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?

Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Topic started by: Hooman on January 24, 2008, 11:52:36 PM