cocoa - ppt - La mejor forma de comunicación entre procesos en Mac OS X

comunicación entre procesos(sockets rpc) (3)

Estoy buscando construir una aplicación Cocoa en la Mac con un proceso de demonio de back-end (probablemente solo una aplicación Cocoa sin cabeza), junto con 0 o más aplicaciones "cliente" ejecutándose localmente (aunque de ser posible hubiera les gusta apoyar clientes remotos también, los clientes remotos solo serían otros Macs o dispositivos iPhone OS).

Los datos que se comunican serán bastante triviales, principalmente solo texto y comandos (que supongo se pueden representar como texto de todos modos), y tal vez el pequeño archivo ocasional (una imagen posiblemente).

He analizado algunos métodos para hacer esto, pero no estoy seguro de cuál es el "mejor" para la tarea en cuestión. Cosas que he considerado:

Leer y escribir en un archivo (... sí), muy básico pero no muy escalable.
Zócalos puros (no tengo experiencia con conectores, pero creo que puedo usarlos para enviar datos localmente y a través de una red. Aunque parece engorroso hacer todo en Cocoa
Objetos distribuidos: parece bastante poco elegante para una tarea como esta
NSConnection : realmente no puedo entender lo que hace esta clase, pero lo he leído en algunos resultados de búsqueda de IPC

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

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

Acerca de las opciones que ha considerado:

Controle los archivos: aunque es posible comunicarse a través de archivos de control, debe tener en cuenta que los archivos deben comunicarse a través de un sistema de archivos de red entre las máquinas involucradas. Por lo tanto, 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 que normalmente tiene la red. Implementación: Prácticamente, necesitará tener al menos dos archivos para cada par de clientes / servidores: un archivo que el servidor utiliza para enviar una solicitud a los clientes y un archivo para las respuestas. Si cada proceso puede comunicarse en ambos sentidos, debe duplicar esto. Además, tanto el (los) cliente (s) como el (los) servidor (es) funcionan en una "extracción", es decir, necesitan volver a visitar los archivos de control con frecuencia y ver si se ha entregado algo nuevo.
La ventaja de esta solución es que minimiza la necesidad de aprender nuevas técnicas. La gran desventaja es que tiene grandes demandas en la lógica del programa; hay que encargarse de muchas cosas (¿los archivos se escribirán de una pieza o puede suceder que una de las partes recoja archivos inconsistentes? ¿Con qué frecuencia se deben implementar las verificaciones? ¿Debo preocuparme por el sistema de archivos? como el almacenamiento en caché, etc.? ¿Puedo agregar cifrado más tarde sin jugar con cosas fuera del código de mi programa? ...)
Si la portabilidad era un problema (que, por lo que entendí de su pregunta no es el caso), esta solución sería fácil de transferir a diferentes sistemas e incluso a diferentes lenguajes de programación. Sin embargo, no conozco ningún sistema de archivos de red para iPhone OS, pero no estoy familiarizado con esto.
Sockets: la interfaz de programación es ciertamente diferente; Dependiendo de su experiencia con la programación de socket, puede significar que tiene más trabajo aprendiendo primero y depurándolo después. Implementación : Prácticamente, necesitará una lógica similar a la anterior, es decir, cliente (s) y servidor (es) que se comunican a través de la red. Un aspecto positivo de este enfoque es que los procesos pueden funcionar de forma "push", es decir, pueden escuchar en un socket hasta que llegue un mensaje que es superior a la comprobación de archivos de control con regularidad. La corrupción de la red y las incoherencias tampoco son su preocupación. Además, usted (puede) tener más control sobre la forma en que se establecen las conexiones en lugar de depender de cosas que están fuera del control de su programa (de nuevo, esto es importante si decide agregar encriptación más adelante).
La ventaja es que se le quitan muchas cosas que le molestarían a una implementación en 1. La desventaja es que aún necesita cambiar sustancialmente la lógica de su programa para asegurarse de que envía y recibe la información correcta (tipos de archivos). etc.).
En mi experiencia, la portabilidad (es decir, la facilidad de transición a diferentes sistemas e incluso lenguajes de programación) es muy buena, ya que todo lo que sea remotamente compatible con POSIX funciona.
[ EDITAR: en particular, tan pronto como comunique números binarios, la endiabilidad se convierte en un problema y debe resolver este problema manualmente; este es un caso especial común (!) Del problema de "información correcta" que mencioné anteriormente. Te morderá, por ejemplo, cuando tienes un PowerPC hablando con un Intel Mac. Este caso especial desaparece con la solución 3. + 4. juntos serán todos los otros asuntos de "información correcta".]
+4. Objetos distribuidos: el NSProxy clase NSProxy se usa para implementar objetos distribuidos. NSConnection es responsable de establecer las conexiones remotas como un requisito previo para el envío de información, por lo que una vez que comprenda cómo usar este sistema, también comprenderá los objetos distribuidos. ; ^)
La idea es que su lógica de programa de alto nivel no necesita ser cambiada (es decir, sus objetos se comunican a través de mensajes y reciben resultados y los mensajes junto con los tipos de devolución son idénticos a los que está acostumbrados de su implementación local) sin tener preocuparse por los detalles de la infraestructura de red. Bueno, al menos en teoría. Implementación: también estoy trabajando en esto ahora, por lo que mi entendimiento es aún limitado. Por lo que yo entiendo, necesitas configurar una cierta estructura, es decir, aún tienes que decidir qué procesos (locales y / o remotos) pueden recibir qué mensajes; esto es lo que hace NSConnection . En este punto, define implícitamente una arquitectura cliente / servidor, pero no necesita preocuparse por los problemas mencionados en 2.
Hay una introducción con dos ejemplos explícitos en el servidor de proyectos Gnustep; ilustra cómo funciona la tecnología y es un buen punto de partida para experimentar: http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html
Desafortunadamente, las desventajas son una pérdida total de compatibilidad (aunque aún así te irá bien con la configuración que mencionaste de Mac y 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 los casos, compatible con el código, pero no hay forma de comunicarse entre Gnustep y Cocoa; consulte mi edición para hacer la pregunta número 2 aquí: CORBA en Mac OS X (Cocoa)
[ EDITAR: Acabo de encontrar otra información que desconocía. Aunque he comprobado que NSProxy está disponible en el iPhone, no verifiqué si las otras partes del mecanismo de objetos distribuidos sí lo están. De acuerdo con este enlace: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (busque en la página la frase "iPhone OS") ellos no son. Esto excluiría esta solución si exige usar iPhone / iPad en este momento.]

Entonces, para concluir, existe una relación de compromiso entre el esfuerzo de aprender (y de implementar y depurar) las nuevas tecnologías, por un lado, y la codificación manual de la lógica de comunicación de bajo nivel, por el otro. Si bien el enfoque del objeto distribuido toma la mayor parte de la carga de sus hombros e incurre en los cambios más pequeños en la lógica del programa, es el más difícil de aprender y también (por desgracia) el menos portátil.

Descargo de responsabilidad: los objetos distribuidos no están disponibles en el iPhone .

¿Por qué encuentras los objetos distribuidos poco elegantes? Suena como un buen partido aquí:

clasificación transparente de tipos fundamentales y clases Objective-C
en realidad no importa si los clientes son locales o remotos
no mucho trabajo adicional para aplicaciones basadas en Cocoa

La documentación puede hacer que suene como más trabajo de lo que realmente es, pero todo lo que tiene que hacer básicamente es usar protocolos limpiamente y exportar, o respectivamente conectarse, al objeto raíz del servidor.
El resto debería suceder automágicamente detrás de escena para usted en el escenario dado.

Estamos usando ThoMoNetworking y funciona bien y es rápido de configurar. Básicamente le permite enviar objetos compatibles con NSCoding en la red local, pero por supuesto también funciona si el cliente y el servidor están en la misma máquina. Como envoltorio alrededor de las clases de base, se encarga de emparejar, reconectar, etc.