noticias - Servidor RPC basado en TCP(¿Erlang o algo similar?) Para la comunicación de aplicaciones iOS/Android

mejor app de noticias 2018

Question

Estoy creando aplicaciones móviles nativas tanto en iOS como en Android. Estas aplicaciones requieren actualizaciones "en tiempo real" desde y hacia el servidor, al igual que cualquier otra aplicación basada en red (Facebook, Twitter, juegos sociales como Words with Friends, etc.)

Creo que el uso de HTTP largo de sondeo para esto es un proceso excesivo en el sentido de que un largo sondeo puede ser perjudicial para la vida útil de la batería, especialmente con una gran cantidad de configuración / desmontaje de TCP. Podría tener sentido que las aplicaciones móviles usen sockets TCP persistentes para establecer una conexión con el servidor y enviar comandos de estilo RPC al servidor para toda la comunicación del servicio web. Este curso, por supuesto, requeriría un servidor para manejar la conexión TCP de larga duración y poder hablar con un servicio web una vez que tenga sentido de los datos transmitidos por el canal TCP. Estoy pensando en pasar datos en texto plano usando JSON o XML.

Quizás un servidor RPC basado en Erlang haría bien en una aplicación basada en red como esta. Permitiría que las aplicaciones móviles envíen y reciban datos del servidor a través de una conexión sin la configuración / desmontaje múltiple que las solicitudes HTTP individuales harían usando algo como NSURLConnection en iOS. Dado que ningún navegador web no está involucrado, no necesitamos lidiar con los matices de HTTP en el nivel de cliente móvil. Muchos de estos servidores "COMET" y de sondeo largo / streaming se crean con HTTP en mente. Pienso que el uso de un protocolo de texto sin formato sobre TCP es lo suficientemente bueno, hará que el cliente sea más receptivo, permitirá recibir actualizaciones del servidor y preservará la vida útil de la batería en comparación con los modelos tradicionales de sondeo largo y transmisión.

¿Alguien hace esto actualmente con su aplicación nativa de iOS o Android? ¿Escribiste tu propio servidor o hay algo de código abierto con el que puedo comenzar a trabajar hoy en lugar de reinventar la rueda? ¿Hay alguna razón por la que usar un servicio RPC basado en TCP sea una decisión peor que usar HTTP?

También busqué en la canalización de HTTP, pero no parece que valga la pena cuando se trata de implementarlo en los clientes. Además, no estoy seguro de si permitiría la comunicación bidireccional en el canal de comunicación del servidor <-> del cliente.

Cualquier idea sería muy apreciada.

Answer 1

Erlang es muy adecuado para su caso de uso. Preferiría usar TCP a través de HTTP para salvar la vida útil de la batería en el teléfono, como ya mencionó.

Generalmente, la comunicación entre el dispositivo y el servidor será muy fácil. El protocolo que está utilizando entre los dos es lo que requerirá la mayoría del trabajo. Sin embargo, los protocolos de escritura en Erlang son sorprendentemente sencillos cuando se utiliza gen_fsm

Debería consultar la talk de Metajack en Erlang Factory, que destaca su solución a un estuche de uso muy similar para su juego de iPhone Snack Words .

Answer 2

Hay compilaciones de ZeroMQ para Android y iOS. También existen enlaces de Java y ObjC.

HTTP fue creado para solicitudes infrecuentes con respuestas grandes. Es altamente ineficiente para transferir grandes cantidades de fragmentos de datos pequeños. En una situación típica, los encabezados http pueden tener el doble de tamaño de la carga útil real. El único lado fuerte de HTTP es su habitualidad, su karma de "talla única".

Si desea una solución ligera y rápida, supongo que ZeroMQ puede ser una solución perfecta.

Answer 3

Todo depende de los datos que envíe: el tamaño, la importancia de la puntualidad, la frecuencia de actualización, etc.

Si está buscando una actualización razonablemente perezosa y datos detallados (digamos JSON), vaya con un patrón de cometa HTTP, ya que le resultará mucho más fácil navegar por los equipos de red estándar, como han resaltado otras respuestas. Si está detrás de un servidor de seguridad / proxy corporativo, por ejemplo, http será una apuesta mucho más segura.

Sin embargo, si está haciendo cosas rápidas con tamaños de datos pequeños, vaya con algo propio y aproveche una conexión TCP. Es mucho más preciso y encontrará el rendimiento en términos reales mucho mejor. Estructuras de datos simples y utilice operadores rápidos para dividir sus datos a medida que los necesite.

De nuevo, como han señalado otros carteles, el uso de la batería es una gran preocupación. Comerás una batería literalmente quemando un agujero en tu bolsillo si no tienes cuidado. Es muy fácil convertir una batería que dura 2 días en una que durará 6 horas.

