Redes de Objective-C: ¿mejores prácticas?

Question

Estoy construyendo una aplicación Objective-C que tiene tanto un servidor como un cliente. El cliente puede enviar actualizaciones al servidor y el servidor debe poder enviar actualizaciones a cada cliente conectado. He estado pensando en la mejor manera de implementar este sistema, pero estoy pidiendo sus sugerencias.

Actualmente, estoy pensando que cuando haya nuevas actualizaciones disponibles, el servidor usará hilos para enviar la actualización a cada cliente. Si un cliente agota el tiempo de espera, se desconectan. Tengo muy poca experiencia en redes, así que le pido su opinión.

¿Crees que este sistema funcionaría bien? Si es así, ¿tiene alguna sugerencia acerca de cómo hacer el enhebrado? ¿Alguna clase de NS a la que me puedas dirigir? Tiene que haber algún tipo de cola que pueda usar, estoy pensando.

¿Alguna otra idea?

EDITAR: No espero que el cliente cuente mucho más de 50, al máximo.

Answer 1

Siempre que tanto el cliente como el servidor sean aplicaciones OS X y que ambos puedan escribirse en Objective-C usando los marcos Cocoa, le recomendaría que consulte la tecnología Distributed Objects (DO) en Cocoa. No trataré de dar un tutorial en Objetos distribuidos aquí, simplemente explique por qué podría ser útil ...

DO maneja los detalles de la red asíncrona para usted (todas las actualizaciones de sus clientes pueden ocurrir en un solo hilo). Además, la semántica de la comunicación con un objeto remoto (de cliente a servidor o viceversa; DO es bidireccional una vez que se establece la conexión) es muy similar a la comunicación en proceso. En otras palabras, una vez que tiene una referencia al objeto remoto (realmente un NSDistantObject que actúa como un proxy para el objeto en el otro extremo de la conexión), su código de cliente puede enviar mensajes al objeto remoto como si fuera local:

[remoteServer update:client]; 

del cliente o

[[remoteClientList objectAtIndex:i] update:server]; 

desde el servidor. Dejaré los detalles de configurar la conexión y obtener la referencia de RemoteServer o remoteClient después de leer el Distributed Objects programming guide.

La desventaja de utilizar DO es que está vinculado a Cocoa; será muy difícil de escribir un cliente o servidor que no sea Cocoa y que se comunique usando Objetos Distirbutados. Si existe la posibilidad de que desee tener implementaciones de servidor o cliente que no sean de Cocoa, no debe utilizar DO. En este caso, recomendaría algo simple con una gran cantidad de soporte de lenguaje e interplataforma. Una API REST-style over HTTP es una buena opción. Eche un vistazo a la documentación de Cocoa URL Loading System para obtener información sobre cómo implementar solicitudes y respuestas HTTP. Eche un vistazo al código de ejemplo CocoaHTTPServer de Apple o un proyecto code.google.com del same name para obtener información sobre la implementación de un servidor HTTP en su código Cocoa.

Como última opción, puede echar un vistazo a la Cocoa Stream Programming Guide si desea implementar su propio protocolo de red. Las subclases de NSStream le permitirán escuchar en un socket de red y manejar lecturas/escrituras asincrónicas a/desde ese socket. Mucha gente usa AsyncSocket para este propósito.Envuelve el (menor nivel) CFStream y CFSocket y hace que escribir código de red sea algo más fácil.

Answer 2

Cuando el servidor envía actualizaciones a los clientes, probablemente sería más fácil tener un solo subproceso manejándolos a todos, y solo usar los sockets asincrónicos. Por supuesto, esto dependerá de cuántos clientes tengas que lidiar también.

Answer 3

No sé cómo planea diseñar su sistema, pero generalmente un servidor no se puede conectar a un cliente; el cliente debe iniciar la comunicación. Con un límite mínimo de 50 clientes, es posible que no se busca en una aplicación Web-servidor/cliente-como ...

Dicho esto, hay básicamente dos maneras de manejar la comunicación cliente-servidor: 1. Las encuestas de clientes el servidor periódicamente para obtener actualizaciones 2. El cliente mantiene una conexión abierta al servidor y el servidor responde con un protocolo bien conocido (como en ambos lados lo entiende).

Answer 4

Hay varios ejemplos de redes en el lado del desarrollador de Apple. Uno que le recomendaría que revise es el URLCache, que se puede descargar. Citando de la documentación de Apple para este ejemplo:

Urlcache es una aplicación de iPhone de ejemplo que muestra cómo descargar un recurso fuera de la web, almacenarla en el directorio de datos de la aplicación, y utilizar la copia local del recurso. Urlcache también demuestra cómo implementar un par de políticas de almacenamiento en caché:

Answer 5

Una opción interesante es el protocolo de BLIPJens Alfke. Es como una versión simplificada de BEEP: un sistema de red orientado a mensajes. Básicamente proporciona las abstracciones de bajo nivel para un tubo de mensaje bidireccional para que pueda concentrarse en capas de su protocolo de comunicación en la parte superior.

Tiene algunos seguidores valiosos como Marcus Zarra (autor de la Biblia CoreData) y el software Gus Mueller de Flying Meat.