Melhor maneira de fazer comunicação entre processos no Mac OS X

StackOverflow https://stackoverflow.com/questions/2846337

Pergunta

Estou pensando em construir um aplicativo Cocoa no Mac com um processo daemon de back-end (na verdade, apenas um aplicativo Cocoa quase sem cabeça, provavelmente), junto com 0 ou mais aplicativos "clientes" em execução localmente (embora, se possível, eu ' também gosto de oferecer suporte a clientes remotos;os clientes remotos seriam apenas outros dispositivos Macs ou iPhone OS).

Os dados sendo comunicados serão bastante triviais, principalmente apenas texto e comandos (que eu acho que podem ser representados como texto de qualquer maneira), e talvez um pequeno arquivo ocasional (possivelmente uma imagem).

Examinei alguns métodos para fazer isso, mas não tenho certeza de qual é o "melhor" para a tarefa em questão.Coisas que considerei:

  • Ler e gravar em um arquivo (…sim), muito básico, mas não muito escalável.
  • Soquetes puros (não tenho experiência com soquetes, mas acho que posso usá-los para enviar dados localmente e através de uma rede.Embora pareça complicado fazer tudo em Cocoa
  • Objetos Distribuídos:parece bastante deselegante para uma tarefa como esta
  • NSConnection:Eu realmente não consigo descobrir o que essa classe faz, mas li sobre isso em alguns resultados de pesquisa do IPC

Tenho certeza de que faltam coisas, mas fiquei surpreso ao descobrir que faltam recursos sobre esse assunto.

Foi útil?

Solução

Atualmente estou analisando as mesmas questões.Para mim a possibilidade de adicionar clientes Windows posteriormente torna a situação mais complicada;no seu caso, a resposta parece ser mais simples.

Sobre as opções que você considerou:

  1. Arquivos de controle: Embora seja possível comunicar-se através de arquivos de controle, você deve ter em mente que os arquivos precisam ser comunicados através de um sistema de arquivos de rede entre as máquinas envolvidas.Portanto, o sistema de arquivos de rede serve como uma abstração da infra-estrutura de rede real, mas não oferece todo o poder e flexibilidade que a rede normalmente possui. Implementação: Praticamente, você precisará ter pelo menos dois arquivos para cada par de clientes/servidores:um arquivo que o servidor usa para enviar uma solicitação ao(s) cliente(s) e um arquivo para as respostas.Se cada processo puder se comunicar nos dois sentidos, você precisará duplicar isso.Além disso, tanto o(s) cliente(s) quanto o(s) servidor(es) trabalham em regime de “pull”, ou seja, precisam revisitar os arquivos de controle com frequência e verificar se algo novo foi entregue.

    A vantagem desta solução é que minimiza a necessidade de aprendizagem de novas técnicas.A grande desvantagem é que ele exige muito da lógica do programa;muitas coisas precisam ser resolvidas por você (os arquivos serão gravados inteiros ou pode acontecer de alguém pegar arquivos inconsistentes?Com que frequência as verificações devem ser implementadas?Preciso me preocupar com o sistema de arquivos, como cache, etc?Posso adicionar criptografia posteriormente sem brincar com coisas fora do código do meu programa?...)

    Se a portabilidade fosse um problema (o que, pelo que entendi da sua pergunta, não é o caso), então essa solução seria fácil de portar para diferentes sistemas e até mesmo para diferentes linguagens de programação.No entanto, não conheço nenhum sistema de arquivos de rede para iPhone OS, mas não estou familiarizado com isso.

  2. Tomadas: A interface de programação é certamente diferente;dependendo da sua experiência com programação de soquetes, isso pode significar que você terá mais trabalho para aprendê-lo primeiro e depurá-lo depois. Implementação:Praticamente, você precisará de uma lógica semelhante à anterior, ou seja, cliente(s) e servidor(es) comunicando-se através da rede.Uma vantagem definitiva dessa abordagem é que os processos podem trabalhar em uma base "push", ou seja, eles podem escutar em um soquete até que chegue uma mensagem, o que é superior à verificação regular dos arquivos de controle.Corrupção e inconsistências na rede também não são sua preocupação.Além disso, você (pode) ter mais controle sobre a maneira como as conexões são estabelecidas, em vez de depender de coisas fora do controle do seu programa (novamente, isso é importante se você decidir adicionar criptografia posteriormente).

    A vantagem é que muitas coisas são tiradas de seus ombros e que incomodariam uma implementação em 1.A desvantagem é que você ainda precisa alterar substancialmente a lógica do seu programa para garantir o envio e o recebimento das informações corretas (tipos de arquivo, etc.).

    Na minha experiência, a portabilidade (ou seja, facilidade de transição para diferentes sistemas e até linguagens de programação) é muito boa, pois qualquer coisa remotamente compatível com POSIX funciona.

    [EDITAR: Em particular, assim que você comunica números binários, o endianess se torna um problema e você precisa cuidar desse problema manualmente - esse é um caso especial comum (!) do problema de "informações corretas" que mencionei acima.Ele vai te morder, por exemplo.quando você tem um PowerPC conversando com um Intel Mac.Este caso especial desaparece com a solução 3.+4.juntas estarão todas as outras questões de “informação correta”.]

  3. +4. Objetos distribuídos: O NSProxy cluster de classe é usado para implementar objetos distribuídos. NSConnection é responsável por configurar conexões remotas como um pré-requisito para o envio de informações, portanto, depois de entender como usar este sistema, você também entenderá os objetos distribuídos.;^)

    A ideia é que a lógica do seu programa de alto nível não precise ser alterada (ou seja, seus objetos se comunicam por meio de mensagens e recebem resultados e as mensagens junto com os tipos de retorno são idênticos aos que você está acostumado na sua implementação local) sem ter preocupar-se com as particularidades da infra-estrutura da rede.Bem, pelo menos em teoria. Implementação: Também estou trabalhando nisso agora, então meu entendimento ainda é limitado.Pelo que entendi, você precisa configurar uma determinada estrutura, ou seja, ainda precisa decidir quais processos (locais e/ou remotos) podem receber quais mensagens;isso é o que NSConnection faz.Neste ponto, você define implicitamente uma arquitetura cliente/servidor, mas não precisa se preocupar com os problemas mencionados em 2.

    Há uma introdução com dois exemplos explícitos no servidor do projeto Gnustep;ilustra como a tecnologia funciona e é um bom ponto de partida para experimentar:http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

    Infelizmente, as desvantagens são uma perda total de compatibilidade (embora você ainda se saia bem com a configuração mencionada apenas para Macs e iPhone/iPad) com outros sistemas e perda de portabilidade para outros idiomas.Gnustep com Objective-C é, na melhor das hipóteses, compatível com código, mas não há como se comunicar entre Gnustep e Cocoa, veja minha edição da pergunta número 2 aqui: CORBA no Mac OS X (cacau)

    [EDITAR: Acabei de me deparar com outra informação que desconhecia.Embora eu tenha verificado isso NSProxy está disponível no iPhone, não verifiquei se as outras partes do mecanismo de objetos distribuídos estão.De acordo com este link: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (pesquise na página a frase "iPhone OS") eles não são.Isso excluiria esta solução se você exigir o uso do iPhone/iPad neste momento.]

Portanto, para concluir, há uma compensação entre o esforço de aprender (e implementar e depurar) novas tecnologias, por um lado, e a codificação manual da lógica de comunicação de nível inferior, por outro.Embora a abordagem de objetos distribuídos ocupe a maior parte de seus ombros e incorra nas menores alterações na lógica do programa, ela é a mais difícil de aprender e também (infelizmente) a menos portátil.

Outras dicas

Isenção de responsabilidade: Objetos distribuídos são Não está disponível no iPhone.

Por que você encontra objetos distribuídos deselegante? Eles parecem uma boa combinação aqui:

  • Marshaling transparente de tipos fundamentais e classes Objective-C
  • realmente não importa se os clientes são locais ou remotos
  • Não há muito trabalho adicional para aplicações baseadas em cacau

A documentação pode fazer parecer mais trabalho do que realmente é, mas tudo o que você basicamente precisa fazer é usar protocolos de maneira limpa e exportar, ou se conectar, respectivamente, o objeto Root Servers.
O resto deve acontecer automaticamente nos bastidores para você no cenário fornecido.

Nós estamos usando Thomonetworking E funciona bem e é rápido para configurar. Basicamente, ele permite que você envie objetos compatíveis com o NSCoding na rede local, mas é claro que também funciona se o cliente e o servidor estiverem na mesma máquina. Como um invólucro nas aulas da fundação, ele cuida de emparelhamento, reconecções, etc.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top