Aplicación cliente servidor dudas

[Demix]

Hola comunidad!

Ante todo gracias!

Estoy armando un pequeño juego en c++ y llego la hora de arrancar a armar el multijugador.

Mi intención es armar un servidor.

En lo que es el lenguaje en si me manejo bastante bien, mi problema es que se muy poco acerca de Sockets y de Concurrencia, aquí vamos:

1) Apunto a que el servidor pueda mantener alrededor de 300 personas. ¿Es posible armar algo desde sockets en c++ capaz de procesar 300 usuarios conectados sin problemas?. Es decir, es factible o para ese tipo de cosas se requieren librerías especiales.

2) Es mejor utilizar sockets sincrónicos y armar un thread por cada uno o utilizar sockets asincronicos y procesar cada X milisegundos todo lo que llego en cada uno (por lo que tengo entendido el socket sincronico se cuelga y espera a que llegue toda la información y el asincronico devuelve solo lo que recibió hasta el momento)

3) Que libro de concurrencia (para no hacer quilombo con los thread) recomiendan?

Finalmente quiero aclarar que esto lo hago en un 100% porque quiero aprender a usar bien recurrencia y sockets, por eso me decidí por el juego ya que es mas motivador y algo que me gusta, esto lo aclaro porque de seguro pueda existir alguna librería que me solucione mucha parte del laburo, pero mi idea es aprender.

De ser imposible acepto sugerencias.

Gracias, Demian

[eferion]

Iniciado por Demix

1) Apunto a que el servidor pueda mantener alrededor de 300 personas. ¿Es posible armar algo desde sockets en c++ capaz de procesar 300 usuarios conectados sin problemas?. Es decir, es factible o para ese tipo de cosas se requieren librerías especiales.

Depende de varios factores:

1. Capacidad del servidor: Cuanto más potente sea el servidor, más usuarios admitirá
2. Carga del servidor: Un usuario, por el simple hecho de estar conectado al servidor, añade una carga de trabajo al mismo. Cuanto más alta sea esta carga menos usuarios va a admitir tu servidor antes de saturarse.
3. Lag: Dependiendo de la velocidad del juego, el tiempo de respuesta del servidor puede ser más o menos crítico... juegos con un tiempo de respuesta muy corto van a admitir menos jugadores.

Iniciado por Demix

2) Es mejor utilizar sockets sincrónicos y armar un thread por cada uno o utilizar sockets asincronicos y procesar cada X milisegundos todo lo que llego en cada uno (por lo que tengo entendido el socket sincronico se cuelga y espera a que llegue toda la información y el asincronico devuelve solo lo que recibió hasta el momento)

Básicamente hay dos tipos de sockets:

• TCP: En este tipo de socket toda la negociación corre por cuenta del equipo. Los mensajes no sólo no se pierden sino que además llegan ordenados y la conexión permanece abierta todo el tiempo.
• UDP: Este socket posee una negociación mínima. La entrega de los mensajes no está garantizada, los mensajes pueden llegar desordenados y no existe el concepto de "conexión".

TCP ofrece un montón de garantías a costa del rendimiento. UDP, en cambio, te ofrece toda la libertad y velocidad disponible a cambio de tener que lidiar tú con la gestión de los paquetes.

Como ves, cada sistema tiene sus ventajas y sus inconvenientes, aunque yo creo que la mejor opción es usar UDP.

En cuanto a cómo procesar los paquetes... es algo que depende de la arquitectura que vayas a montar. Lo suyo sería ir procesando las cosas según llegan, de esa forma no limitas la velocidad de conexión (no te sirve de nada tener una conexión de 20Mb si la tasa máxima de tu servidor no alcanza los 2Mb por los delays que impones)

Iniciado por Demix

3) Que libro de concurrencia (para no hacer quilombo con los thread) recomiendan?

Ahora mismo no se me ocurre ninguno... además no estoy en casa para consultar la biblioteca. Seguro que alguien acaba aportando algo en este apartado.

Un saludo.

[Demix]

Hola, antes que todo gracias por responder.

El tema del poder del servidor lo veree a su tiempo (ya de por si no se si alguien lo va a jugar jajaja), mi intención es tratar de hacerlo lo mas eficiente posible.

Con el tema udp, como aseguras el orden de los paquetes??, enviando bits adicionales de control o algo asi?.

Luego, al procesar los sockets de 5 usuarios, es mejor armar un thread por cada uno o conviene meter todo en un thread y leer todos, ejecutar acciones, leer todos, ejecutar acciones.

Gracias

[eferion]

Iniciado por Demix

El tema del poder del servidor lo veree a su tiempo (ya de por si no se si alguien lo va a jugar jajaja), mi intención es tratar de hacerlo lo mas eficiente posible.

Yo no pondría especial incapié en el rendimiento antes de tener el servidor operativo. ¿por qué? pues porque el rendimiento es relativo:

• más velocidad suele llevar aparejado un mayor consumo de memoria y la memoria disponible suele ser una limitación importante
• Una mejora de rendimiento en un aspecto suele suponer un peor rendimiento en otros aspectos
• Muchas veces no es necesario aplicar mejoras
• Cuanto mayor nivel de optimización más complejo se vuelve el código

Es decir, hasta que no tengas un servidor operativo y hagas pruebas evaluando su uso previsto no vas a ser capaz de identificar las posibles mejoras que pueda necesitar.

Iniciado por Demix

Con el tema udp, como aseguras el orden de los paquetes??, enviando bits adicionales de control o algo asi?.

Efectivamente. UDP no verifica absolutamente nada, por eso es bastante más rápido que TCP. Es tu responsabilidad incluir los mecanismos de control pertinentes para que la comunicación funcione correctamente.

Iniciado por Demix

Luego, al procesar los sockets de 5 usuarios, es mejor armar un thread por cada uno o conviene meter todo en un thread y leer todos, ejecutar acciones, leer todos, ejecutar acciones.

Nuevamente, depende... para 5 usuarios puede que no notes la diferencia... pero imagina 50 usuarios... ¿vás a crear un hilo para cada uno? ten en cuenta que el entorno multihilo también lleva aparejado un consumo de recursos... si creas muchos hilos y todos tienen que competir por los recursos del procesador entonces vas a perder un montón de tiempo precisamente en resolver esos conflictos. Lo mismo resulta más conveniente crear un hilo por cada núcleo del procesador y que cada hilo se encargue de un cupo de usuarios... o que el primer hilo disponible se encargue de la siguiente petición pendiente... o... posibilidades existen todas las que quieras.

Pero lo más importante, como ya te he dicho, hasta que no tengas un servidor operativo no vas a ser consciente de las mejoras que vas a necesitar aplicar.

Un saludo