La mejor manera de hacer la comunicación entre procesos en Mac OS X

Question

Me estoy mirando a la construcción de una aplicación Cocoa en el Mac con un proceso de demonio de fondo (en realidad una aplicación Cocoa su mayoría sin cabeza, probablemente), junto con 0 o más aplicaciones "cliente" que se ejecutan localmente (aunque si es posible me gustaría dar soporte a clientes remotos, así,. los clientes remotos serían solamente nunca haber otros Macs o dispositivos iPhone OS)

Los datos que se comunican será bastante trivial, en su mayoría sólo texto y comandos (que supongo que se puede representar en forma de texto de todos modos), y tal vez el pequeño archivo de vez en cuando (una imagen posiblemente).

He mirado en algunos métodos para hacer esto, pero no estoy seguro de que es "mejor" para la tarea en cuestión. Cosas que hemos considerado:

• La lectura y la escritura en un archivo (... sí), muy básico, pero no es muy escalable.
• sockets puros (que no tienen experiencia con tomas pero parecen pensar que puedo usarlos para enviar datos a nivel local como a través de una red. Aunque parece complicado si se hace todo en el cacao
• Objetos Distribuidos: parece poco elegante para una tarea como esta
• NSConnection: Realmente no puedo averiguar lo que incluso hace esta clase, pero he leído de ella en algunos resultados de búsqueda IPC

Estoy seguro de que hay cosas que me faltan, pero me sorprendió encontrar una falta de recursos sobre este tema.

Answer 1

Actualmente estoy investigando las mismas preguntas. Para mí la posibilidad de añadir más tarde los clientes de Windows hace que la situación sea más complicada; en su caso, la respuesta parece ser más simple.

Acerca de las opciones que ha considerado:

1. Archivos de control: Si bien es posible comunicarse a través de los archivos de control, hay que tener en cuenta que los archivos deben ser comunicados a través de un sistema de archivos de red entre los equipos implicados. Por lo que el sistema de archivos de red sirve como una abstracción de la infraestructura de red real, pero no ofrece toda la potencia y flexibilidad de la red tiene normalmente. Implementación: En la práctica, usted tendrá que tener al menos dos archivos para cada par de clientes / servidores: un archivo utiliza el servidor para enviar una petición al cliente (s) y un archivo para las respuestas. Si cada proceso se puede comunicar en ambos sentidos, es necesario duplicar este. Por otra parte, tanto el cliente (s) y el servidor de trabajo (s) sobre una base de "pull", es decir, tienen que volver a examinar los archivos de control de frecuencia y ver si algo nuevo ha sido entregado.

   La ventaja de esta solución es que minimiza la necesidad de aprender nuevas técnicas. La gran desventaja es que tiene una gran demanda en la lógica del programa; un montón de cosas tienen que ser atendidos por usted (se escribirán los archivos en una sola pieza o puede suceder que alguna selecciones del partido hasta archivos inconsistentes? ¿Con qué frecuencia se deben implementar controles? ¿Es necesario que se preocupe por el sistema de archivos, al igual que el almacenamiento en caché, etc? ¿Puedo añadir encriptación más tarde sin jugando un poco con las cosas fuera de mi código de programa? ...)

   Si la portabilidad era un problema (que, por lo que yo entendí de su pregunta no es el caso), entonces esta solución sería fácil de portar a diferentes sistemas e incluso diferentes lenguajes de programación. Sin embargo, no sé de cualquier red de archivos istema para iPhone OS, pero no estoy familiarizado con esto.

2. Enchufes: La interfaz de programación es ciertamente diferente; dependiendo de su experiencia con la programación del zócalo puede significar que usted tiene más trabajo aprender primero y depuración más tarde. La aplicación : En la práctica, se necesita una lógica similar a la anterior, es decir, el cliente (s) y el servidor (s) que se comunica a través de la red. Un punto a su favor de este enfoque es que los procesos pueden trabajar sobre una base de "empuje", es decir, que pueden escuchar en un zócalo hasta que llega un mensaje que es superior a la comprobación de los archivos de control con regularidad. También la corrupción y las inconsistencias de la red no son su preocupación. Por otra parte, usted (mayo) tiene más control sobre la forma en que se establecen las conexiones en lugar de confiar en las cosas fuera del control de su programa (de nuevo, esto es importante si usted decide agregar cifrado más adelante).

   La ventaja es que muchas cosas se toman de sus hombros que se molestaría en una implementación 1. La desventaja es que usted todavía tiene que cambiar la lógica del programa sustancialmente con el fin de asegurarse de que permite enviar y recibir la información correcta (tipos de archivos, etc.).

   En mi experiencia de la portabilidad (es decir, la facilidad de la transición a sistemas diferentes e incluso lenguajes de programación) es muy bueno ya que nada ni remotamente compatible con POSIX funciona.

   [ EDIT: En particular, en cuanto a comunicarse números binarios endianess se convierte en un problema y que tiene que hacerse cargo de este problema de forma manual - esto es un común caso especial de la "(!) información correcta tema" que he mencionado anteriormente. Se va a morder, por ejemplo, cuando se tiene un PowerPC hablar con un Mac Intel. Este caso especial desaparece con la solución 3. + 4. que conjuntamente con todos los demás temas de "información correcta".]

3. 4. objetos distribuidas: El clúster clase NSProxy se utiliza para implementar objetos distribuidos. NSConnection es responsable de establecer conexiones remotas como requisito previo para el envío deformación alrededor, por lo que una vez que entienda cómo utilizar este sistema, también se entiende objetos distribuidos. ; ^)

   La idea es que la lógica del programa de alto nivel no necesita ser cambiado (es decir, los objetos se comunican a través de mensajes y recibir los resultados y los mensajes junto con los tipos de retorno son idénticos a lo que estamos acostumbrados a partir de su aplicación a nivel local ) sin tener que preocuparse sobre los detalles de la infraestructura de red. Bueno, al menos en teoría. Implementación: También estoy trabajando en este momento, así que mi entendimiento es aún limitada. Por lo que yo entiendo, sí es necesario para configurar una cierta estructura, es decir, que todavía tiene que decidir qué procesos (local y / o remota) que puede recibir mensajes; esto es lo que hace NSConnection. En este punto, se definen implícitamente una arquitectura cliente / servidor, pero no es necesario que preocuparse de los problemas mencionados en 2.

   Hay una introducción con dos ejemplos explícitos en el servidor del proyecto gnustep; que ilustra cómo funciona la tecnología y es un buen punto de partida para la experimentación: http://www.gnustep.org/resources/documentation/ desarrollador / Base / ProgrammingManual / manual_7.html

   Por desgracia, las desventajas son una pérdida total de la compatibilidad (aunque todavía se va a hacer bien con la configuración que usted ha mencionado de Mac y el iPhone / IPAD solamente) con otros sistemas y la pérdida de la portabilidad a otros idiomas. Gnustep con Objective-C es, en el mejor de códigos compatibles, pero no hay manera de comunicarse entre gnustep y Cacao, ver mi edición a la pregunta número 2 aquí: CORBA en Mac OS X (cacao)

   [ EDIT: Me encontré con otra pieza de información que no era consciente de. Mientras He comprobado que NSProxy está disponible en el iPhone, no el registro si las otras partes del mecanismo de objetos distribuidos son. De acuerdo con este enlace: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (buscar en la página para la frase "iPhone OS") ellos no son. Esto excluiría esta solución si la demanda de usar iPhone / iPad en este momento.]

