Frequent disconnects during triangulation

Bug Report Section Mac Version
#1

This bug is related to a previous thread that can be found here: https://forum.star-conflict.com/index.php?showtopic=27051&st=0

 

The disconnects happens often and only during triangulation,when the player is transferred from the queue of the master-server to the game-server of the chosen game mode (any mode). It is not only annoying to me, but also that all the other players are short one player.

 

After analysing the previous issue with the devs, a known bug was confirmed to exist in a third-party tool that they use (RakNet), no fix is available.

 

A known workaround is to fine-tune the MTU size.

While that would work for some of us, it doesn’t for those of us with routers that don’t allow to change the MTU size.

 

The problem is another bug that I found, hence the new thread:

 

When the game ‘discovers’ the client (when it’s writing the log-entry with the MTU size) it’s actually taking the MTU of my router (fixed at 1492).

The game doesn’t follow the IP chain all the way to my machine (the true end-point of the connection), where it would find the MTU to be 1476, the optimum value calculated with a formula/method provided by the devs in the preceding thread**).
Would it pick up the MTU from the true end-point (my machine), I would be able to adjust the MTU down to whatever value works.**

I spoke to my ISP about that and the only option they offer is to buy a router that allows me to set the MTU for 160€.
Frankly I don’t see why I should spend money to bypass a bug in the game.

 

Best regards 

 

 

[GameWithError.log](< base_url >/applications/core/interface/file/attachment.php?id=9404)[TerminalLogAtTimeOfGame.log](< base_url >/applications/core/interface/file/attachment.php?id=9405)

#2

the way RakNet determine your MTU on connect stage is :

 

  1. send the largest-possible packet to client.

 

  2. On fail, send another packet, but a little smaller; repeat this step until success

 

record MTU size and continue with it.

The router on your way with MTU set to its maximum shouldnt be a problem.

Because the found MTU sized packet has landed successfully on your Mac

 

Though we’ll try to squeeze MTU size down to 1430 from inside the game client for the test. And it is maximum we can do for now not digging inside the RakNet code. wait for the patched game client version,

#3

The way you describe the connection mechanism it should really work. 

Only the game.log and behaviour ist not consistent with that.

 

It constantly recorded 1492 as the MTU for the client (I haven’t found a different value in 3 weeks, checking the log several times a day whenever the disconnect occurs).

The ping in the terminal session constantly is giving me 1448 as the max value before an error occurs, +28 for the header being 1476, which is what my PC is set to.

It is however consistent with what my ISP tells me: The router is set to a fixed 1492 in the firmware with no possibility to change the settings as a user.

So nothing dynamic is happening there.

 

So the mechanism you describe should really get to 1476 if it worked correctly and thus I should see it in the game.log.

 

Theoretically, the MTU should not be a problem at all. Changing it should only make it slower or faster, depending on how many splits occur, and there is the optimal speed based on the network quality and stability between our providers, which happens to be 1476 quite reliably.

 

The problem really seems one of timing: I have a feeling there is some calculation going on somewhere that takes my router’s MTU (instead if my client’s MTU), determines how long this should take and calls a timeout when we get beyond that threshold. Now if the MTU is too high (1492 > 1476), more frequent splits will occur, reducing the actual throughput of the connection, making a timeout more probable (I called this a ‘false timeout’ in the earlier thread, as it is not a technical timeout -> no real network communication error occurs).

This would really be not ‘best-practice’ in commercial (business software - that’s what I do for a living), but I can understand the need for that in gaming software, trying to squeeze the most performance out of the connection.

 

That would explain why the people with configurable routers can bypass the problem by adjusting the MTU size.

 

Dear sgdmity, I hope I am not getting on your nerves with this, just doing the best I can to help you identifying the root cause if the problem without me having all the source code for a debugging session. It’s not just me getting annoyed by the frequent errors, just remember that for every time I get the error, 3-10 other gamers get annoyed with me seemingly ‘quitting’ the game, diminishing their chances for a win. Multiply that by the amount of players that have the same problem. 

I am now in a corp (SRO), and I am already getting word that some members don’t think I am reliable due to the many disconnects. 

Plus I get punished by my ships getting blocked for the duration of the game without them being actually in use.

Please also keep in mind that the re-connect dialog needs fixing (the dialog that pops open right after the disconnect message).

 

The upcoming changes to the client you describe don’t look like a real solution of the problem, but of course I would be happy if it helps to bypass the real problem, even when it’s not exploiting the max connection speed possible.

 

 

 

Thanks and best regards