Support cancelling MultiplayerService session joining functions

[trev3d]

Is your feature request related to a problem? Please describe. It takes several seconds to join a session through MultiplayerService. I'd like to let users cancel a connection attempt during the connection process.

Describe the solution you'd like I'd like to pass cancellation tokens to functions like MultiplayerService.Instance.CreateOrJoinSessionAsync.

Describe alternatives you've considered I've tried preventing the NetworkManager from connecting to a session if my own connection function wrapping MultiplayerService.Instance.CreateOrJoinSessionAsync is cancelled, but I cannot find a clean way to do this. I have also considered modifying the Unity.Services.Multiplayer package myself, but I would rather not do this.

[EmandM]

Hi, thanks for your submission!

There's a lot complexity in this space as CreateOrJoinSessionAsync can start the allocation of cloud resources. Due to this "cancelling" a request can have some different meanings.

Cancellation could mean:

1. Cancelling the allocation of cloud resources.
2. Cancelling the call to start the NetworkManager.

For oir information, which type of cancellation are you thinking here? Are there other cancellation behaviours you're looking for?

[trev3d]

I'd like to cancel the network manager start call. While cancelling cloud resource allocation would be nice, I'm more concerned about this from a UX perspective: I don't want to make the user wait to finish connecting if they decide not to connect.

[Edvinas01]

To add to this, we're also having some issues with cancelling as the players have a lot of freedom in our game related to how sessions are created. To give some context, players can freely enter "portals" which establish a session in DA, while its being established (which can take some time) they can hop into another level portal which starts creating a new session - this is where I need to cancel the old call. If the session API were to support cancelling (e.g., CreateOrJoinSessionAsync in this case), I'd expect all underlying UGS calls to be cancelled/reverted so they're not in a partial state where for example a Lobby is created and a Relay is not.

Though I understand that this can be quite complex, seeing as none of UGS support cancellation, however I think this is quite a big oversight when dealing with async calls.

[EmandM]

The team that is maintaining the SDK are working on the full comprehensive cancellation path, however it's a complex space with a lot of moving parts. Cancellation was definitely overlooked while building the initial implementation.

It's very useful for them to know which parts to prioritize as they build out cancellation. Obviously the end state is that everything, including the cloud resources, is cancelled cleanly and intuitively. Knowing whether the cloud resources or the local NetworkManager experience is more immediately painful helps a lot in deciding what needs to be implemented first.

[Edvinas01]

Personally I'm experiencing most issues with "zombie players" staying in lobbies when a connection was cancelled or the player leaves without a clean disconnect. I'm also using CreateOrJoinSessionAsync in combination with MatchmakeSessionAsync (trying out various methods to see which one is more stable). In some cases on my end, UGS thinks that a player is in a lobby and produces player is already a member of the lobby error (don't have the full log at hand right now), which renders some lobbies un-joinable for players in some cases. Given this I'd say priority should be on making sure lobbies are correctly cleaned up on cancel when using session join functions specified in join session docs. Next would be Relay I suppose, however I haven't seen any errors related to that just yet. Perhaps @trev3d has some more ideas, I don't want to hijack the issue 😅

[trev3d]

In some cases on my end, UGS thinks that a player is in a lobby and produces player is already a member of the lobby error (don't have the full log at hand right now), which renders some lobbies un-joinable for players in some cases.

I've encountered this too. If you open a new issue I'll gladly comment on it, but we should stay on-topic (cancellation) for maintainers' sakes.