[0.14.13] [Oxyd] Mod limit causes inability to connect.

[Lennartos]

After playing some multi player games with several different players i found out that some players have a hard limit of 50 mods.
For these mods only amount matters not content or size, nor does it matter if they are zipped or not - took us some hours to find out what the cause was
If you exceed this limit by adding even 1 more mod, then suddenly no one can connect to these players if they host - and they cannot join anyone.

Message is always:
"Couldnt establish network communication with server."

However others can have 90 mods just fine, with no issues.
I cannot say what the cause is, but its very easy to reproduce.
With a headless server he joins the game according to log, but is kicked immediately from his perspective ( with a timer showing a delayed kick from others )
Attached is the log from the server.

[Oxyd]

Post the log from one of the limited clients, please.

[Lennartos]

Hereby Attached Logs for a 50 Mod game (server and client CAN connect).. and a 51 mod game (which fails)

[kovarex]

This might be related to maximum packet size/packet fragmentation problems on certain network connections.
It might be, that the ConnectionAcceptOrDeny network message that contains the list of the mod with names might gets too large and the 50 is just a coincidence.

I might make the packet somewhat smaller to see if it changes the limit in the next version. (The 0.14.13 is alrady being released, so it will have to wait for 0.14.14)

[Lennartos]

Yeah. we where thinking the same - but we cant be sure since we dont know whats actually happening behind the scenes.
A good test might be to use base64 on the modlist if its currently clear text, and see if that affects it much.
If it does, and "UDP only" is kept, then adding automatic split of messages ( fragmentation ) would be a good addition to the networking layer.

[kovarex]

Messages can be quite long, and it should be fragmented automatically, it might be specifics of some network that causes this problem.

Anyway, lets see what will change in 0.14.14

[Lennartos]

been tracking deeper into this, and behold - its apparently due to fragmentation being disabled by their ISP. ( which means its actually a larger problem than just a few people )
According to my tests, the usual packet size limit of modern routers is 1472 bytes.

But those affected by that setting i found that there is a 100% packet loss between 1465 and 1472 both OUT and IN. ( fits with PPPoE taking these 8 byte )
Packets larger than 1473 are fragmented on the external side and thus work fine ( as long as each chunk is < 1465 bytes )
But from inside they cannot reach anyone with packet sizes > 1465 bytes.

The only solution i can see is thus to automatically split the packages yourself into lets say 1024 or 1280 Byte chunks (since ipv6 guarantees only 1280, and also has no fragmentation support ), and assemble on the other end - since IP-fragmentation apparently is not a guaranteed feature in real life, and on the way out anyway with Ipv6.

From wiki:
"In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP datagrams with a total reassembled size of up to 576 bytes. They may also attempt to reassemble fragmented IP datagrams larger than 576 bytes, but they are also permitted to silently discard such larger datagrams. Applications are recommended to refrain from sending datagrams larger than 576 bytes unless they have prior knowledge that the remote host is capable of accepting or reassembling them"

[White-Tiger]

[...] (since ipv6 guarantees only 1280, and also has no fragmentation support ) [...]

Just to clarify some things so others might not get the wrong idea...
IPv6 guarantees that the MTU is at least 1280 (IPv4 supported at least 68.... yep that's right.. 68 but with a minimum datagram size of 576) and also supports fragmentation but nothing automatically done by hops...
Though if a software isn't using MTU discovery, it should not exceed 1280 octets per packet / fragment

[kovarex]

been tracking deeper into this, and behold - its apparently due to fragmentation being disabled by their ISP. ( which means its actually a larger problem than just a few people )
According to my tests, the usual packet size limit of modern routers is 1472 bytes.

But those affected by that setting i found that there is a 100% packet loss between 1465 and 1472 both OUT and IN. ( fits with PPPoE taking these 8 byte )
Packets larger than 1473 are fragmented on the external side and thus work fine ( as long as each chunk is < 1465 bytes )
But from inside they cannot reach anyone with packet sizes > 1465 bytes.

The only solution i can see is thus to automatically split the packages yourself into lets say 1024 or 1280 Byte chunks (since ipv6 guarantees only 1280, and also has no fragmentation support ), and assemble on the other end - since IP-fragmentation apparently is not a guaranteed feature in real life, and on the way out anyway with Ipv6.

From wiki:
"In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP datagrams with a total reassembled size of up to 576 bytes. They may also attempt to reassemble fragmented IP datagrams larger than 576 bytes, but they are also permitted to silently discard such larger datagrams. Applications are recommended to refrain from sending datagrams larger than 576 bytes unless they have prior knowledge that the remote host is capable of accepting or reassembling them"

You are most probably right. Did you try in the 0.14.14? The limit should be increased but it should still be there.

[kovarex]

So the task of automatic packet fragmentation on the application level has been assigned and it should be done in the 0.14 branch.

[Lennartos]

He didn't have time to test, but we did schedule a test for tonight.

[bk5115545]

The packet fragmentation implementation might also fix this one and similar if it's implemented for the whole game instead of just the connection process.
viewtopic.php?f=47&t=34452

[Rseding91]

The packet fragmentation implementation might also fix this one and similar if it's implemented for the whole game instead of just the connection process.
viewtopic.php?f=47&t=34452

Yes, that issue will be addressed as well.

[Oxyd]

Fixed in 0.14.15.

[Lennartos]

With 14.14 the mod limit increased to 64 mods from 50, so definetly a improvement.
However we cannot continue our game as the bug also seems to appear during map transfer - making the game looping loading and syncing until timeout ( with messages of "server not responding" popping up constantly during transfer) - new game works fine

[Lennartos]

After testing 14.15 the behavior definitely is improved.
Though he is now stuck in a desync loop.. error report here:
viewtopic.php?f=209&t=35164

Not sure if there is still a hole in fragmentation or something else.