1 réponse
- Le plus récent
- Le plus de votes
- La plupart des commentaires
0
Hey Chanson,
When a server process tries to acquire a port that has already been acquired by a second process I'm assuming it fails? If so, can the server backoff and retry to find the next port that is available? This might help deal with contention when multiple processes are detecting the same port as available.
Alternatively, you could pass in a static port number as a parameter to your ServerLaunchParameters
. Since you have a fixed number of processes are going to launch, each could read a different unique parameter that it can use to as the port number it will try to acquire, completely avoiding contention.
Thanks!
répondu il y a 2 ans
Contenus pertinents
- demandé il y a un an
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 3 ans
hey! thank you for the answer:
When a server process tries to acquire a port that has already been acquired by a second process I'm assuming it fails? If so, can the server backoff and retry to find the next port that is available?
Yes, this is exactly what happens when I test locally. The first process will start on port 5000, and the next on 5001, etc. However, this behavior is not carrying over to my GameLift instances.
Alternatively, you could pass in a static port number as a parameter to your ServerLaunchParameters. Since you have a fixed number of processes are going to launch, each could read a different unique parameter that it can use to as the port number it will try to acquire, completely avoiding contention.
Is this a best practice? If I only have 5 game sessions active, I wouldn't want 50 active processes, right?