Выбор архитектуры связи в приложении IOS / Linux?

Question

У меня проблема с архитектурой программного обеспечения.Мне нужно спроектировать приложение IOS, которое будет взаимодействовать с приложением Linux, чтобы получить состояние датчика и опубликовать команду привода.Оба приложения работают в локальной сети с Wi-Fi-соединением Ad-Hoc между устройством IOS и компьютером Linux.

Поэтому мне нужно синхронизировать два значения между двумя приложениями (как описано на рисунке 1).В системе Linux / Linux я решаю эту проблему благодаря любому промежуточному программному обеспечению для издателей и подписчиков. Но как я могу решить эту проблему в мире IOS / Linux ?

На самом деле приложение Linux встраивает асинхронный TCP-сервер, а приложение IOSасинхронный TCP-клиент.Оба приложения взаимодействуют через сокет TCP.Я думаю, что этот метод является методом низкого уровня, и я хотел бы перевести уровень связи на гораздо более высокий уровень инфраструктуры связи, основанной на услугах.

После некоторого библиографического исследования я нашел три способа решения моей проблемы:

1. Способ REST:

   Я могу создать веб-сервис RESTful, который моделирует состояние датчика и который может отправлять команду приводу.Для IOS существует реализация клиента веб-службы RESTful, то есть «RESTKit», и я думаю, что могу использовать Apache / Axis2 на стороне сервера.

2. Способ RPC:

   Я могу создать на своемКомпьютер Linux - поставщик услуг RPC благодаря libmaia.На стороне IOS я могу использовать xmlrpc (https://github.com/eczarny/xmlrpc). Мои две программы будут взаимодействовать благодаря службе, описанной на рисунке ниже.

3. Способ ZeroConf:

   Я не попал вподробно об этих методах, но я полагаю, что я могу использовать Bonjour на стороне IOS и AVAHI на стороне linux, а затем создать пользовательский сервис, как в RPC с обеих сторон.

Обсуждение этих методов:

Путь REST не кажется хорошим, потому что: " Разработан интерфейс RESTбыть эффективным для передачи крупномасштабных гипермедиа данных"(из главы 5 Филдингской диссертации). Мои данные - очень точные данные зерна, потому что моя команда - это просто число с плавающей точкой, а состояние моего датчика тоже.

Я думаю, что нет большой разницы между способом ZeroConf и способом RPC. ZeroConf предоставляет «только» механизм обнаружения службы, и мне не нужен этот механизм, потому что мое приложение является жестким приложением.h сторон знает, какие службы существуют.

Итак, мой вопрос:

• Является ли метод на основе XML RPC хорошим выбором для решения моей проблемы синхронизации переменных между Iphone икомпьютер?
• Существуют ли другие методы?

Приветствия,

Answer 1

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

Я также предполагаю, что ваша модель заключается в том, что устройство iOS опрашивает сервер для синхронизации состояния.

Вероятно, лучше избегать прямого использования сокетов Berkeley на устройстве iOS. У iOS раньше были проблемы с низкоуровневыми сокетами, не соединяющимися после периода бездействия. По крайней мере, я бы использовал объекты NSStream или CFStream для транспорта или, если возможно, я бы использовал NSURL, NSURLConnection, NSURLRequest. Возможность асинхронной загрузки данных NSURLConnection хорошо сочетается с циклом обновления графического интерфейса iOS.

Я думаю, вам придется реализовать какую-то форму языка определения данных независимо от вашего метода реализации (RES, XML RPC, CORBA, свернуть свой собственный и т. Д.)

Данные, которые вы отправляете и получаете по проводам, вероятно, будут XML или JSON. Если вы используете XML, вам придется написать свой собственный обработчик документов XML, так как iOS реализует класс NSXMLParser, но не класс NSXMLDocument. Я бы сослался на JSON, так как синтаксический анализатор JSON вернет иерархию NSArray или NSDictionary объектов NSO, содержащих несериализованные данные.

Я работал над реализацией GSOAP, которая использовала CFStreams для транспорта. Каждый запрос и ответ обрабатывались классом, специфичным для запроса, для создания объектов, специфичных для запроса. Каждый новый запрос требовал нового определения класса для возвращаемых данных. Интерактивность поддерживалась путем запуска запросов через NSOperationQueue. Здесь много шимов. Основным преимуществом этого метода было то, что интерфейс был определен в схеме wsdl (все запросы, ответы и структуры данных были определены в одном месте.

Я не смотрел на CORBA на iOS - вам пришлось бы привязать библиотеки C ++ к своему коду и изменить транспорт для использования CFStreams. Опять же, много шимов, но преимущество в том, что протокол определен в файле idl. Также у вас будет одно соединение с сервером, вместо того, чтобы устанавливать и разрывать TCP-соединения для каждого запроса.

Мои $ .02

Answer 2

Я действительно рекомендую вам использовать "tcp socket + protobuf" для вашего приложения.

Socket очень эффективно передает сообщения в ваше приложение ios, а protobuf может сэкономить ваше время на доставку сообщения вместо символьных байтов. Ваше другое предложение высокого уровня на самом деле вносит больше сложностей ...

Answer 3

Похоже, вы выбрали некоторые существующие технологии и пытаетесь приспособить их к проблеме.

Я бы хотел перенести уровень связи на гораздо более высокий уровень инфраструктуры связи на основе услуг.

Почему?

Вам следует искать метод, который соответствует вашим требованиям с точки зрения доступных ресурсов (если вы предполагаете, что клиент может поддерживать согласованное соединение? Насколько он безопасен?)быть?) Однако, помимо функциональности, доступности и безопасности, самой большой проблемой должно быть то, как реализовать это с наименьшими усилиями.

Я бы склонялся к подходу REST, потому что:

• Я много занимаюсь веб-разработкой, поэтому мои навыки лежат там
• у него минимальные зависимости
• хорошо поддерживается код, реализующий стек протоколов на обоих концах
• тривиально заменить любой конец соединения для проверки реализации
• it 'Тривиально контролировать коммуникации (если они не зашифрованы) для проверки реализации
• добавление шифрования / аутентификации не меняет обмен данными

С учетом вашей цитаты, HTTP невероятно, не самый разумный для SCADA - но тогда ни iOS.

Answer 4

XML RPC и то, что вы называете "RESTful Web Service", оба сделают свою работу. Если вы можете использовать JSON вместо XML в качестве формата полезной нагрузки, это несколько упростит ситуацию на iOS.

Zeroconf (он же Bonjour) может использоваться в сочетании с любым подходом. В вашем случае это позволило бы клиенту определять местоположение сервера динамически, в качестве альтернативы жесткому кодированию URL или другого адреса в клиенте. Zeroconf не играет никакой роли в реальной передаче данных на уровне приложения.

Возможно, вы не захотите, чтобы приложение linux вызывало приложение iOS, поскольку это сильно усложнит приложение iOS, а также будет очень жадно работать от батареи.