question

Jason Bakker avatar image
Jason Bakker asked

Servers 2.0 - Ports don't seem to be opening for requested multiplayer server

Hi there,

We're attempting to get the new multiplayer flow implemented in our Unity game, and are having trouble getting our UNet layer to communicate between the client and the server.

We are able to request the multiplayer server correctly, and I've confirmed the server is listening to the UDP port that we specify in the Ports (using 0.0.0.0 as the listening IP address), and the client is attempting to connect to the correct ip/port that it receives back from the multiplayer server request.

When I inspect the docker container on the running server, the correct ports seem to be open in UDP mode. The only thing that I'm seeing that might be off is that when I use docker exec -it powershell to go inside the running container, the netstat -ano doesn't include the port that I'm using (7777) - though in the documentation here it suggests that these will be 'different than the container ports', so I'm not sure if that's where the error is - I can't find a mapping between the open ports reported by netstat -ano inside the container and the port we've set up and been told to listen on (7777).

On the server, I'm grabbing the "game_port" key out of PlayFab.PlayFabMultiplayerAgentAPI.GetConfigSettings, and it's set to 7777 - is it possible that PlayFab is setting up a different port inside the docker container, but not letting us know about it?

Are you able to check what's going on? Our title ID is 9A23D.

multiplayer
10 |1200

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

Jason Bakker avatar image
Jason Bakker answered

I've resolved this issue - it was occurring when using LocalMultiplayerAgent as well, but then when I did a local build of the server (instead of through our build pipeline), the client could connect to the server. I discovered that builds that were occurring through our build pipeline had a define set that would modify UNET such that all packets were encrypted; but because I didn't have that define set on the client, the client would be sending unencrypted UNET connection requests to the Server, and the Server wouldn't be able to parse what they were, because it was expecting all UNET communication from Clients to be encrypted. I just had to ensure that both sides (Client and Server) matched in terms of whether they were communicating using encrypted or unencrypted messages.

Thanks again for the help Dimitris!

10 |1200

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

Dimitris-Ilias Gkanatsios avatar image
Dimitris-Ilias Gkanatsios answered

When you run your Unity server, it will listen to whatever port you specify it to. The fact that you cannot find 7777 on "netstat -ano" is kinda worrying. I'd expect it to be there. Is your server working correctly? Can you try the same configuration with LocalMultiplayerAgent?

To your comment about the documentation: yeah, ports in the VM will be different than the ports on the container. So, e.g. port 30000 on the VM will be mapped to 7777 in the container. Check this video PlayFab Multiplayer Hosted Servers part 1: Multiplayer Servers Quick Start - YouTube at around minute 22, where we explain port mapping.

1 comment
10 |1200

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

Jason Bakker avatar image Jason Bakker commented ·

Thanks Dimitris!

Ah, I realised that I was checking "netstat -ano" before the server had been allocated and started listening - it does show up in "netstat -ano' once this occurs. It must be something else in this case.

One thing that we're doing is that we start the Server listening on the port that we specify only once it receives the OnServerActive callback, and there may be delays between us receiving the OnServerActive callback from the PlayFabMultiplayerAgentAPI, and our Server opening the port. I might re-organise our logical structure a little bit on the Server to see if only reporting ReadyForPlayers after our port is already open will help.

I'm assuming that a Connect attempt from the Client could be lost if it is received on the VM before our Server has opened the specified port (the VM would pass it through to the docker instance, but our Server wouldn't be listening to that port yet).

Thanks again, your response was great, it's really narrowed down what the issue might be. The studio is breaking for the holidays, but when I get back to this in the new year I'll aim to post the results. I'll also see what happens when using LocalMultiplayerAgent as well, as you suggested.

0 Likes 0 ·

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.