COMET (servidor de inserción al cliente) en el iPhone

Question

Estoy buscando establecer algún tipo de funcionalidad de tipo socket/COMET desde mi (s) servidor (es) a mi aplicación de iPhone. Esencialmente, cada vez que un usuario logra establecer un objeto arbitrario 'sucio' en el servidor, por ejemplo, actualizando su Dirección ... los comentarios deben ser enviados desde el servidor a cualquier cliente que mantenga una encuesta en vivo al servidor. La palabra de moda para esto es COMET, supongo. Sé que existe DWR para aplicaciones de navegador web, así que estoy pensando, quizás sea mejor configurar un UIWebView oculto en cada uno de mis controladores solo para que pueda salir de la caja COMET desde su marco de JavaScript. ¿Hay un enfoque más elegante?

Answer 1

Hay un par de soluciones disponibles para usar un cliente STOMP.

STOMP es increíblemente simple y ligero, perfecto para el iPhone.

Utilicé this one como mi punto de partida, y me pareció muy bueno. Tiene algunos problemas de asignación de objetos/fuga de memoria, pero una vez que me acostumbré a la programación del iPhone, estos fueron fáciles de solucionar.

Espero que ayude!

Answer 2

Escribí web server para hacer exactamente este tipo de cosas. Estoy presionando las actualizaciones en tiempo real a través del servidor con una encuesta larga y, como ejemplo, tuve safari on the iPhone mostrando esos datos.

Una instancia determinada del servidor debería poder manejar unos pocos miles de clientes simultáneos sin esforzarse demasiado. Tengo un plan para ponerlos en una jerarquía que permita una escala más horizontal (debería ser bastante trivial, pero no afecta mi aplicación actual).

Answer 3

¿El trabajo de larga duración funcionaría para lo que usted desea lograr? Puede implementar el lado del cliente en unas pocas líneas de Javascript regular, que será más ligero de lo que podría ser cualquier marco.

También sería trivial para implementarlo en ObjC (conectar, esperar una respuesta o tiempo de espera, repetición)

Las respuestas a mi pregunta Simple "Long Polling" example code? espero explicar cómo extremadamente simple sondeo largo es ..

Básicamente, solo solicitaría una URL como siempre: el servidor web aceptaría la conexión, pero no enviaría datos hasta que esté disponible. Cuando recibe datos, o la conexión expira, se vuelve a conectar (y repite)

El bit más complicado sería el servidor en el lado del servidor, ya que no puede usar un servidor web normal como Apache, aunque esto también es el caso con Comet ...

Answer 4

¿Desea/tiene la comunicación para su aplicación a través de http? De lo contrario, puede usar el marco CFNetwork para usar sockets (TCP/UDP) para permitir que su aplicación y servidor se comuniquen. Por lo que he visto de la pila de CFNetwork, es bastante genial, y hace que sea bastante sencillo leer y escribir en transmisiones, y permite la comunicación sincrónica y asincrónica. También le permite definir devoluciones de llamadas en su socket, lo que le permite recibir notificaciones de eventos como datos recibidos, conexiones realizadas, etc. Por lo tanto, en su ejemplo, podría enviar la información a su servidor a través del socket, y luego podría definir un devolución de llamada que escucharía los datos entrantes en la transmisión y luego actualiza su aplicación en consecuencia.

EDITAR: Investigué un poco más, y si sigue el enfoque de socket, es posible que también desee ver las clases de NSStream. Son abstracciones de Cocoa construidas sobre las cosas de CFSocket.

Answer 5

¿Se puede utilizar un zócalo TCP/IP normal en su aplicación?

A) En caso afirmativo, definitivamente un zócalo TCP/IP sin procesar es una solución más elegante. Desde su aplicación de iPhone solo espera los eventos de notificación. El socket está abierto mientras tu aplicación esté abierta. Si lo desea, puede incluso usar protocolos/encabezados HTTP.

En el lado del servidor, puede usar algunos frameworks para escribir servidores que manejan de manera eficiente miles de conexiones TCP/IP abiertas. por ejemplo, Twisted, EventMachine o libevent. A continuación, conecte el zócalo principal del servidor al puerto http (80).

La idea es utilizar un servidor que mantenga una sola estructura de datos por cliente. Recibe el evento de actualización de alguna aplicación DB y luego lo envía al cliente correcto.

B) No, debe utilizar Apache y el cliente http en el lado del iPhone. Entonces, debe saber que la solución COMET entera es, en realidad, una solución para las limitaciones del protocolo HTTP y Apache/PHP.

Apache fue diseñado para manejar muchas conexiones de corta duración. Hasta ahora solo conozco las versiones más nuevas de Apache (trabajador de mpm) que pueden manejar eficientemente una gran cantidad de conexiones abiertas. Anteriormente, Apache mantenía un proceso por conexión.

Los navegadores web tienen un límite de conexiones abiertas concurrentes a un servidor web (de hecho, la dirección URL, por ejemplo, www.foo.com, no la dirección IP de www.foo.com). Y el límite son 2 conexiones. Además, un navegador solo permitirá conexiones AJAX al mismo servidor desde el que se descargó la página HTML principal.

Answer 6

no mencionó qué tecnología de servidor está utilizando. Pero en caso de que sea microsoft .net (o de cualquier otro googlers que se encuentre con esto), existe una opción simple para el cometa: http://www.codeplex.com/ncomet.

Answer 7

COMET, LightStreamer, AJAX toda esa basura está rota. Los conceptos básicos de TCP son que no se garantizan las 'keep-alives' sin hacer ping al tráfico. Por lo tanto, puede olvidarse de ese largo sondeo si se garantiza una fiabilidad decente o una entrega oportuna.

a través de vuelta en 2003, cuando la cojo-manía comenzó ..

Answer 8

WebSync tiene un cliente javascript que funciona en el iPhone, si eso es lo que está buscando

Answer 9

StreamHub Comet Server obras con el iPhone fuera de la caja, sin complementos o cualquier cosa requerida. Acabo de navegar a su sitio web en mi iPhone y todos los ejemplos funcionaron, no fue necesario instalar Flash ni nada.