Сеть Objective-C - лучшие практики?

Question

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

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

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

Есть еще мысли?

РЕДАКТИРОВАТЬ: Я не ожидаю, что количество клиентов станет намного выше 50 или около того, на максимальном

Answer 1

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

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

[remoteServer update:client];

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

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

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

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

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

Answer 2

Интересным вариантом является протокол BLIP от Jens Alfke . Это похоже на урезанную версию BEEP : сетевую систему, ориентированную на сообщения. Он в основном обеспечивает низкоуровневые абстракции для двунаправленного канала сообщений, так что вы можете сосредоточиться на наложении своего коммуникационного протокола поверх него.

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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