question

Markus Henschel avatar image
Markus Henschel asked

Validate Users for Multiplayer 2.0 Servers with Server Backfill Tickets

Hello,

I'm using server backfill tickets with multipler servers 2.0 and the new matchmaking with automatic server allocation. I know how I can validate connecting users for the initial users. But if I use server backfill tickets I run into an issue.

I call CreateServerBackfillTcket and then continuously poll the server backfill ticket until the ticket is going to the Matched state. Then I call GetMatch. But I think it can happen that new clients in the newly created match connect before my dedicated server receives the match result from GetMatch. So in this case I don't know how to validate new users. Keeping newly connected users in a seperate queue on the dedicated server until it received the reply to the GetMatch call isn't so easy in this case as the Engine (UE4) has a certain flow that doesn't allow this (or makes it hard to implement).

But with backfill tickets it is especially important to validate connecting users. For instance I want to wait a certain time for initial users to connect. Then I call GetMatch and filter the users that didn't connect so far. If necessary I call CreateServerBackfillTicket. Let's say I filter user Fred because it took to long for him to connect and then I look for more users. But then suddenly Fred finally does connect. I don't want to not let Fred in anymore because I might already have another player connecting from the server backfill ticket. I could certainly remember Fred to have timed out and not let him in anymore. But to make this even more confusing Fred might be picked by the server backfill ticket later because he queued again.

Do you see any way to validate users when using server backfill tickets that doesn't suffer from the race condition of the user connecting before the server gets the result of GetMatch? I could imagine to sneak in some kind of secret generated on the dedicated server into the matchmaking attributes, let the newly found client inspect those and forward this to the server. But I would hope there is a more straight forwards solution.

Thanks

Markus

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

2 Answers

·
Citrus Yan avatar image
Citrus Yan answered

As I understand it, the clients and the dedicated servers are able to retrieve the match result at almost the same time, therefore, the interval between new clients connecting and the server receiving the match result shouldn’t take very long (if that happens) . And, since keeping newly connected users in a separate queue is cumbersome in UE4, maybe you can simply have the server decline incoming connections when match result is not ready and have the clients retry connections when that happens. The number of retries should be quite small because as mentioned above, the servers are also able to receive match result when clients are able to do so.

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Markus Henschel avatar image
Markus Henschel answered

I was trying to implement retrying for the game clients and this is also not super trivial in UE4. I'm sure it can be done somehow but I implemented several workarounds.

1. Delay the client call to connect to the server by ticket polling time. The server polls the matchmaking ticket the same way the client does. So the client can get the "Matched" ticket state earlier then the server. This just reduces the likeliness of the race condition.

2. I let the server put some generated secret into the matchmaking attributes of the members of the backfill ticket. The clients matched with this ticket retrieve the matchmaking attributes of all members, extract the secret and supply it when connecting to the server so it can be checked by the server.

3. The clients supply the match id when connecting to the server. Even if the server might not know the right match id yet when clients connect it can at least remember the previous match id(s) to reject people connecting from previous matches.

2. or 3. Should actually work for well behaving clients but there might be some loop holes for malicious clients. So on top of that I would wait for GetMatch to complete and kick players not in the result.

From my point of view there is a step missing for server backfill tickets. It is pretty similar to normal matchmaking with server allocation. If a match is made tickets first go into a "Waiting for Server" state. A dedicated server is started and the matchmaker waits for it to be ready to accept connections. For a server backfill ticket it would also make sense to keep the client matchmaking tickets in that state if a match is made. The server could call GetMatch wait for the result and then signal the matchmaker via some API call that it is ready. After that client tickets would go into the Matched state and could connect.

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.