Server Connection Failed

[Webb (DayZ) 0]

Alright - basically, the server that a friend of mine is hosting is bugged - and nobody can connect, unless running six launcher. I'm not sure if it is a beta patch issue, a server issue, or what ever else it could be - but if you do not use six launcher, you get a "Connection Failed" error.

We have tried everything we can to fix it, but nothing has worked - so I am posting here to see if any other server host or players know how to fix this, or are having the same bug.

If you need the server name to help figure this out, PM me - and I'll give it to you.

Thanks,

Webb

[Alfie (DayZ) 8]

What is the server launch command line?

What beta build version is installed?

Copy + Paste the server.cfg either onto pastebin.com or within code tags on here.

Then I can help :P

[Webb (DayZ) 0]

Alright, everything is here: http://pastebin.com/KQ32rAzM

Running the most recent beta, 94444.

[Alfie (DayZ) 8]

Assuming you've got the ports forwarded properly on the server (please tell me you haven't overlooked that), there's a few things I can suggest as starters.

Remove the IP parameter from the launch. As quote from Kelly Heroes set up guide:

You cannot specify an IP address with which to bind the server to i.e. -ip = xxx.xxx.x.xxx

ArmA2 server defaults to the primary ip address of the server and cannot be changed.

If you wish to setup multiple instances of ArmA2 server on the same server it is only possible by specifying alternative ports with -port.

Doubt it will make jack all difference, but you should specify -name=cfgdayz after specifying the port, before the rest.

I'd also revert to the 93965 beta. To revert you literally need to just install that version. Nothing else needs to be done (other then the change in the server.cfg required build). Though I don't see why that would really cause an issue, but I have heard there have been some problems. It's worth trying just to be sure.

I'd also switch the player count from 80 to 50, or a max of 64. I seriously doubt you've got the CPU power to support 80 people on a stable server. Even if you do it'll degrade very quickly. Fact is a dedicated Arma server is not multi threaded very well. As far as I'm aware it's something they added later in development so it's pretty half arsed.

To add to this the more people you've got on regularly (and longer it's been up) dramatically alters the footprint the server uses. The larger the memory footprint, the faster it will reach its crash point.

You'll seriously be surprised just how crippling the engine limitations are. It doesn't even matter if the OA server has the box entirely to itself (and that box is a mega-beefy rig), it's happy to act like it's being run on a single-processor server from four years ago. "Engine limitations". Learn that phrase well, because it will become the bane of your Arma 2 hosting existence.

You should set your exThreads to 1 as well. That won't be the issue with the connection issues, but seriously it shouldn't be higher. An explanation on that from Mojo:

exThreads is a mask for a parameter table, not an incremental count. That is, setting it to 7 doesn't create seven additional threads for better threading. The options are 0, 1, 3, 5, and 7:

0: No additional threading.

1: Threading for file operations only

3: Threading for file operations and textures

5: Threading for file operations and geometry

7: Threading for file operations, geometry, and textures

The reason you don't set it to 7 (and I don't know why the DevTeam defaults it to this, it absolutely perplexes me) is because A2/OA are single-threaded applications with basic multithreading functionality added, they don't properly create parallel threads native to the application, they basically rely on OS scheduling.

That means that when you launch the server with -exThreads=7, you're telling the server to prepare core scheduling for geometry and texture processing on a render loop that will never, ever come on the server. You're creating overhead for absolutely no reason, and zero gains.

exThreads 1, however, uses only file operations. File operations are *mostly* used to handle the other two threads (geo and tex), but only because those are the most-called file operations. It handles all file operations. If you have the overhead to spare, you will notice marginal performance and stability gains as it offloads the file operations process from the main process. If, on the other hand, you don't have the overhead, it will destabilize the server.

In other words, never use anything but -exThreads=0 or -exThreads=1 for the server. You also actually do need to specify this, because the .exe WILL use auto-detection to try to determine the exThreads number based on your core count.

If none of the above has resolved the issue, can you guys get the server up and going, try to get in and fail, and connect via six updater successfully. Then after that, stop the server, go to your cfgdayz folder, open up arma2oaserver.RPT in a text editor and dump everything that's on there on pastebin.

[Webb (DayZ) 0]

Assuming you've got the ports forwarded properly on the server (please tell me you haven't overlooked that)' date=' there's a few things I can suggest as starters.

Remove the IP parameter from the launch. As quote from Kelly Heroes set up guide:

