Dynamically Acquire pmtu Settings From Server

[SloneFallion]

For a server that only hosts a certain game, such as Animal Crossing: New Horizons, many people aren't putting in the correct pmtu argument when connecting with LAN Play. While that's on them to follow instructions, it provides a poor experience for those that are already connected with the correct settings as the game crashes.

I propose an optional flag on the server to override or force-set the pmtu on the client. This would require an update on both the server and client, but I figured it would start with the server being able to send that data, first.

A command line argument could be something like slp-server-rust --clientpmtu 500

[igromanru]

The idea is good, but it would make a server bad for other games.
Maybe it's also an idea to let only people connect with each other, who got the same PMTU settings.

[SloneFallion]

The idea is good, but it would make a server bad for other games.
Maybe it's also an idea to let only people connect with each other, who got the same PMTU settings.

That's exactly what this issue isn't for, though. "For a server that only hosts a certain game, such as Animal Crossing: New Horizons".

To clarify - I run a personal server for Animal Crossing LAN Play. I only use it and want it used for such purpose. One person with bad settings connects and kills the whole experience for everyone connected. Again, if implemented, the flag would be optional upon server start.

[drizuid]

I'm not aware of a mechanism to force client side path mtu or mtu for that matter, otherwise, my life as a cisco network dude would be much simpler :p Usually path mtu discovery is used (this is still client side) but that doesnt work on most non-enterprise setups, much like mss clamping must be done on the client side.

Maybe space knows something I don't, but I wouldn't hold your breath on this :(

[SloneFallion]

The client already supports a custom pmtu setting - I'm proposing that the client and server can have an interaction to negotiate a specific pmtu administered by the server. A config "file", if you will.

I figured it could go something like this, prior to actually relaying traffic:

1. Request parameters.
2. replies with nothing.
3. SLP client runs with client command line parameters specified.

OR

1. Request parameters.
2. replies with an override on the pmtu flag. "--pmtu 500".
3. SLP client runs with command line arguments specified, but replaces pmtu value with server override, regardless of the client's requested parameters.
4. SLP starts the client with the specified override from the server - "pmtu 500".