Waiting For Game Info Hangs

[Norfleet]

What's the story behind this new 2.11 feature that causes games to regularly hang on "waiting for game info"? According to the patch notes, something was apparently changed in the netcode in 2.11, and now it's much, much worse!

[Gandalf Parker]

Ive been waiting for someone to reply saying they have the same problem. So far it seems to be something that only affects certain copies.

[Norfleet]

It seems to afflict a number of Windoze servers, and ONLY Windoze servers. It also seems to only kick in after the game has been running for many hours, and doesn't occur all at once, but instead, gradually, as the "waiting for game info" period can become interminably long....before this phase starts taking longer than anyone reasonably has patience for, and kills the process to try reconnecting again. Sometimes, this banishes the problem for a few connection attempts, but ultimately, it exacerbates the problem for any future connect attempts, and the situation deterioriates: Players who are ALREADY connected to the server often notice nothing unusual, however.

Killing the process and restarting it always banishes the problem completely for at least a few hours.

It's definitely not related to "specific copies", because the kludgemush.com cluster had 3 different Windoze boxen that all suffered this problem: We moved all the games to a Linux box yesterday, and now the games are as stable as the ones on Mosehansen's, which is also a Linux box: No more WFGI hangs. Argitoth's server, a Windoze box, and Xavier's, another Windoze box, also seem to suffer from this on occasion, although it's hard to tell as I don't have too many games there and elsewhere. Their boxes also nagot constantly on turn generations, something that I am unable to reproduce. Not too many people can host 24h servers.

This strongly suggests that it's a Windoze-specific problem, as Windoze networking code and networking code for unices are completely different: Everything else would largely be the same, except for the network code, which I currently suspect is the culprit. It should also be noted that, according to the changelog, the networking code was altered in 2.11, and this problem did not occur in 2.08.

[Cainehill]

Originally posted by Gandalf Parker:
Ive been waiting for someone to reply saying they have the same problem. So far it seems to be something that only affects certain copies.

I thought it was too obvious this was a problem to warrant replying. If a game is hosted on a Windows box, it gets slower and slower and slower, until it seems like the game has completely hung.

Sometimes it takes 5 minutes. Sometimes it takes longer - I'll get up, go to the kitchen, make a snack, come back and it's ready. Sometimes it takes so much longer I kill the dom2 process and do something else entirely.

[Gandalf Parker]

Sounds like its worth testing then. Thanks for bringing it up.

[alexti]

Originally posted by Norfleet:
This strongly suggests that it's a Windoze-specific problem, as Windoze networking code and networking code for unices are completely different: Everything else would largely be the same, except for the network code, which I currently suspect is the culprit.

If you're talking about the applications network code, you can write pretty much the same code. Either OS supports berkeley sockets API, so unless Illwinter intentionally implements networking differently, it should be the same.

TCP transport implementation (that comes with OS) is a different thing though. But then it's not clear why only Dom2 suffers from the problems. Though Windows is not as good at networking, the degree of problems is unreasonable even for Windows. I'm puzzled about what it might be. Maybe some setsockopt option is different by default? SO_LINGER for example?

[Gandalf Parker]

Well I would have thought it was the zombie-processes problem we saw before on Linux. But I get the impression that the people complaining know how to check for unclosed connections.

Has anyone checked to see if its a memory leak?

[alexti]

It looks that the problem is that sockets are getting stuck in FIN_WAIT2 state. When the client closes the connection is send FIN,ACK and the server responds with ACK (that's something TCP/IP stack is doing independently from the application), but the server never sends FIN to the client (which he is supposed to do). This looks that the application (Dom2 server) either misses connection closed/reset notification or just doesn't close the socket because of some other reason. The FIN is sent when the application closes the socket.

This leads me to the possible cause. AFAIR, on Unices function to close the socket is called "close" and on Windows it is called "closesocket". To properly confuse things, Windows has a function "close" which has nothing to do with sockets and possibly the code that calls "close" to close the socket will even compile (but it won't result in closing the socket).

Another possibility is the difference in lingering settings.

And yet another possibility is that on Windows Illwinter uses windows-specific socket event monitoring mechanism (there is such) and there's a bug somewhere in it (for example FD_CLOSE flag is not interpreted or not specified in monitoring mask).

In all these cases it should be relatively simple to track down the problem in the debugger, so I hope this won't be as hard to find as a famous battle replay problem.

[Johan K]

It turns out that it is indeed a single function that hasn't got its close converted to closesocket. The windows code is a copy and paste from the unix code where the close call is used. That might explain the 'temp file bug' in windows too I think.

[Gandalf Parker]

Originally posted by Johan K:
It turns out that it is indeed a single function that hasn't got its close converted to closesocket. The windows code is a copy and paste from the unix code where the close call is used. That might explain the 'temp file bug' in windows too I think.

Run! Run and Hide Johan. I'll cover you.
You are becoming the experienced expert on "runs on other operating systems, then theres Windows" bugs. A Windows programming guru. You will get pestered by other developers.

[ April 24, 2004, 13:36: Message edited by: Gandalf Parker ]