google-app-engine - pricing - google cloud app engine prices

¿Juego en tiempo real en Google Cloud: Channel API o Compute Engine?

Question

Necesitamos desarrollar un juego multijugador con rendimiento en tiempo real. Esto debe funcionar en todo el mundo (servidores en Estados Unidos, Europa, Asia) y admitir un gran tráfico. Utilizando los servicios de Google Cloud para el hosting.

Estamos pensando en referencias como Jam with Chrome, Chrome Maze o Cube Slam.

El juego :

• 2 jugadores desafían una carrera
• Necesitamos mostrar simultáneamente la progresión de los 2 jugadores.
• Cada partido puede durar entre 30 y 45 segundos.

El alojamiento:

Obviamente, alojaremos el sitio web en AppEngine, que se escala automáticamente, pero estamos pensando en 2 soluciones para los servidores en tiempo real:

1. Uso de servidores websocket con Compute Engine
   
   Como hicieron para Jam con Chrome, Maze, etc.
   Desarrollando nuestros propios servidores websocket (tecnología TBD), implementándolos en centros de datos en Europa, EE. UU., Asia, manejando escalas, sincronizando entre ellos, calculando problemas de latencia en servidores y clientes, etc.
   Pero es bastante desafiante desde el punto de vista técnico, ya que tenemos muy poco tiempo y, por ahora, faltan un administrador de sistemas y un tipo de red.

2. O usando API del canal
   
   Entendemos que no es una plataforma websocket, y que el rendimiento en tiempo real es menor.
   Pero sería mucho más simple y seguro para nosotros y el tiempo que tenemos.
   Por lo tanto, también nos gustaría saber más sobre eso.

En cualquier caso, creemos que podríamos usar algunos trucos gráficos en los frontales, para que parezcan en tiempo real, pero realmente depende de si tenemos una latencia de 100 ~ 500ms o 500ms ~ 10s.

Algunas preguntas :

• ¿Cómo se verían los valores del rango de latencia para las diferentes soluciones?
  (Jamón con Chrome obtuvo 100 ms con GCE, ¿podría la API del canal llegar a varios segundos?)
• ¿Cómo manejarían los servidores API de canal el alto tráfico, cómo funciona el escalado, la latencia podría ser muy alta? (¿No hay información sobre eso en la documentación de Channel?)
• ¿Qué pasa si alguien en Francia juega con alguien en EE. UU., Se conecta a diferentes servidores, espera que se sincronicen, cómo lidiar con eso?
• ¿Algún consejo o experiencia para compartir?
• ¿Alguna lectura o lectura interesante? (visto algunos pero no muy precisos)
• ¿Alguna otra solución?

Gracias por cualquier comentario de ayuda!

EDITAR :

• Solo 2 jugadores conectados entre sí, potencialmente desde diferentes zonas del mundo, no se necesita transmisión.
• Podríamos encontrar algunos trucos del lado frontal para evitar el procesamiento del lado del servidor. Esta es una carrera entre 2 jugadores, por lo que en realidad solo necesitamos comparar su progresión, y la resolución del ganador real no es tan importante ya que no hay cosas reales que ganar, esto es más por diversión

Answer 1

La respuesta de Alfred es la mejor en el marco de la pregunta que hice. Muchas gracias !

Sin embargo, olvidé mencionar algunos puntos importantes y el alcance cambió un poco:

• Tenemos muy poco tiempo de desarrollo (alrededor de 1 semana solamente)
• Esto es para una campaña que solo durará 3 semanas (tendremos que mantenerla en línea unos meses después, pero no es como que necesitamos una arquitectura duradera)
• Necesitamos que funcione en la mayor audiencia de navegadores posible (por ahora, WebRTC solo se ejecuta en Chrome y Firefox)

De acuerdo con estos puntos, finalmente llegamos a una tercera solución:
Utilizando un PAAS en tiempo real .

Es mucho más fácil y rápido de desarrollar, mucho más económico, ya que no necesitamos un sólido desarrollador de back-end ni un administrador de sistema / red, y podemos concentrarnos más en el proyecto que en la infraestructura y la plataforma.

Hay un par de servicios que parecen buenos por ahí, ya que albergan MMO RPG y el tipo, a nivel mundial, con baja latencia y buenos sistemas de escalado.
Aquí hay una lista de proveedores:
https://github.com/leggetter/realtime-web-technologies-guide/blob/master/guide.md

Answer 2

También depende de otras cosas como la escalabilidad.

Ingress se basa en el motor de la aplicación y una parte de la falla de la memoria caché ocasional es bastante impresionante.

Recuerda que la api del canal usa talk.Google, que es el servicio en el que se basan los hangouts. Escalable y en tiempo real.

Personalmente, si sus niveles de tráfico van a ser erráticos e impredecibles, vaya al motor de aplicaciones. Si cree que puede ser controlado y predecible, utilice el motor de cálculo o alguna otra cosa.

Answer 3

Si necesita un servidor para procesar los datos:

Definitivamente iría con websockets en Compute Engine!

La API de canales es mucho más lenta y también bastante impredecible (la latencia difiere de un mensaje a otro). Los datos deben ir al servidor de canales, que los envía a la instancia de App Engine, que tiene que hacer una solicitud al servidor de canales, que enviará el mensaje al cliente. ¡Hay mucho que hacer allí si quieres mantener la latencia baja!

Aquí hay una prueba de estrés de API de canales:
http://channelapistresstest.appspot.com/
Intente hacer clic en el botón "enviar 5" y verá que los números de latencia aumentan a varios segundos.

La API de canales también es bastante costosa bajo una carga pesada (probablemente no se escala bien, incluso si Google, por supuesto, puede resolver eso con más instancias).

Cuando se mantiene la latencia baja, la geolocalización es bastante importante. Con un servidor websocket en Compute Engine, puede enviar a sus visitantes europeos al centro de datos europeo de google y a sus visitantes estadounidenses al centro de datos de EE. UU. (Utilizando los encabezados de ubicación geográfica que proporcionará AppEngine). No tiene dicho control con la API de canales (o el motor de la aplicación, a través del cual se transmiten todos sus mensajes). Tal vez Google tenga servidores de borde para la API de canales (no lo sé), pero si su instancia de AppEngine está en el otro lado del planeta, eso no importa.

Si NO necesita un servidor para procesar los datos:

Debes establecer una conexión de igual a igual con WebRTC, enviando cosas directamente entre los navegadores de los usuarios. Eso es lo que hace Cube Slam. (WebRTC requiere un intercambio de manos inicial ("señalización") para que los dos pares puedan encontrarse, y la API de canales funcionaría bien para ese intercambio de manos, eso es solo un par de mensajes para establecer la conexión de igual a igual).

WebRTC DataChannels API le proporcionará una buena interfaz similar a un channel.onmessage = function(e) { yadayada()... }; como channel.onmessage = function(e) { yadayada()... }; y channel.send("yadayada"); para enviar sus datos entre los pares.

Ocasionalmente, WebRTC no puede hacer una conexión de igual a igual. Luego, recurrirá a un servidor TURN, que transmite el tráfico entre los pares. Cube Slam utiliza los servidores TURN que se ejecutan en ComputeEngine (tanto en Europa como en Estados Unidos para mantener la latencia baja), pero eso es solo el problema cuando no es posible un verdadero intercambio entre iguales.