There’s at least a couple complete stories in there, good read.
I suggested a follow-up task: their stuff should kill itself when it can’t get all of the ports it needs. Also, the thing that runs tasks should be set to check all of the ports too, and if it can’t get satisfaction, it should kill the task.
Ugh I had to deal with something similar in Unreal Engine. By default there’s a mechanism within the Ip/NetConnection interfaces that will try subsequent ports if it can’t bind to the one specified. So if you run multiple servers on the same host all with the default 7777 port; the second instance will first try 7777 and fail, then try 7778 and succeed on that one. In theory this could be a good thing if you just use the value of the port it got for everything afterwards. However, we had a deployment issue where multiple servers were specified to use the same port, and we’d use the specified port to route players. So we got into a spot where players would be routed to join servers they were never supposed to, which would result in player facing errors like… “Server is Full” on what should have been a fresh/empty instance.
There’s a configuration option in the ini files to disable this behavior and the server effectively panics if it can’t bind to the single specified port. I think we ran into this issue once or twice again since changing that option and instead of a multiple weeks and log spelunking sessions of “How is this possible” It was like “Oh the servers dying because it can’t bind to this port” and that became a MUCH MUCH easier investigation…
There’s at least a couple complete stories in there, good read.
Ugh I had to deal with something similar in Unreal Engine. By default there’s a mechanism within the Ip/NetConnection interfaces that will try subsequent ports if it can’t bind to the one specified. So if you run multiple servers on the same host all with the default 7777 port; the second instance will first try 7777 and fail, then try 7778 and succeed on that one. In theory this could be a good thing if you just use the value of the port it got for everything afterwards. However, we had a deployment issue where multiple servers were specified to use the same port, and we’d use the specified port to route players. So we got into a spot where players would be routed to join servers they were never supposed to, which would result in player facing errors like… “Server is Full” on what should have been a fresh/empty instance.
There’s a configuration option in the ini files to disable this behavior and the server effectively panics if it can’t bind to the single specified port. I think we ran into this issue once or twice again since changing that option and instead of a multiple weeks and log spelunking sessions of “How is this possible” It was like “Oh the servers dying because it can’t bind to this port” and that became a MUCH MUCH easier investigation…
Same circus, same elephants, different shit. :)