Por último, no confíes en la red si eres sensible al tiempo. Si no lo eres, entonces una larga encuesta a través de HTTP estará bien para ti. Pero si está buscando mensajes de alto rendimiento, tenga en cuenta que una red móvil no es una conexión TCP de extremo a extremo. Sus solicitudes variarán en el tiempo de viaje y la latencia.

Así que vuelve a lo que quieres hacer con la aplicación. A medida que se está construyendo para iOS (nativo obviamente dictado) y Andriod, aprovecharía los servicios Apple Push y su marco de notificación. Cree sus servicios de back-end para hablar con ellos y también proporcione interfaces para dispositivos que no sean de Apple (es decir, escuchas de nivel http o tcp). De esa forma una plataforma y múltiples ''gateways'' para tus aplicaciones. También puede hacer RIM a través de su servicio push si así lo desea.

Answer 4

Trabajo en una aplicación que se conecta a un servidor http de Microsoft con conexiones http / https de larga duración a dispositivos móviles para permitir que se envíen datos de tipo push al móvil. Funciona, pero hay un montón de pequeños gotcha en el lado móvil.

• Para que el cliente obtenga ''paquetes'' de datos, ponemos la conexión http en el modo de codificación de Chucked para que cada paquete esté en un paquete de chucked.

• No todos los servicios de la API http nativa en cada móvil admitirán devolverle la llamada cuando haya llegado un ''chuck'' de datos, en los que normalmente no esperan hasta que todos los datos del servidor hayan llegado antes de volver a llamar a la aplicación con los datos . Las plataformas que admiten devoluciones de llamada con datos parciales son (que he encontrado):

  • Symbian
  • Windows Mobile

• Plataformas que no admiten devoluciones de llamadas de datos parciales:

  • IOS
  • Mora

• Para las plataformas que no son compatibles con devoluciones de llamada parciales, hemos escrito nuestro propio código de conexión http con soporte de codificación chucked utilizando el soporte de calcetín nativo. En realidad no es muy difícil.

• No confíe en el hecho de que un chuck es uno de sus paquetes, los proxies http o las implementaciones nativas de http api pueden romper esa suposición.

• En IOS con estas reglas de multitarea en segundo plano, significa que no puede mantener esta conexión mientras su aplicación está en segundo plano. Realmente necesitas usar el servicio de notificaciones push de Apple y vivir de acuerdo con sus limitaciones.

• Nunca confíe en las redes celulares móviles, he visto las cosas más extrañas que ocurren en el lado del servidor al ver caer la conexión http y luego volver a conectar (y reproducir la solicitud http original) mientras que en el extremo móvil no ve ninguna caída en la conexión . Básicamente, trate la conexión como no confiable donde los datos pueden desaparecer. Terminamos implementando un esquema de número de secuencia tipo ''tcp'' para asegurarnos de que no perdimos datos.

• El uso de http / https hace que sea más fácil pasar las reglas de firewall en los sitios de los clientes.

No estoy seguro de que usar conexiones http / https de larga duración haya sido la decisión más inteligente que hayamos tomado, pero se tomó mucho antes de que apareciera, así que tengo que vivir con las consecuencias.

Como alternativa, también estamos viendo los sockets web, pero con la especificación web-socket en el estado de flujo atm y, en general, no es bueno seguir, no sé si funcionará o no.

Esa es mi experiencia con el uso de http / https como una conexión en tiempo real de larga duración.

Su kilometraje puede variar.

Answer 5

Una razón para utilizar HTTP en lugar de un servicio personalizado es que es ampliamente compatible en el nivel de transporte.

Con los dispositivos móviles, un usuario puede estar conectado a Wi-Fi en un hotel, aeropuerto, cafetería o LAN corporativa. En algunos casos, esto significa tener que conectarse a través de proxy. Los usuarios de su aplicación estarán más contentos si la aplicación puede usar la configuración de proxy del dispositivo para conectarse. Esto proporciona la menor sorpresa: si la navegación web funciona, entonces la aplicación también debería funcionar.

HTTP es lo suficientemente simple como para que no sea difícil escribir un servidor que acepte solicitudes HTTP de un cliente personalizado. Si decide tomar esta ruta, la mejor solución es la que no tiene que admitir. Si puede escribir algo en Erlang que respalde los cambios de aplicación, entonces suena como una solución razonable. Si no se siente cómodo al hacerlo, PHP o J2EE obtienen puntos de bonificación por la disponibilidad de mano de obra barata.

