Objective-C de redes - las mejores prácticas?

Question

Estoy construyendo una aplicación de Objective-C que tiene tanto un servidor y un cliente. El cliente puede enviar actualizaciones al servidor, y el servidor tiene que ser capaz de enviar actualizaciones a cada cliente conectado. He estado pensando en la mejor manera de poner en práctica este sistema, pero estoy pidiendo por sus sugerencias.

Actualmente, estoy pensando que cuando hay nuevas actualizaciones disponibles, el servidor va a utilizar hilos para enviar la actualización a cada cliente a su vez. Si un cliente se agota, que están desconectados. Tengo muy poca experiencia en redes, por lo que pido su comprensión.

¿Cree que este sistema funcionaría bien? Si es así, ¿tiene alguna sugerencia sobre cómo hacer la rosca? Cualquier clase NS me puede apuntar a? Tiene que haber algún tipo de cola puedo utilizar, estoy pensando.

¿Alguna otra idea?

EDIT: no espero que el recuento de cliente para obtener muy por encima de 50 o menos, en el máximo

.

Answer 1

Mientras tanto el cliente y el servidor de aplicaciones son OS X y ambos pueden ser escritos en Objective-C utilizando los marcos de cacao, recomendaría encarecidamente que tome un vistazo a la distribuida. No voy a tratar de dar un tutorial en objetos distribuidos aquí, sólo a explicar por qué podría ser útil ...

DO maneja detalles de la red asíncronos para usted (todos sus actualizaciones del cliente podría ocurrir en un solo hilo). Además la semántica de comunicación con un objeto remoto (cliente a servidor o viceversa; DO es bidireccional, una vez se establece la conexión) son muy similares a la comunicación en proceso. En otras palabras, una vez que tenga 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), el código de cliente puede enviar mensajes al objeto remoto como si fuera local:

[remoteServer update:client];

desde el cliente o

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

desde el servidor. Voy a dejar los detalles de la configuración de la conexión y para conseguir el remoteServer o referencia remoteClient a que después de leer el noreferrer objetos distribuidos guía de programación .

La desventaja de usar DO es que está atado a cacao; será muy difícil escribir un cliente que no sea de cacao o servidor que se comunica utilizando Distirbuted objetos. Si hay una posibilidad de que usted puede querer tener implementaciones de servidor o cliente no cacao, no se debe utilizar la DO. En este caso, yo recomendaría algo sencillo con una gran cantidad de multiplataforma y soporte de idiomas. Una API estilo REST a través de HTTP es una buena opción. Echar un vistazo a la de cacao documentación URL sistema de carga para obtener información sobre cómo implementar las peticiones y respuestas HTTP. Echar un vistazo a CocoaHTTPServer código de ejemplo de Apple o un proyecto de code.google.com la mismo nombre para obtener información sobre la implementación de un servidor HTTP en el código de cacao.

Como última opción, se puede echar un vistazo a la Cacao Guía de flujo de programación si se desea implementar su propio protocolo de red. subclases de NSStream le permitirá escuchar en una toma de red y manejar asíncrono lee / escribe a / desde ese socket. Una gran cantidad de personas utilizan AsyncSocket para este propósito. Se envuelve el (nivel inferior) y CFStream CFSocket y hace que el código de red escrito algo más fácil.

Answer 2

Cuando el servidor envía actualizaciones a los clientes, que probablemente sería más fácil tener un solo hilo de manejar todos ellos, y sólo tiene que utilizar sockets asincrónicos. Por supuesto, esto dependerá de la cantidad de clientes que tuvo que lidiar con demasiado.

Answer 3

Hay varios ejemplos de redes en el lado de desarrolladores de Apple. Uno le recomiendo que usted echa un vistazo es la 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, la almacena 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 4

Una opción interesante es la BLIP protocolo de Jens Alfke. Es como una versión simplificada de BEEP : un sistema de red orientado a mensajes. Básicamente ofrece las abstracciones de bajo nivel para una tubería de mensajes bidireccional para que pueda concentrarse en su protocolo de comunicación capas en la parte superior de la misma.

Tiene algunos dignos seguidores como Marcus Zarra (autor de la biblia CoreData) y Gus Mueller de vuelo software de carne.

Answer 5

No sé cómo va a diseñar su sistema, pero por lo general 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, usted no puede estar buscando a un / aplicación cliente-como servidor web ...

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