[Regression]: Revert to finding clients by connection ID, not PID

[jonbarrow]

Checked Existing

• I have checked the repository for duplicate issues.

What happened?

There appears to be issues with finding the correct user connections based on the PID, resulting in matchmaking errors

What was the previous functionality?

There were less of these errors

When did this occur?

In the recent matchmaking updates we swapped from getting connections by the connection ID to using the users PID in certain contexts. Those being:

• MatchMaking::GetSessionURLs
• SecureConnection::RequestURLs
• utils.SendNotificationEvent which is used in 16 places across various methods

Other relevant information. (OPTIONAL)

Using the PID seems convenient as we can easily obtain the clients PID from multiple sources, however it has the issue of potentially pulling the wrong connection in one of 2 situations:

1. An old stale connection is still lingering around, due to a bug somewhere (this is theorized to already be happening in nex-go)
2. The same user is logged in on 2 different platforms (Wii U and Cemu, which may or may not be legitimate usage given the circumstances)

We should look into reverting back to using the connection ID where possible. In cases where we NEED to use the PID, I propose we add a new method to nex-go to return all instances of the PID not just the first one, to try and cover all the bases

This won't fix the underlying bug, if that is the cause, but it should reduce the number of errors

For cases like MatchMaking::GetSessionURLs, where all we have is limited information about players (this method only sends the gathering ID, which we use to lookup the host PID) we should see if we can also store the connection ID. Adding a new column to the gatherings database to add the host/player connection IDs alongside the PIDs and use the connection IDs for pulling the correct connections. This would also allow us to properly support players logged into the same account multiple times

[DaniElectra]

Since this change is trying to workaround a bug from nex-go, I believe we should try to solve the bug on the core library instead of trying to workaround it here, especially since this goes against the principle of identifying a connection with a PID.

Trying to allow a PID to connect from multiple places is not feasible imo (and it also wasn't possible on NN) due to how NEX and its protocols are fundamentally designed, and trying to force this will probably lead to more issues compared to only stale connections.

[jonbarrow]

I agree the underlying issue is most likely in nex-go and that that's where it should be fixed long term, but until that happens (because we still don't know why the issue occurs) this would act as a good temporary fix to mitigate the issues. I think it's worth considering this so that we reduce the number of errors while we research the real issue

and it also wasn't possible on NN

Is there a source for this? I 100% remember being able to connect to the same server from the same NNID on both real hardware and Cemu at the same time. This was also shown to be possible from the Cemu piracy scene, where it was very common for people to share console/account dumps without issues

The only case I can find where this wasn't possible is in Mario Kart 8, but this seems to have been intentionally designed that way rather than things just breaking (it's been reported that the server would kick the previous connection when a new one was established):

• https://www.reddit.com/r/cemu/s/SDUDaCwS2h
• https://www.reddit.com/r/cemu/s/LstcqmXDEl

I'm positive this was possible to do on NN, and in that case the only real way to do that is with the connection ID or else they'd have the same issues we have right now

[DaniElectra]

Is there a source for this?

I will admit that it was something I hadn't tested, but I honestly thought it wasn't possible to do. I apologize

If that was actually possible, then I'm more open to these changes, but it leaves me some open questions. For example, the messaging protocol uses a PID as input. If I sent a message would it get sent to all connections attached to it? I also feel that there would be undefined behavior on some games that may not expect two connections with the same PID, but that's just speculation

[jonbarrow]

I would assume it would send it to all connections? That would make the most sense to me?

I do agree that there may be some cases where some undefined behavior may arise, and based on reports of MK8 seemingly being designed to disallow this behavior, I'm speculating that maybe it was a configurable option for some games?

Also to keep things tracked, I'm copy-pasting a message from @shutterbug2000 on discord:

on Switch iirc the Nintendo account ID (BAAS id more accurately) is what's used as the NEX account PID
you can have that account on multiple Switches, and it works to login multiple places afaik (albeit some games have issues)
so unless they heavily altered NEX to account for that (doubtful) I think it should work fine?

[ashquarky]

For Splatoon we have reverted to v2.0.5 to get around this: PretendoNetwork/splatoon#12