Ejecutar tanto el servidor como el cliente dentro del mismo proceso

Pregunta

Acabo de comenzar a trabajar con Lidgren y la creación de redes por primera vez, y me di cuenta de que es posible ejecutar tanto el servidor como el cliente dentro del mismo proceso.

¿Se desaconseja esta práctica por alguna razón?

Contexto

La razón por la que pregunto es porque teoricé que este concepto podría permitirme tratar los modos de un solo jugador y multijugador como uno solo, lo que sería muy útil.

Siguiendo mi línea de pensamiento, esta es la distribución que tenía en mente:

• Un jugador: 1 servidor + 1 cliente en el mismo proceso. ¿Qué tan rápido son las comunicaciones?
• Multijugador: igual que un jugador para el host + 1 cliente adicional para cada otro jugador.

El flujo de ejecución que estoy representando es para que los clientes reciban la entrada del usuario y envíen una notificación al servidor. Luego, el servidor lo valida y transmite una acción para que todos los clientes la ejecuten. No debería importar si solo hay un cliente (es decir, un jugador) o varios clientes (es decir, multijugador).

Esto es básicamente una pregunta de proceso versus hilo, ambos no son muy diferentes, a veces los hilos se llaman procesos livianos. La mayor diferencia es que un proceso separado tiene su propio espacio de direcciones, pero hay otras diferencias (1):

Por proceso

• espacio de dirección
• Variables globales
• Abrir archivos
• Procesos hijos
• Alarmas pendientes, interrupciones y manejadores de señal

Por hilo

• Contador de programa
• Registros
• Apilar
• Estado

En base a estas diferencias, podría ser útil tener un servidor y un hilo de cliente en el mismo proceso para que pueda compartir identificadores de archivos y variables globales. Este sería un argumento para el enfoque 'en el mismo proceso', otro argumento (pequeño) sería que solo se obtiene una ventana emergente 'Windows Firewall' por proceso. Un argumento para el enfoque de 'proceso diferente' sería que una persona puede ejecutar múltiples servidores sin tener que ejecutar múltiples clientes. Esto sería ideal para un host dedicado como la configuración y es un enfoque que comúnmente vemos en los shooters en primera persona.

Ahora, en cuanto a la idea de tener un proceso de servidor o hilo incluso para jugar fuera de línea (y tal vez incluso para un solo jugador), esta es una gran idea que se usa mucho en la práctica. Puedes ver que muchos juegos hacen esto mirando la pantalla de carga, pequeños indicios como 'recibir' lo delatarán. Es lógico hacer esto ya que si vas a hacer un multijugador, la mayoría de las reglas del juego se regirán por el servidor, entonces, ¿por qué no hacer que las gobierne para un solo jugador? Esto reduce el código que tiene que escribir y proporciona una separación más clara entre el cliente y el "juego", lo que mejorará la calidad de su código.

Ahora, ¿qué tal la comunicación entre procesos e hilos? La comunicación de proceso cruzado se puede hacer de muchas maneras, (nombre-) tuberías, memoria compartida, COM, realmente depende de la tecnología que esté utilizando. Sin embargo, si está creando un servidor, es probable que desee utilizar una variante de red utilizando sockets y algo así como TCP, esto es, por supuesto, donde LIDGREN será útil.

Muchas de estas técnicas también son válidas para la comunicación entre hilos. Pero esto depende aún más de las técnicas que esté utilizando. Podrías volver a usar TCP, pero quizás un sistema aún más simple sería eventos y algo de clasificación, aunque esto podría hacer que tu ciclo de juego no sea determinista (2).

Fuentes

1. Diseño e implementación de sistemas operativos (el libro MINIX), tercera edición de Andrew S. Tanenbaum
2. Fije su paso de tiempo por Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/