Сетевое взаимодействие Objective-C - лучшие практики?

Question

Я создаю приложение Objective-C, в котором есть как сервер, так и клиент.Клиент может отправлять обновления на сервер, а сервер должен иметь возможность отправлять обновления каждому подключенному клиенту.Я думал о том, как лучше всего внедрить эту систему, но прошу ваших предложений.

В настоящее время я думаю, что когда будут доступны новые обновления, сервер будет использовать потоки для отправки обновления каждому клиенту по очереди.Если время ожидания клиента истекает, они отключаются.У меня очень мало опыта работы в сети, поэтому прошу вашего понимания.

Считаете ли вы, что эта система работала бы хорошо?Если да, есть ли у вас какие-либо предложения о том, как выполнить потоковую обработку?Есть какие-нибудь классы NS, на которые вы можете мне указать?Я думаю, должна быть какая-то очередь, которую я мог бы использовать.

Есть еще какие-нибудь мысли?

Редактировать:Я не ожидаю, что количество клиентов превысит 50 или около того, максимум.

Answer 1

Поскольку и клиент, и сервер являются приложениями OS X и могут быть написаны на Objective-C с использованием фреймворков Cocoa, я бы настоятельно рекомендовал вам ознакомиться с Распределенные Объекты (DO) технология приготовления Какао.Я не буду пытаться давать здесь руководство по распределенным объектам, просто объясню, почему это может быть полезно...

DO обрабатывает асинхронные сетевые данные для вас (все обновления вашего клиента могут происходить в одном потоке).Кроме того, семантика связи с удаленным объектом (клиент-сервер или наоборот;DO является двунаправленным после установления соединения) очень похожи на обмен данными в процессе.Другими словами, как только у вас есть ссылка на удаленный объект (на самом деле NSDistantObject который действует как прокси-сервер для объекта на другом конце соединения), ваш клиентский код может отправлять сообщения удаленному объекту, как если бы он был локальным:

[remoteServer update:client];

от клиента или

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

с сервера.Я оставлю вам подробности настройки соединения и получения ссылки на удаленный сервер или remoteClient после прочтения Руководство по программированию распределенных объектов.

Недостатком использования DO является то, что вы привязаны к Cocoa;это будет очень трудно написать клиент или сервер, отличающийся от Cocoa, который обменивается данными с использованием удаленных объектов.Если есть вероятность, что вы захотите использовать клиентские или серверные реализации, отличные от Cocoa, вам не следует использовать DO .В этом случае я бы порекомендовал что-нибудь простое с большой кроссплатформенной и языковой поддержкой.API в стиле REST через HTTP - хороший вариант.Взгляните на Какао Система загрузки URL-адресов документация для получения информации о том, как реализовать HTTP-запросы и ответы.Взгляните на Apple Сервер CocoaHTTPServer пример кода или code.google.com проект из то же имя для получения информации о внедрении HTTP-сервера в ваш Cocoa-код.

В качестве самого последнего варианта вы можете взглянуть на Какао Руководство по программированию потока если вы хотите реализовать свой собственный сетевой протокол. NSStreamподклассы позволят вам прослушивать сетевой сокет и обрабатывать асинхронные операции чтения / записи в / из этого сокета.Многие люди используют Асинхронный сокет для этой цели.Это обертывает (низкоуровневые) CFStream и CFSocket и несколько упрощает написание сетевого кода.

Answer 2

Когда сервер отправляет обновления клиентам, вероятно, было бы проще просто поручить одному потоку обрабатывать их все и просто использовать асинхронные сокеты.Конечно, это тоже зависело бы от того, со сколькими клиентами вам приходилось иметь дело.

Answer 3

На стороне разработчика Apple есть несколько примеров работы с сетями.Один из них, который я бы рекомендовал вам проверить, - это URLCache, который можно загрузить.Цитирую документацию Apple для этого примера:

URLCache - это пример приложения для iPhone, которое демонстрирует, как загрузить ресурс из Интернета, сохранить его в каталоге данных приложения и использовать локальную копию ресурса.URLCache также демонстрирует, как реализовать несколько политик кэширования:

Answer 4

Интересным вариантом является ВСПЫШКА протокол от Йенс Альфке.Это как урезанная версия ЗВУКОВОЙ СИГНАЛ:сетевая система, ориентированная на сообщения.В основном он предоставляет низкоуровневые абстракции для двунаправленного канала передачи сообщений, чтобы вы могли сосредоточиться на наложении поверх него вашего протокола связи.

У него есть несколько достойных последователей, таких как Маркус Зарра (автор библии CoreData) и Гас Мюллер из Flying Meat software.

Answer 5

Я не знаю, как вы планируете проектировать свою систему, но обычно сервер не может подключиться к клиенту;клиент должен инициировать сообщение.При низком лимите в 50 клиентов вы, возможно, не рассматриваете реализацию, подобную веб-серверу / клиенту...

Тем не менее, существует в основном два способа обработки связи клиент-сервер:1.Клиент периодически опрашивает сервер для получения обновлений 2.Клиент поддерживает соединение с сервером открытым, и сервер отвечает по хорошо известному (в понимании обеих сторон) протоколу.