Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Filter clients in sessions by network properties #43

Open
1 task done
jonbarrow opened this issue Oct 25, 2024 · 1 comment
Open
1 task done
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase

Comments

@jonbarrow
Copy link
Member

Checked Existing

  • I have checked the repository for duplicate issues.

What enhancement would you like to see?

Check players network properties to try and only match players who have compatible networks. Many users report having 118-XXXX class errors. These are related to p2p networking issues. In a lot of cases we can't do anything about this, however it seems like in other cases we can.

Any other details to share? (OPTIONAL)

Now that @DaniElectra has documented the real names of all the PIA errors, we can start to shed some light on why these errors happen.

Some of the most common errors I see people having are:

  • 118-0502 (nn::pia::ResultStationConnectionFailed)
  • 118-0513 (nn::pia::ResultNatTraversalFailedBothEim)
  • 118-0516 (nn::pia::ResultNatTraversalFailedLocalEdmRemoteEim)
  • 118-0519 (nn::pia::ResultRelayFailedRelayNumLimit)
  • 118-0521 (nn::pia::ResultNatTraversalRequestTimeout)
  • 118-0562 (nn::pia::ResultGameServerProcessAborted)

Errors 0502, 0521 and 0562 all seem pretty generic, likely nothing we can do there afaik. However errors 0513, 0516 and 0519 all have pretty detailed names which shed light on the underlying issue.

Taking a look at the docs for StationURL shows that there's 3 main things we can use for this filtering:

  • type - NAT device flags (bitwise). Flag 1 means the connection is behind NAT, flag 2 means the connection is public
  • natm - NAT mapping mode (enum). 1 = "Endpoint independent mapping", whereas 2 = "Endpoint dependent mapping"
  • natf - NAT filtering mode (enum). 1 = "Port independent filtering", whereas 2 = "Port dependent filtering"

These can be used to tell us what kind of network setup a client is using, which should be roughly enough to determine if 2 clients can connect or not. The error codes also seem to support this:

  • ResultNatTraversalFailedBothEim likely means that the error was caused because both clients had natm set to 1 (Eim = "Endpoint independent mapping")
  • ResultNatTraversalFailedLocalEdmRemoteEim likely means that the error was caused because the local user has natm set to 2 and the remote user has natm set to 1 (Eim = "Endpoint independent mapping", and Edm = "Endpoint dependent mapping")
  • ResultRelayFailedRelayNumLimit From what I've seen, PIA is able to connect clients in a way that uses other clients as a "relay". For example if there's 3 clients, PlayerA-C, where PlayerA can connect to both PlayerB and PlayerC, but PlayerC cannot connect to PlayerB, then PlayerC can use PlayerA as a "relay" back to PlayerB. This error is likely caused by there being something incompatible in these users' networks preventing this type of connection, which messes with the relay abilities?

If we do more filtering to only match clients with compatible networks then we will almost certainly see a reduction in 118-XXXX errors in general. https://en.wikipedia.org/wiki/Network_address_translation may also be of some use here.

Some potential downsides/issues/questions to this are:

  • Is this really enough info to do adequate filtering? Nintendo had to be doing something like this on their end, so I assume so, but idk
  • This works well for matching 2 players, but it needs to be expanded to many more. Maybe this filtering would only be done against the host?
  • I have concerns about this possibly making it harder to find matches, if we make bad assumptions about compatible networks or if we do a bad job at finding compatible matches
  • Due to the "secret stuff happening behind the scenes by @shutterbug2000" this issue may become completely redundant in the future, and any effort spent improving this MIGHT be a waste of time
@jonbarrow jonbarrow added enhancement An update to an existing part of the codebase awaiting-approval Topic has not been approved or denied labels Oct 25, 2024
@ashquarky
Copy link
Member

For reference, this blogpost from Tailscale is great and defines all these NAT terms (eim, edm, cones, etc.) and explains why they have compatibility issues https://tailscale.com/blog/how-nat-traversal-works

We can't follow their advice on how to traverse since we don't control the clients, but the information is very good for understanding this

@jonbarrow jonbarrow added approved The topic is approved by a developer and removed awaiting-approval Topic has not been approved or denied labels Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase
Projects
None yet
Development

No branches or pull requests

2 participants