Need help with setup

[Cherden]

Hi,
thanks for implementing this solution!

We are trying to set it up at the moment but have some confusion about the environment. The client and server use netcode.websocket as the transport layer, with wss enabled.

The proxy is configured to use the matchId and queue from the Playfab matchmaking api and runs on the same node as the web server for the WebGL build. The WebGL build then connects to the web server using wss (wss://proxy.domain.com).

Here is where we are confused about the setup. Would the request need to be forwarded by nginx to the container on port 80? How would we need to setup the web server to accept the incoming connections, i.e. which ports need to be mapped to which in the container? Does the Playfab server build need the websocket transport layer as well or communicates the proxy over http? If the server still uses the websocket transport layer, we would need to disable wss there and use ws, correct?

Thanks in advance.

[AustinBrunkhorst]

Hi @Cherden,

If I understand correctly, you have a:

• Web server that hosts your static WebGL assets (HTML/JS, etc.)
• The container from this repository running in the same virtual machine (?) as the web server

And you're not sure how to accept requests from the web server so that they are forwarded to your PlayFab hosted game server.

The WebGL client should ideally connect to the proxy directly. There shouldn't be a need for the web server to forward requests to the proxy server. You can bind an unused host port to 443 on the container in the docker run command for your proxy container. Then, your WebGL client connects to wss://proxy.domain.com:{HostPort}.

Does the Playfab server build need the websocket transport layer as well or communicates the proxy over http

Your PlayFab hosted game server needs to run a websocket server listening on the port configured in your build.

If the server still uses the websocket transport layer, we would need to disable wss there and use ws, correct?

You can use insecure websockets on the game server since the proxy server handles the handshake process associated with secure websockets.

Let me know if my assumptions are correct, or if there were additional questions. It would be helpful on our end to get more details about your architecture and how the web/proxy servers are hosted.

[Cherden]

Thanks for your reply.

We have the proxy running in a container on the same web server as the WebGL build. It exposes port 80 as 8090 and 443 as 443. Playfab instances have one game port 7777/TCP configured. The Playfab server build has a websocket transport layer configured with Secure Connection disabled, listening on port 7777.

When a WebGL client (on https) gets matched through Playfab Matchmaking, it connects to wss://domain.com:443/matchId/queueName. I can see the incoming connection getting logged in the proxy container with the correct FQDN and port, meaning the proxy connection and matchmaking lookup works.

info: Yarp.ReverseProxy.Forwarder.HttpForwarder[9]
      Proxying to http://xxx.azure.com:30000/ HTTP/2 RequestVersionOrLower no-streaming

But there is no log inside the Playfab server instance confirming that the connection was established (for example a OnPlayerConnect callback). This also resulted in the WebGL client getting disconnected immediately and console/nginx logs display a 400 error.

I hope that explains our setup and situation better.

[AustinBrunkhorst]

Thank you for providing these details. A few follow-up questions:

• Have you tried setting SecureConnection to true? I mentioned the opposite in my last response, but it's worth a try.
• Is your PlayFab build using container or process for Server type? If it's using process, you'll need to get the ServerListeningPort from the GSDK during game startup. Here's an example for doing this in Unity.
• Have you tried running your game server locally using the Local Multiplayer Agent? We can use this to rule out a GSDK integration issue.
• Do the console/nginx logs include any more specific details about the 400 error? This HTTP status code usually indicates bad input from the caller.

[Cherden]

I managed to get it to work eventually. Thank you for your help @AustinBrunkhorst.

As a reference for future devs stuck in my position:
The setup described in the previous message was correct, our nginx configuration was wrong. The working config is

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}
upstream websocket {
  server localhost:8090;
}
server {
  listen 443 ssl;
  server_name proxy.domain.com;
  ssl_session_cache shared:acme_nginx_SSL:10m;
  ssl_session_timeout 1440m;
  ssl_session_tickets off;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;
  ssl_ciphers "yada-yada-yada";
  ssl_certificate /path/to/certs/fullchain.cer;
  ssl_certificate_key /path/to/certs/key.key;
  location / {
     proxy_pass http://websocket;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
  }
}

The line proxy_set_header Connection "upgrade"; fixed the issue. It was set to proxy_set_header Connection keep-alive; before.

Note:

• server localhost:8090;: Set the port to the one you expose port 80 from the container from.
• Adjust ssl_ciphers, ssl_certificate, ssl_certificate_key.