Para concluir, hay un equilibrio entre el esfuerzo de aprendizaje (y la implementación y depuración) las nuevas tecnologías, por un lado y la mano de codificación lógica de comunicación de bajo nivel en el otro. Si bien el enfoque de objetos distribuidos lleva la mayor carga de los hombros e incurre en los más mínimos cambios en la lógica del programa, que es el más difícil de aprender y también (por desgracia) al menos portátil.

Answer 2

Renuncia: son objetos distribuidos no está disponible en el iPhone .

---

¿Por qué a encontrar objetos distribuidos ¿poco elegante? Que suena como un buen partido aquí:

• de clasificación transparente de los tipos fundamentales y clases de Objective-C
• que en realidad no importa wether clientes son local o remoto
• No mucho trabajo adicional para las aplicaciones basadas en cacao

La documentación puede hacer que suene como más trabajo a continuación, lo que realmente es, pero todo lo que básicamente tiene que hacer es utilizar protocolos de forma limpia y exportación, o respectivamente conectarse, el objeto servidores raíz.
El resto debería ocurrir automagicamente detrás de las escenas para que en el escenario dado.

Answer 3

Estamos utilizando ThoMoNetworking y funciona muy bien y es rápido de instalar. Básicamente se le permite enviar objetos que cumplen NSCoding en la red local, pero por supuesto también funciona si el cliente y el servidor están en él la misma máquina. Como una envoltura alrededor de las clases de la fundación que se encarga de emparejamiento, reconexiones, etc ..