Interconectar una flota de vehiculos

[Sopanda]

Hola,

Resulta que estoy realizando una aplicación que debe interconectar vehículos con sus talleres para saber su posición GPS, y poder enviarles información.

Podrían ser hasta 600 talleres y cada taller podría tener 6 vehículos más o menos... eso hace 3600 vehículos... si hago que transmitan información de su localización cada minuto a un servidor... y del servidor los talleres acceden para saber como está su flota... más o menos haciendo cálculos me salen 5millones de conexiones en un día (solo por parte de los vehículos diciendo donde están) con el servidor. No sé cuanto puede soportar un servidor dedicado.. pero me parecen muchas conexiones, y no sé que equipo tendría que tener para soportar eso.

Otra opción que había pensado, es que cada taller se conectara directamente con sus vehículos, y mediante una conexión TCP que se transmitieran información, pero primero no estoy seguro si se podría porque para WinXP creo que el límite son 10 conexiones TCP a la vez, y después no sé si por los puertos me darían muchos problemas...

A alguien se le ocurre alguna forma de hacerlo?. Para liberar de trabajo al servidor la mejor forma sería la segunda idea, pero tengo que seguir dándole vueltas porque no lo veo aún claro y tengo que hacer pruebas para ver si funcionaría al menos a pequeña escala.

[mocelet]

Estas cosas se ven mejor en conexiones por segundo. 3600 vehículos -> 3600 peticiones por minuto -> 60 peticiones por segundo (estadísticamente estarán espaciadas en el tiempo, no vas a encontrarte con 3600 peticiones de golpe ni estarán todos en movimiento siempre). Eso no es nada para un servidor dedicado, incluso un VPS podría con ello.

Sobre el ancho de banda, si evitas HTTP y optas por un protocolo más ligero, con unos bytes por petición va más que sobrado, pero ponle 1 KB -> 60 KB/s = 480 kbps. Eso tampoco es nada para un servicio de alojamiento. Tráfico mensual: 1 KB * 3600 * 60 * 24 (y es pasarse) * 30 = 155 GB mensuales.

La forma elegante de diseñarlo, conservando principios de escalabilidad y demás, sería tener un conjunto de servidores que atiendan los envíos de coordenadas de los coches, un conjunto de servidores que generen los informes para los talleres (frontend) y todos ellos conectados a una base de datos maestra (backend).

En plan "prototipo rápido" y dada la carga que va a tener, con un servidor va apañado. Y si no quieres conservar el historial de posiciones de los coches, la base de datos también sobra porque cabe en una hash en memoria del servidor. El servidor te saldría por unos 30-40 euros al mes.

[Sopanda]

Gracias por la contestación,

Lo pensaba hacer primero con servidores, pero no tenía muy claro lo que podían soportar y busqué otras opciones. Cómo podría calcular las peticiones por minuto que podría soportar un servidor?.

Y en cuanto al envío de la información, utilizar un webservice REST sería buena opción?.

Saludos,

[mocelet]

La única forma fiable es hacer pruebas de carga (con un generador automático de peticiones externo) y monitorizar los recursos (memoria, uso del procesador y acceso a disco) y el tiempo de respuesta del servidor. Así sabes si para aumentar la capacidad necesitas más RAM, mas velocidad o qué.

Pero en casa de herrero cuchillo de palo, todavía no me he puesto a medir la carga máxima del nuevo online para mis juegos xD

Un servicio REST es http, te facilita la vida, pero es lo menos eficiente. Para un juego no lo usaría ni loco, pero para enviar posiciones y ya te ahorras usar sockets y es fácil hacer clientes, incluso en HTML con javascript.

Enviado desde mi HTC Desire usando Tapatalk 2

[Sopanda]

Entonces mejor intento utilizar sockets para que no se me sature mucho, no?

[mocelet]

No todo es eficiencia. Cada opción tiene sus ventajas e inconvenientes. Lo de saturar no tiene que preocuparte, en tu aplicación es muy fácil escalar porque las flotas son pequeñas e independientes de las demás. Lo que tiene que preocuparte es que la app sea segura, fácil de desarrollar y mantener.

HTTP es universal, tiene sus mecanismos de autenticación estándar, es "tráfico amistoso" para los cortafuegos y proxies, y para enviar información no hay problema (si tuvieras que recibir, como es el caso de los juegos, ya es más problemático). Que haya unas cuantas cabeceras más no es problema hoy día (y si no mira XML, sacrifica eficiencia de espacio y procesamiento por sencillez, y el espacio con gzip tampoco es problema).

Meterte en un desarrollo propio que use sockets por ahorrarte bytes transmitidos no merece la pena, y menos ahora que estás empezando.

[pmaicas]

Yo tengo algo parecido: http://www.mancuentro.com/

:grin: