.NET Game Server

Question

Tengo una pregunta aquí sobre la tecnología .Net framework y el servidor de juegos. supuestamente, tengo algunas máquinas de juego actuando como cliente y quiero conectar esas máquinas cliente a un servidor de juegos, ¿ustedes creen que es bueno si desarrollo la aplicación de servidor usando .NET Framework?

la máquina cliente también está desarrollada en tecnología dotnet. ¿Qué ocurre si amplío mi servidor a unos pocos servidores que se ejecutan simultáneamente? ¿Sería posible si utilizo .Net Framework en mi servidor de juegos? ¿Qué tecnología .Net debería usar, .Net Remoting, servicios web XML, COM +, MSMQ o cualquier sugerencia?

un factor más importante aquí es el rendimiento en cuanto a rendimiento. Quiero que la comunicación entre el cliente y el servidor se comunique de manera rápida y eficiente sin largos tiempos de retraso.

El propósito que quiero expandir a algunos servidores es porque si uno de los servidores falla o se apaga para dar servicio, aún puedo tener mi aplicación ejecutándose sin interrumpir el proceso del juego que es crítico y en tiempo real.

¿Hay algún alma amable que haya hecho tal configuración anteriormente? si es así, ¿qué piensan ustedes sobre eso? lo mejor, lo bueno, lo peor o lo peor para emplear .Net en el servidor del juego?

Agradezco sinceramente a todo el experto en desarrollo de .Net y juegos para que me brinde sus comentarios aquí.

gracias,

Answer 1

Para que cualquier tipo de escalabilidad para un servidor de juegos, es necesario utilizar UDP para la comunicación (que es compatible con .NET, consulte UdpClient).

Este artículo le podría apuntar en la dirección correcta: Multi-Threaded Game Server Browser

Answer 2

No creo que tengo el tipo de conocimiento del dominio necesario para responder a esto, pero quiero darle una oportunidad de todos modos, y tal vez voy a hacer algunas preguntas que ayudan a desentrañar el la respuesta correcta para ti.

¿Es .Net el camino a seguir? No lo sé. Comunicándose con DirectX? - Pase, lo siento.

¿Están los clientes y el servidor en la misma LAN? ¿Se están conectando a través de la web? Para un rendimiento puro, necesitaré un ssume .Net Remoting. Para las comunicaciones en general, es posible que desee considerar el WCF, ya que puede cambiar la forma en que se comunica por un cambio en la configuración (cola de servicios web, por ejemplo). Habiendo dicho eso, para sacar el máximo provecho de algo como hacer cola, es posible que deba tener cuidado con la forma en que realmente diseña los puntos finales.

¿Hablas de ampliar el servidor? Supongo que querrás golpear algún tipo de equilibrador de carga, con múltiples nodos debajo de eso. Esto podría ser útil: http://www.codeproject.com/KB/IP/remotingdesigndecisions.aspx

Answer 3

No estoy seguro de que un enfoque estándar .Net va a ser la forma en que quiere ir ...

Cada .Net La tecnología que menciona tiene una configuración mensurable y un costo de desmontaje asociado, y WCF es una de las peores. Si su objetivo es el rendimiento, debe hablar directamente con los puertos en lugar de usar un contenedor estandarizado para manejarlos. Incluso diría que si el rendimiento es realmente clave, debe estar buscando una función C directa en lugar de un lenguaje .Net.(Algunos ciertamente estarán en desacuerdo conmigo, pero he encontrado que los lenguajes dinámicos como Ruby y Python también son bastante rápidos)

La otra pregunta que entrará en juego es tu back-end de datos. Si todo está en la memoria, ejecutar varios servidores significa que tendrás que utilizar algún tipo de mecanismo de almacenamiento en caché, como memcached, para mantener sincronizados todos tus datos. Si vas a utilizar una base de datos, te sugiero que uses varios puertos, uno que está conectado a tu base de datos y otro que está estrictamente basado en la memoria. La ventaja que obtiene es que los datos que no requieren bases de datos se pueden ejecutar en un espacio de memoria que se ejecuta tan rápido como se ejecutará la computadora y el proceso no tiene que esperar en costosas conexiones de bases de datos.

WCF/.Net Remoting/COM +/etc son excelentes para aplicaciones de línea de negocio donde un cambio de 1 segundo no te matará, pero en un entorno en tiempo real donde cada milisegundo cuenta necesitas ser capaz de administrar toda la pila de comunicación desde el momento en que recibe el primer paquete hasta que cierra la conexión. Cada pila de comunicación .Net que he usado en entornos en tiempo real ha agregado casi 100ms a cada solicitud. Al eliminar al intermediario y tratar directamente con el cliente (es decir, leer la transmisión directamente desde el puerto y luego enviar la transmisión directamente al puerto) reduje ese costo y recupero ese tiempo. Cuando maneja decenas de miles de solicitudes por minuto, ese tiempo se vuelve muy importante.