You cannot specify an IP address with which to bind the server to i.e. -ip = xxx.xxx.x.xxx

ArmA2 server defaults to the primary ip address of the server and cannot be changed.

If you wish to setup multiple instances of ArmA2 server on the same server it is only possible by specifying alternative ports with -port.

Doubt it will make jack all difference, but you should specify -name=cfgdayz after specifying the port, before the rest.

I'd also revert to the 93965 beta. To revert you literally need to just install that version. Nothing else needs to be done (other then the change in the server.cfg required build). Though I don't see why that would really cause an issue, but I have heard there have been some problems. It's worth trying just to be sure.

I'd also switch the player count from 80 to 50, or a max of 64. I seriously doubt you've got the CPU power to support 80 people on a stable server. Even if you do it'll degrade very quickly. Fact is a dedicated Arma server is not multi threaded very well. As far as I'm aware it's something they added later in development so it's pretty half arsed.

To add to this the more people you've got on regularly (and longer it's been up) dramatically alters the footprint the server uses. The larger the memory footprint, the faster it will reach its crash point.

You'll seriously be surprised just how crippling the engine limitations are. It doesn't even matter if the OA server has the box entirely to itself (and that box is a mega-beefy rig), it's happy to act like it's being run on a single-processor server from four years ago. "Engine limitations". Learn that phrase well, because it will become the bane of your Arma 2 hosting existence.

You should set your exThreads to 1 as well. That won't be the issue with the connection issues, but seriously it shouldn't be higher. An explanation on that from Mojo:

exThreads is a mask for a parameter table, not an incremental count. That is, setting it to 7 doesn't create seven additional threads for better threading. The options are 0, 1, 3, 5, and 7:

0: No additional threading.

1: Threading for file operations only

3: Threading for file operations and textures

5: Threading for file operations and geometry

7: Threading for file operations, geometry, and textures

The reason you don't set it to 7 (and I don't know why the DevTeam defaults it to this, it absolutely perplexes me) is because A2/OA are single-threaded applications with basic multithreading functionality added, they don't properly create parallel threads native to the application, they basically rely on OS scheduling.

That means that when you launch the server with -exThreads=7, you're telling the server to prepare core scheduling for geometry and texture processing on a render loop that will never, ever come on the server. You're creating overhead for absolutely no reason, and zero gains.

exThreads 1, however, uses only file operations. File operations are *mostly* used to handle the other two threads (geo and tex), but only because those are the most-called file operations. It handles all file operations. If you have the overhead to spare, you will notice marginal performance and stability gains as it offloads the file operations process from the main process. If, on the other hand, you don't have the overhead, it will destabilize the server.

In other words, never use anything but -exThreads=0 or -exThreads=1 for the server. You also actually do need to specify this, because the .exe WILL use auto-detection to try to determine the exThreads number based on your core count.

If none of the above has resolved the issue, can you guys get the server up and going, try to get in and fail, and connect via six updater successfully. Then after that, stop the server, go to your cfgdayz folder, open up arma2oaserver.RPT in a text editor and dump everything that's on there on pastebin.

Well, here is a dump from the .rpt file, http://pastebin.com/1tHBAAeG

It seems that now, players can't even get ingame - just get a server is running an invalid server file or something along that line. We are re-installing everything tonight from scratch, I will tell you how it goes.

[t0pz 173]

bump

just an add to Webb's post: this has only been happening since the latest build 94444. The server was running fine before that.

Downgrading didn't seem to fix it, strangely enough. Or the downgrading failed/messed sth else up.

btw, we don't seem to be the only ones: http://dayzmod.com/forum/showthread.php?tid=28185

[Alfie (DayZ) 8]

You could try uninstalling the files, redownloading and then patching with an older version on a clean install. Only thing I can think of doing at the moment.

[Webb (DayZ) 0]

Gonna bump this, still not solved.

[t0pz 173]

We just updated it to 1.7.2.3 as well as the beta patch 94876 and the same issue still exists. When anyone joins the server through Arma, it gives a "Connecting Failed" error, however through Six Launcher everyone can connect fine.

This also doesnt seem to be the only server with this issue. I see some (not many) servers with the same problem. I cant connect to their server unless i use six launcher.

I do not know where to begin to find out why this could be... It does not make any sense, since six launcher connects the same way to the server, as Arma does. What is the actual difference between the six launcher and the arma launcher, really?

[kpl_hicks 1]

Bump