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

pasar contactos de iphone a android por bluetooth

Question

Estoy construyendo una aplicación Objective-C que tiene un servidor y 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 por turno. 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 sobre 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.

¿Algún otro pensamiento?

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

Answer 1

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

Answer 2

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

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

Answer 3

No sé cómo planea diseñar su sistema, pero generalmente un servidor no puede conectarse con un cliente; el cliente debe iniciar la comunicación. Con un límite bajo de 50 clientes, es posible que no esté buscando una implementación de servidor web / cliente ...

Dicho esto, básicamente hay dos maneras de manejar la comunicación del servidor del cliente: 1. El cliente sondea el servidor periódicamente para obtener actualizaciones 2. El cliente mantiene una conexión abierta al servidor y el servidor responde con un conocido (como en ambos lados) entiéndelo) protocolo.

Answer 4

Siempre que tanto el cliente como el servidor sean aplicaciones OS X y que ambos puedan estar escritos en Objective-C utilizando los marcos Cocoa, le recomendaría encarecidamente que eche un vistazo a la tecnología Distributed Objects (DO) en Cocoa. No intentaré dar un tutorial en Objetos distribuidos aquí, solo explicaré por qué podría ser útil ...

DO maneja los detalles de la red asíncrona por usted (todas las actualizaciones de sus clientes podrían 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];

del servidor Dejaré los detalles de configuración de la conexión y para obtener el servidor remoto o la referencia de RemoteClient después de leer la guía de programación de Objetos distribuidos .

La desventaja de usar DO es que estás atado a Cocoa; será muy difícil 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 del Sistema de carga de URL de Cocoa 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 mismo nombre 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 Guía de programación de Cocoa Stream si desea implementar su propio protocolo de red. NSStream subclases de NSStream le permitirán escuchar en un socket de red y manejar lecturas / escrituras asincrónicas en / 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 5

Una opción interesante es el protocolo BLIP de Jens 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.