Hi, why my matchmaking ticketing fail with this result “MultiplayAllocationError: request error: maximum capacity reached”?
I set backfill true but new player always forced to open new server.
There could be multiple things happening here.
For the “maximum capacity reached”, This mean that the matchmaker can’t allocate new servers, make sure that all your game server that shouldn’t be running anymore have exited properly (You can see what server is running on UDash in Multiplayer > Game Server Hosting > Servers). You can increase the maximum number available servers on UDash in Multiplayer > Game Server Hosting > Fleets > you fleet > Scaling settings.
For your backfilling issues, are you properly approving the backfill ticket every ~20sec ?
More about backfilling here.
I am getting the same error,
when a player joins the server a second time after leaving the server its matchmaker through this error
“[Matchmaker] [MatchAssignmentError] - Failed - MultiplayAllocationError: request error: maximum capacity reached (1)”
When a player joins and leaves the server I approve and update the ticket. I am using the flow same as the MegaCity Metro sample.
Can anyone help, what could be the reason?
I got this same issue. Did you ever resolve it?
As @FlorianAtUnity mentioned before, you have to look at:
UDash in Multiplayer => Game Server Hosting => Fleets => Scaling settings => Max available servers
Scripts.zip (4.0 KB)
I am also having problem. I approved, Update my backfill in the update method every 1 second. But i am still having the same error.
Pinged you in a message too, but this could be useful for other too.
You were attempting to use the same user profile to connect to the matchmaker service multiple times.
So make sure that in your client code you specify some sort of unique profile identifier for each local client that you are testing with.
something along the lines could work:
await UnityServices.InitializeAsync();
// needed for making the local clients to be treated as unique players
Random.InitState(DateTime.Now.Millisecond);
AuthenticationService.Instance.SwitchProfile($"Player_{Math.Ceiling(Random.value * 42)}");
await AuthenticationService.Instance.SignInAnonymouslyAsync();
How do we ensure that when a user disconnects, they can reconnect right away? What steps can we take to debug this issue?
Hey @AdamB_BVG,
You can query which sessions the current user is a part of, and you should be using the reconnect flow, not a simple join if a user want’s to reconnect in the first few seconds after they got disconnected.
hope this helps answer your question,
Kálmán
I may be misunderstanding, but I think these docs are specific to Unity’s Netcode? and not related to matchmaker, correct? What about for other Netcode solutions? Is there a way to see if matchmaker already has the user assigned?
No the linked docs are not specific to the Netcode solutions.
When you are using the Multiplayer Services SDK introduced Sessions API, the sessions are a composite of multiple underlying systems.
Matchmaker is one of the systems. Lobby, Relay, Multiplay and more are other components of it.
We aimed to make all of these as Netcode independent as they can be. By default we provide NetworkHandlers for our netcode variants GameObjects and Entities but you can use a custom network handler with sessions to integrate any netcode solutions. See this short example here.
Matchmaker only plays a role in assigning a player to a given lobby / session. It does not actually keep a state for which players are assigned where. Sessions does.
You can use await MultiplayerService.Instance.GetJoinedSessionIdsAsync(); to validate if the player is already part of any session or not.
When you want to reconnect to a session, you can either use the reconnect flow in case the player is still part of the session in question, or if they are not part of it any more, simply use the join flow to connect again.
Thank you so much for the clarification, I’ll try this out.
I’ve started implementing sessions, and ran into an issue.
I get an error when I setup the session on the server that says I can’t set MaxPlayers above 150.
Why would this limitation be there? If this is the case, we likely can’t use sessions, even if it seems like a much easier system to manage. We are hoping to have 200-500 users per server concurrently.
Furthermore, I just wanted to give some feedback that I find the documentation super confusing about sessions.
in the manual: Multiplayer sessions
session represents a group of connected players and manages their interactions through various connection types, including client-hosted solutions like Relay and Distributed Authority, or dedicated game servers through Multiplay Hosting. Sessions work with either the Netcode for GameObjects or the Netcode for Entities networking libraries. Sessions provide an abstraction layer for managing multiplayer game states, handling everything from initial player connections to ongoing gameplay interactions, and automatically handle complex multiplayer operations such as host election, player joining and leaving, and network connection establishment.
This really makes it seem like it’s not compatible with 3rd party Netcode. However my experiments and your message above contradicts this. There’s zero documentation on how this should work.
Sessions also seems to be able to handle backfill automatically, which I previously spent over a week implementing, and it seems like an overall much better system. (despite the possible 150 player limit), yet there’s no mention of this on either the Matchmaking or Multiplay Manuals! This would have saved a lot of time and effort.
So after some much more intense testing, I think that basically sessions do not work with 3rd party Netcode. I got everything more or less working, The servers would spin up… everything seemed fine, but clients just couldn’t connect.
Browsing through the logs on the server, there was an error message saying something like “Netcode for GameObjects or Netcode for Entities must be installed.”
So I’m still having issues where clients can’t reconnect right away with the same profile once leaving a server. Matchmaker won’t accept their ticket since it thinks our server already has them connected. After a little while they can reconnect just fine, but it’s definitely not right away, even though we remove them from the backfill ticket when they disconnect. I get the error about maximum capacity reached (1), because it won’t let them reconnect and I have my server scaling settings to max out at 1, so it can’t spin up a new instance, even though there’s room on the server.
Hi @AdamB_BVG
Thank you for the feedback! We know that the documentation could use some improvements, the good news is that we are actively working on it. The bad news is that it may take some time for the updates to roll out.
The 150 player limitation does exists at the moment on the Lobby / Session side of the service stack. Sadly this is only mentioned in one of the code snippets and on the cloud dashboard under the Lobby configuration page.
If you don’t mind me asking what would be the exact use-case that would require more than 150 players? We can potentially suggest some workarounds, but we’d like to test them internally first.
I am very surprised to see that “Netcode for GameObjects or Netcode for Entities must be installed.” error message. I am not aware of any limitation on the SDK’s side that would require you to use it with those two solutions only. I will have to dig around and try to reproduce that issue. If you have any repro steps that you could share, don’t hesitate 
I do not have all the answers for you yet, I will get back to you as soon as I can.
cheers,
Kálmán
Quick update regarding the Netcode for GameObjects or Netcode for Entities package need to be installed message.
This error message comes from an internal builder that would only show up if you are not overriding the underlying network handler of the session by adding a custom handler to your session (both on the client and server side).
You need to implement an INetworkHandler, and pass it to the session system for handling a 3rd party networking solution. For the mean time, you can look at the NGO one we ship with the package for some inspiration. Look for: GameObjectsNetcodeNetworkHandler.cs in your project.
At the moment we do not have a great example of the implementation, but this snippet shows how to apply the data handler on your session:
Thanks, I had implemented a custom handler on the server but not the client, so that might explain it (although the error I got was on the server)
However, I don’t think I can continue this exploration due to the 150 max player limit.
We are hoping to support around 500 connections per server or even more. In our not-yet-optimized initial load tests we had 40 players connected only using around 4% peak of our server’s resources, so it seems very much possible. For reference it was on a single multiplay virtual instance allocated 100% to a single server, using FishNet as the Netcode (bayou transport).
Anyway thanks for getting back to me, but we have to end this line of research with Sessions due to the hard cap. I haven’t found any limits on Matchmaker or Multiplay that would suggest 500 is not possible.
The limit is on the Lobby side of the service stack as Lobby is connected to some other services that needs to keep the latency reasonable for users.
The following suggestion is really not tested, but should be possible based on my short research, but please take it with a grain (or more) of salt:
If you want to increase the max player count tied to a single server, and your metrics show that the server can handle it. You could create more than 1 session (lobby) in the spawned server. Often missed fact, that a single player (even a server) can be part of multiple Sessions at the same time.
You could connect the 1,2,3-x sessions through some session properties and in your code implement custom logic to handle the connection between them. However I think you do need to share the netcode instance for these sessions in order for things to function. This can be done through your custom INetworkHandler.
Note that multiple lobbies could incur more cost though, please take that into account:
Session is built on top of the Lobby grouping mechanism and is connected with all the other services in a convenient wrapper interface. We do think it can be customized easily, but we have to abide by the underlying service limitations.
I do understand however if you do not have the time / budget to experiment with this approach
One last question tough! Is your team working on an mmo? 
Best of luck,
Kálmán
Yes we are. We plan to have a few big servers for public areas and smaller instances for private/small group areas.