Lots of changes on common protocols

[DaniElectra]

• Since we now store the client station URLs on nex.Client, there's no
  need for external handlers to do so, so remove them. Also, the handlers
  were deprecated as they didn't do anything anyway.
• Use common struct on NAT traversal and remove external handlers,
  as we now store the client station URLs on nex.Client. And implement
  ReportNATTraversalResult.
• Various changes to Matchmaking:
  • Use structure.Copy() and structure.Equal() now that they are
    implemented.
  • Add notification types that weren't used before.
  • Remove handlers for MatchMaking(-Ext) and use global sessions for
    handling rooms.
  • And possibly more

Depends on PretendoNetwork/nex-protocols-go#24

[DaniElectra]

While I was testing this on MK7, everything seemed to work fine, except that one of the clients would randomly disconnect in-game from the session (also causing the other client to leave) and from NEX for seemingly no reason (there aren't any requests sent to NEX before this happening, just the Leaving message).

Luckily, the NEX matchmaking sessions themselves seem to work fine. I can't test nat traversal however, since both machines are connected to the same network

[jonbarrow]

(there aren't any requests sent to NEX before this happening, just the Leaving message).

About how long does this take to happen? It sounds like a ping timeout issue

[DaniElectra]

(there aren't any requests sent to NEX before this happening, just the Leaving message).

About how long does this take to happen? It sounds like a ping timeout issue

It would happen some seconds after the game had started (the time varied on each test).
Actually, that may be it, since the server is set with ping after 999 seconds and I hadn't changed that parameter

I will try again tomorrow

[DaniElectra]

Interestingly, the issue above appears on Race mode, but on Battle mode almost everything works just fine, and I can play as many rounds as I want. However, when one of the participants leaves, the EndParticipation isn't sent for some reason (but the client doesn't disconnect from the server), and the other player will show a connection error.

I wonder if this is a me issue, because of having the server and consoles on the same network? idk

[jonbarrow]

It's possible that's causing issues, yeah. I've had a few issues when hosting the servers on the same network as the clients in the past. That is weird though

[jonbarrow]

I see this was marked as open, no longer a draft. Are we still waiting for more changes or is this ready for review now?

[DaniElectra]

Yes, it's ready for review

[jonbarrow]

Some things addressed here are not actually changes you made, but they are around the code you are working on and this PR seems to be broadly covering a refactor of the common protocols, so I figured they fit

Also full transparency, since I am personally not very familiar with the matchmaking system specifically, my review is strictly on code quality and performance. I have not exactly reviewed the logic behind the matchmaking itself, and I would prefer if I could get another set of eyes on that. I have already assigned @shutterbug2000 for this task as well, but will likely also call upon Rambo since he's done great work on MK8

You will also need to update the go modules, as I have pushed updates to them and made some breaking changes to some protocols

[jonbarrow]

This value doesn't appear to be checked anywhere. Though very unlikely, if a server runs for long enough and people keep creating sessions then this will reach the max uint32. Reaching this value may create unexpected side effects (such as the above check thinking no session was found, which I addressed in an earlier comment as well). This should be bounds checked

[shutterbug2000]

Looks good to me

[jonbarrow]

Relating to a comment we talked about the other day, nex-protocols-go version 1.0.30 now has a GatheringFlags structure in the match making protocol to hold all the possible flags a gathering can have. I added 0x20 and 0x200 as well despite them being labeled as "unknown"

[jonbarrow]

Carrying over from Discord, @shutterbug2000 has confirmed that the matchmaking changes here work fine in MK7 during his testing. So this PR should be good to merge once the Go modules are updated (I merged your other PR PretendoNetwork/nex-protocols-go#25 and made a new release) and once the other issues are looked at

[DaniElectra]

I changed invalid values to be zero, as it can't be a valid gathering ID nor a valid connection ID. To get a gathering ID, I changed the counter to the function GetSessionIndex(), which will check for empty sessions starting from ID 1. I tested this implementation in isolation (with maps with a million values) with minimal performance impact. Considering a PID can only create one session, it's impossible that we reach the max uint32 limit, so if we get an error, it should be an issue of not erasing empty sessions.

I also implemented time validation on Kerberos tickets. If the ticket is expired, we kick the client for timeout, as on Mario Kart 7 the client was still sending data packets when using a graceful kick (using graceful kicks aren't really an issue though, as we delete the client and the server can't decrypt those data packets anymore [PRUDPv0] Error decoding packet data: [PRUDPv0] Error parsing RMC request: RMC Request size does not match length of buffer, but the client would get spammy with those packets).