El diseño de un protocolo de red para dispositivos de datos en tiempo real/móvil

Question

me encuentro ante un dilema siguiente:

Diseño de un nuevo protocolo de red que se utiliza entre un servidor (software de Java) y clientes de escritorio y móviles. Los clientes móviles incluyen J2ME, Android y tal vez en el futuro, incluso iPhone.

La secuencia de datos es una transmisión constante en tiempo real con también partes más infrecuentes. Los clientes muestran formas de onda de estos datos y también datos que no necesitan actualizarse instantáneamente. Los clientes también deben ser autenticados.

Me gustaría evitar la creación de una implementación totalmente personalizada del protocolo TCP desde cero si es posible.

En estos días, la gente generalmente recomienda hacer todo en el estilo REST, que también me gusta mucho. Sin embargo, en este caso estoy un poco indeciso: ¿cómo implementarías un flujo de datos constante además de REST? ¿Una respuesta HTTP fragmentada?

También estoy considerando protocolos que no sean de texto plano (los actuales que estoy reemplazando son protocolos binarios). Esos protocolos actuales tienen sus problemas más serios, por lo que deberían ser reemplazados.

Buffers de protocolo de Google se ve como un candidato bastante fuerte para manejar los detalles de bajo nivel, pero no estoy seguro si se puede usar desde Android. Y estoy bastante seguro de que la implementación del iPhone también tendría problemas.

También hay BEEP, pero creo que está prácticamente muerto y me pregunto si alguna vez fue ampliamente utilizado.

¿Alguna idea?

Answer 1

Es posible que desee mirar RTP (Real-time Transport Protocol), que puede no ser directamente útil (y/o podría ser demasiado), pero su diseño le daría algunas buenas ideas para trabajar. Y es muy posible que puedas usarlo.

Answer 2

creo que antes de entrar en el diseño del protocolo que debe hacerse cargo de los siguientes temas con mucho cuidado:

• Casi todos los protocolos excepto HTTP son filtrados por los cortafuegos en estos días. Incluso muchos tipos de contenido y puertos (excepto 80) pueden ser filtrados por los proveedores de servicios, especialmente en servicios de datos móviles. Por lo tanto, asegúrese de no tener problemas de firewall en su red objetivo antes de elegir usar o diseñar un protocolo.
• El tamaño y la velocidad son importantes. Trate de usar protocolos eficientes tanto en el tamaño del mensaje de transporte como en la velocidad de codificación/descodificación (serialización/deserialización). Google Protocol Buffers proporciona una solución confiable a este problema.
• Las conexiones siempre se desconectan. Nunca puede confiar en que una conexión permanezca abierta por mucho tiempo debido a los tiempos de espera de NAT (15 minutos por defecto), los tiempos de espera de protocolo (30 minutos para TCP) y muchos problemas de red existentes. Por lo tanto, no prefiera un protocolo sobre el otro solo porque mantiene la conexión abierta (puede intentarlo, pero nunca tiene éxito). Enviar latidos es una buena prueba para el problema del tiempo de espera, pero las desconexiones de red siguen siendo inevitables.
• El rendimiento importa. Por rendimiento, me refiero a la cantidad de mensajes procesados ​​en un período de tiempo (por ejemplo, 1 segundo). El uso de protocolos asíncronos que desconectan a un cliente después de recibir su mensaje, realmente ayuda a aumentar el rendimiento.Aunque no confíes en conectarte al cliente desde el servidor para impulsar el resultado porque muchos clientes están detrás de NAT y cortafuegos que evitan la conexión directa desde el exterior. Intente mantener la conexión abierta o sondear el servidor para obtener el resultado. Evitar el estado en una conversación es también el otro método que ayuda a escalar el rendimiento de la aplicación a medida que crece la cantidad de clientes.
• No hay en tiempo real en las WAN existentes. No confíe en los que dicen que han implementado un protocolo en tiempo real basado en los protocolos de red de área amplia existentes. Nunca puede implementar un protocolo en tiempo real además de los que no son en tiempo real. Puedes hacer lo mejor que puedas y rezar para que la red funcione rápido. Eso significa: no te detengas, haz tu mejor esfuerzo.
• IO sin bloqueo. NIO (IO sin bloqueo) es la tendencia actual, que se usa de manera efectiva en la programación de redes. Permite una gran cantidad de conexiones con menos uso de memoria y un número limitado de subprocesos. Java 5 tiene soporte nativo para NIO, que es muy primitivo. Se han implementado muchos marcos, como Apache MINA y Netty, basados ​​en Java NIO para facilitar y robustecer la programación no bloqueante. Los recomiendo encarecidamente

Answer 3

lo podría hacer en Kryo y/o KryoNet, que son NIO y Java basada en el escritorio y trabajar y Android. Sin embargo, tendrías que escribir el lado del iPhone, lo que sería bastante complicado. Kryo supera a los búferes de protocolo de Google en tamaño serializado (benchmarks here) y su facilidad de uso (no es necesario escribir un esquema tipo .proto, con Kryo las definiciones de clase Java son el esquema).

En cuanto a NIO, puede consultar NPTL. Lo viejo se vuelve nuevo de nuevo.

Answer 4

No es una solución elegante, pero puede hacerlo en http recta, no configurando el campo de longitud de contenido en la respuesta http y nunca cerrando la secuencia de salida. Solo sigue enviando datos.

También puede establecer una longitud de contenido muy grande y enviar datos desde el servidor en tiempo real hasta que el servidor haya enviado esa cantidad, luego el cliente puede optar por hacer una nueva solicitud o no.

Lamentablemente no encontré ningún enlace útil para estas ideas, pero confío en que obtenga las ideas.

El lado positivo de estas ideas es que están por encima de http, lo que pasa por el problema del firewall, y puede implementar su aplicación como una aplicación web con un servlet.

Sólo mis 2 centavos;)