I’ve been working to set up Relay as a way for clients to connect via WSS to my Multiplay hosted dedicated server.
It seems to work, but I am seeing a strange behaviour - Only the first server that spins up on the Multiplay machine stays connected to a Relay Allocation. The rest seem to drop, and the Allocation eventually times out, invalidating the join code. This happens consistently. When a new machine spins up, the first server on it manages to host.
Currently I run 4 servers for each machine.
To sanity check that this is not some logical error - Does Relay support this scenario? The machine will be making multiple allocations from the same IP, each new allocation for each new Multiplay server.
I was wondering if this was some restriction by Relay, disallowing multiple hosts from the same IP, or if I’m dealing with some other problem.
Is this a documented requirement somewhere?
With a dedicated server you needn’t use the Relay service. To use WSS you have to specify “wss” as the connection type string in the Transport setup and do so for both server and clients.
I’m unsure about the certificates as I mentioned in an earlier thread, not sure if that was also you. 
This should work fine as I’ve seen Relay + Multiplay workloads doing similar with up to 10 servers per machine and individual game sessions with 20+ players connected to each running for an hour. Multiplay server allocations have their own port range for the IP address, so connection wise that’s unique.
To clarify, you create and join a Relay from the game server binary and share that join code to game clients out of band (e.g. via Lobby) and by the time the game client tries to connect the Relay has deallocated?
Is there anything unique about how you’re observing that first allocation staying alive? Perhaps joining with a client much more quickly, since it’s first. Based on what you’re describing it seems like the Relay host never binds to the allocation and you hit the 60 second timeout. Can you confirm you’re following this connection flow and still seeing the problem? Connection flow
This is a workaround some folks use to get WSS working with Multiplay since certs per server aren’t available. We do have feature roadmap items to support WSS natively on Multiplay, but it’s not scheduled for a release yet.
That’s our situation exactly. We use WSS not for browsers but for functioning under restrictive firewalls. Fingers crossed for certs per server sometime in the future, that would make it a lot easier to use Multiplay in enterprise settings.
We did also try implementing a reverse WSS proxy, but with Multiplay machine IP’s being dynamically allocated it was tricky to figure out how to do that robustly and securely.
So, the Relay workaround is the path of least resistance.
Thank you for this, that means it’s probably a local error on our side. I’m going to investigate further and share if I find any relevant information.
Correct, this is what seems to happen. We share the join code out of band, but using our own backend services instead of Unity Lobby, so it’s possible the error is due to how we’re handling this.
Something I noticed yesterday was that clients seemed to be connecting on the same Relay IP+port for all servers, maybe something has been misconfigured there.
It seems that way, but in all cases the client tries to connect to the host almost immediately after the host has connected to Relay and shared the join code. I observed that even without clients connected, the host seems to keep the connection alive (at least after 5-10 minutes).
On further investigation, this seems to happen on subsequent servers launching on the machine:
Socket creation failed (error 67108865: External/baselib/baselib/Source/Posix/Baselib_Socket_PosixApi.inl.h(309):Baselib_Socket_Bind: Address in use (0x04000001) - Address already in use (errno:0x00000062)
Listen request for address 0.0.0.0:37000 failed.
Based on Relay metrics, it does seem like we manage to create multiple allocations, but we always end up trying to listen on the same port (37000 in this case), and that fails because the same machine cannot create multiple listen sockets on the same port.
I’m trying to understand how this can happen. Once we’ve allocated the Relay server, we parse the data and use the Endpoint to listen, something like:
// Allocate, then parse data
var allocation = await RelayService.Instance.CreateAllocationAsync(20);
var hostRelayData = new RelayServerData(allocation, "dtls");
// Register driver
var settings = DefaultDriverBuilder.GetNetworkSettings();
settings = settings.WithRelayParameters(ref hostRelayData);
DefaultDriverBuilder.RegisterServerDriver(world, ref driverStore, netDebug, settings);
// Start listening (with N4E)
var listenEndpoint = NetworkEndpoint.AnyIpv4.WithPort(hostRelayData.Endpoint.Port);
var listenRequest = entityManager.CreateEntity(typeof(NetworkStreamRequestListen));
entityManager.SetComponentData(listenRequest, new NetworkStreamRequestListen { Endpoint = listenEndpoint });
Is it expected that going through this process, I would end up with multiple allocations targeting the same port? I suppose it’s possible I have two different Relay server IPs, but listening with NetworkEndpoint.AnyIpv4.WithPort it’s possible to have a collision on ports?
Solution:
I had a few configuration problems that I fixed, but the problem described in the original post was ultimately caused by trying to listen on the same port on multiple servers.
This can happen because each server on the machine may get allocated Relay servers on different IPs targeting the same port.
Changing my listen code from listening on NetworkEndpoint.AnyIpv4.WithPort(hostRelayData.Endpoint.Port) to NetworkEndpoint.AnyIpv4 on the server resolved the issue.
Thanks for the inputs!