Si bien HTTP se beneficia de ser ampliamente soportado, algunos proyectos exitosos se basan en otros protocolos. Los desarrolladores de Sipdroid descubrieron que las conexiones TCP persistentes mejoran en gran medida la vida útil de la batería. Su article sobre el tema no aborda el lado del servidor, pero sí proporciona una descripción de alto nivel de su enfoque en el cliente.

Answer 6

El uso de sockets TCP con su propio protocolo es bastante mejor que HTTP, especialmente con la naturaleza de los recursos en los dispositivos móviles. Erlang lo hará bastante bien, sin embargo, comencemos desde su protocolo. Erlang sobresale bien en esto especialmente con las expresiones de sintaxis de bits . Sin embargo, aún así, puede utilizar texto plano como desee. JSON (necesitaría un analizador: Mochijson2.erl encontrado en la biblioteca Mochiweb ) y XML (necesitará un analizador: Erlsom ).

Personalmente, he trabajado en un proyecto en el que estábamos usando Sockets TCP sin procesar con nuestros servidores Erlang y dispositivos móviles. Sin embargo, dependiendo de los números de puerto que elija, los enrutadores en el camino bloquearán / eliminarán paquetes dependiendo de las políticas de seguridad de los proveedores de servicios. Sin embargo, sigo pensando que HTTP puede funcionar. La gente chatea en Facebook Mobile, envía Twits, etc. desde sus dispositivos y estoy seguro de que estos motores sociales utilizan algún tipo de sondeo largo o empuje de servidor o lo que sea, pero utilizan HTTP. Los dispositivos móviles han avanzado en capacidad de última hora.

Rodar su propio protocolo basado en TCP conlleva una serie de desafíos: selección de puertos, análisis de datos tanto en el cliente como en el servidor, problemas de seguridad, etc. El uso de HTTP le permitirá pensar en el problema real que pasar el tiempo corrigiendo los problemas del protocolo en el cliente o servidor. Los dispositivos que mencionó anteriormente, como Android y IOS (Ipad, Iphone, etc.) son muy capaces de manejar HTTP COMET (sondeo largo). Estoy seguro de que cuando cumpla con los estándares para aplicaciones web en dispositivos móviles y con estas prácticas recomendadas de W3C Mobile Web , su aplicación funcionará bien usando HTTP.

El uso de métodos HTTP acelerará el trabajo y hay muchas bibliotecas en los SDK de estos dispositivos que le ayudarán a crear un prototipo de la solución que desea en comparación con la situación de rodar su propio protocolo de texto simple basado en TCP. Para respaldar este razonamiento, revise estos hallazgos del W3C .

Permítanme finalmente hablar de los beneficios de HTTP en estos dispositivos. Si va a utilizar tecnologías web para dispositivos móviles, como Opera Widgets , Phone Gap , Sencha Touch y JQuery Mobile , sus SDK y bibliotecas ya han hecho optimizaciones para usted o tienen formas bien documentadas de hacer que su aplicación sea eficiente. Aún más, estas tecnologías tienen las API para acceder a los recursos de los dispositivos nativos, como la verificación de batería, SMS, MMS, canales de transmisión GSM, contactos, iluminación, GPS y memoria; todos como APIs en las clases de JavaScript. Sería difícil (inflexible) si usas lenguajes de programación nativos como J2ME , Mobile Python o Symbian C ++ / Qt en comparación con el uso de tecnologías web como CSS3, HTML5 y las herramientas de JavaScript mencionadas anteriormente. El uso de las herramientas web mencionadas anteriormente hará que su aplicación sea fácilmente distribuible, por ejemplo, Ovi Store o Apple Store , por experiencia.

Tenga en cuenta que si utiliza HTTP, la prueba será fácil. Todo lo que necesita es un dominio público para que los widgets en el dispositivo móvil ubiquen sus servidores a través de Internet. Si desempeña su propio protocolo TCP / IP, los enrutadores de red pueden interrumpir el número de puerto que usa, a menos que piense en usar el puerto 80 u otro puerto conocido, pero aún así, la IP de su servidor deberá hacerse pública. Hay un atajo para esto: si pone su servidor TCP detrás del mismo ISP que la conexión a Internet de su Mobile de prueba, los enrutadores del ISP verán tanto el origen como el destino detrás de su red. Pero, en definitiva, existen desafíos con la implementación de su propio protocolo.

Edición: Usando HTTP, te beneficiarás de REST . Los servidores web implementados en Erlang (especialmente Yaws y Mochiweb ) sobresalen en los servicios REST. Mira este artículo: Servicios RESTOSOS con Yaws . Para mochiweb, hay un artículo interesante sobre: Una aplicación de un millón de usuarios de cometas que usa Mochiweb, que se divide en 3 partes. Aún más, usted podría mirar la solución dada a esta pregunta .