Objective-C networking - melhores práticas?

Question

Eu estou construindo um aplicativo Objective-C que tem um servidor e um cliente. O cliente pode enviar atualizações para o servidor, e o servidor precisa ser capaz de enviar atualizações para cada cliente conectado. Eu estive pensando sobre a melhor forma de implementar este sistema, mas estou pedindo suas sugestões.

Atualmente, eu estou pensando que, quando novas atualizações estão disponíveis, o servidor irá usar tópicos para enviar a atualização para cada cliente, por sua vez. Se um cliente expira, eles estão desconectados. Tenho muito pouco trabalho em rede experiência, por isso estou pedindo a sua visão.

Você acha que este sistema iria funcionar bem? Se assim for, você tem alguma sugestão sobre como fazer a rosca? Quaisquer classes NS você pode apontar-me em? Tem que haver algum tipo de fila eu posso usar, eu estou pensando.

Quaisquer outros pensamentos?

EDIT:. Eu não espero que a contagem de cliente para ficar muito acima de 50 ou mais, no máximo

Answer 1

Enquanto o cliente e servidor são aplicativos OS X e pode tanto ser escrito em Objective-C usando os quadros de cacau, eu recomendo que você dê uma olhada no Distribuído tecnologia objetos (DO) em Cocoa. Eu não vou tentar dar um tutorial em Objetos Distribuídos aqui, apenas explicar por que ele pode ser útil ...

DO lida com detalhes da rede assíncronos para você (todas as suas atualizações do cliente poderia acontecer em um único segmento). Além disso a semântica de comunicação com um objeto remoto (cliente para servidor ou vice-versa; DO é bidirecional uma vez que a conexão é estabelecida) são muito semelhantes aos de comunicação dentro do processo. Em outras palavras, uma vez que você tem uma referência para o objeto remoto (realmente um NSDistantObject que age como um proxy para o objeto na outra extremidade da conexão), o código do cliente pode enviar mensagens para o objeto remoto como se fosse local:

[remoteServer update:client];

a partir do cliente ou

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

a partir do servidor. Vou deixar os detalhes de configuração da conexão e para obter a referência remoteserver ou remoteClient a você depois de ler o objetos distribuídos guia de programação .

A desvantagem de usar DO é que você está amarrado a Cacau; será muito difícil escrever um cliente ou servidor não-cacau que se comunica usando Distirbuted objetos. Se há uma chance de que você pode querer ter cliente ou servidor implementações não-Cacau, você não deve usar DO. Neste caso, eu recomendaria algo simples, com um monte de cross-plataforma e suporte a idiomas. A API estilo REST sobre HTTP é uma boa opção. Ter um olhar para o Cocoa URL Carregando Sistema documentação para obter informações sobre como implementar HTTP solicitações e respostas. Ter um olhar para CocoaHTTPServer exemplo de código da Apple ou um projeto code.google.com de mesmo nome para obter informações sobre a implementação de um servidor HTTP em seu código de cacau.

Como uma última opção, você pode dar uma olhada no rel="noreferrer"> Cacau se você quiser implementar seu próprio protocolo de rede. subclasses de NSStream vai deixar você escuta em um soquete de rede e alça assíncrono lê / escreve de / para que soquete. Um monte de pessoas usam AsyncSocket para esta finalidade. Ela envolve o (nível inferior) CFStream e CFSocket e faz escrever código de rede um pouco mais fácil.

Answer 2

Quando o servidor envia atualizações para os clientes, provavelmente seria mais fácil simplesmente ter um identificador de thread todos eles, e apenas usar assíncrono soquetes. Claro que isso vai depender de quantos clientes você teve que lidar com também.

Answer 3

Há vários exemplos de redes no lado do desenvolvedor maçã. Uma que eu recomendo que você check-out é o URLCache, que pode ser baixado. Citando a documentação da Apple para este exemplo:

URLCache é um aplicativo de iPhone exemplo que demonstra como fazer o download de um recurso fora da web, armazená-lo no diretório de dados do aplicativo, e usar a cópia local do recurso. URLCache também demonstra como implementar um par de políticas de cache:

Answer 4

Uma opção interessante é a BLIP protocolo de Jens Alfke . É como uma versão simplificada do BEEP : uma mensagem orientada sistema de rede. Ele basicamente fornece as abstrações de baixo nível para um tubo de mensagem bidirecional para que possa concentrar-se em camadas seu protocolo de comunicação em cima dela.

Ele tem alguns seguidores dignos, como Marcus Zarra (autor do CoreData bíblia) e Gus Mueller of Flying software carne.

Answer 5

Eu não sei como você pretende projetar seu sistema, mas geralmente um servidor não pode se conectar a um cliente; o cliente deve iniciar a comunicação. Com um baixo limite de 50 clientes, você não pode estar olhando para um servidor web / cliente-like implementação ...

Dito isto, existem basicamente duas formas de comunicação cliente-servidor punho: 1. As pesquisas do cliente o servidor periodicamente para obter atualizações 2. O cliente mantém um aberto conexão com o servidor e os as responde de servidor com um conhecido (como em ambos os lados entendo) protocolo.