Return to Answer

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a socket service. If it solves that problem, then it is worthwhile; if it doesn't solve a problem or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, different process limits, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard to in a long-lived processes, and worse this is hard to simulate in a development environment. A multitier architecture allows you to kill and respawn the game servers after certain amount of time or number of requests to limit the damages from resource leakages, without disconnecting clients.

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a dedicated queuing service. If it solves that problem, then it is worthwhile; if it doesn't solve a problem or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, different process limits, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard in a long-lived processes, and worse this is hard to replicate in a development environment. A multitier architecture allows you to kill and respawn the game servers after certain amount of time or number of requests to limit the damages from resource leakages, without disrupting service.

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a socket service. If it solves that problem, then it is worthwhile; if it doesn't solve a problem or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, different process limits, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard to in a long-lived processes, and worse this is hard to simulate in a development environment. A multitier architecture allows you to kill and respawn the game servers after certain amount of time or a number of requests to limit the damages from resource leakages.

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a socket service. If it solves that problem, then it is worthwhile; if it doesn't solve a problem or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, different process limits, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard to in a long-lived processes, and worse this is hard to simulate in a development environment. A multitier architecture allows you to kill and respawn the game servers after certain amount of time or number of requests to limit the damages from resource leakages, without disconnecting clients.

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a socket service. If it solves that problem, then it is worthwhile; if it doesn't or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard to in a long-lived processes. A multitier architecture allows you to kill and respawn the game servers after so many requests to limit the damages from resource leakages.

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?

To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a socket service. If it solves that problem, then it is worthwhile; if it doesn't solve a problem or if you don't have a problem to solve to begin with, then it's probably not.

Let's see some reasons why some servers use a multi-tier architecture:

1. Load balancing - load balancing make sense if you want to spread your workload over to multiple worker machines. If your program have bottlenecks that you want to solve simply by having multiple concurrent worker process on the same machine, then it's best in the long run to actually solve the bottleneck, but as a short term workaround, spawning worker processes could be practical.
2. Privilege separation - Maybe you don't want a security breach into your chat server to automatically gain access of your game server or vice versa. If your game server is separate from your in-game chat server, you can configure your game server and chat server to live in separate security domain (e.g. run as different user, with different access privileges, different process limits, etc).
3. Zero downtime upgrade - if you want to achieve zero downtime upgrade, you need to have multiple tiers and configure the system such that when you take down a server for servicing, its requests will be redirected to the other servers in the same tier to ensure continuous service.
4. Breaking limit - if you reach the socket limit, file descriptor limit, a global interpreter lock, etc, you may be able to work around that limit by running multiple processes. Another way to solve this is to change the limit, but that's not always easy as you may have to recompile the kernel, or there may be security or performance implications.
5. Limiting resources leakage - you want to write software that doesn't leak resources, but even in fully garbage managed languages this is extremely hard to in a long-lived processes, and worse this is hard to simulate in a development environment. A multitier architecture allows you to kill and respawn the game servers after certain amount of time or a number of requests to limit the damages from resource leakages.