Подтвердить что ты не робот

Лучший способ для межпроцессного общения в Mac OS X

Я смотрю на создание приложения Cocoa на Mac с фоновым процессом-демоном (на самом деле, скорее всего, это приложение с большинством головок Cocoa), а также 0 или более "клиентских" приложений, выполняемых локально (хотя, если возможно, я хотел бы также поддерживать удаленные клиенты, а удаленные клиенты могли бы быть только другими устройствами Mac или iPhone OS).

Передаваемые данные будут довольно тривиальными, в основном просто текстовыми и командами (которые, как я полагаю, могут быть представлены как текст в любом случае) и, возможно, случайным маленьким файлом (возможно, изображение).

Я просмотрел несколько методов для этого, но я не уверен, что "лучше" для этой задачи. Вещи, которые я рассмотрел:

  • Чтение и запись в файл (... да), очень простой, но не очень масштабируемый.
  • Чистые сокеты (у меня нет опыта работы со сокетами, но, похоже, я могу использовать их для отправки данных локально и по сети. Хотя это кажется громоздким, если делать все в Cocoa
  • Распределенные объекты: кажется довольно неэлегантным для такой задачи
  • NSConnection: я не могу понять, что делает этот класс, но я читал об этом в некоторых результатах поиска IPC.

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

4b9b3361

ОТВЕТЫ

Ответ 1

В настоящее время я изучаю те же вопросы. Для меня возможность добавления клиентов Windows впоследствии усложняет ситуацию; в вашем случае ответ кажется более простым.

О параметрах, которые вы рассмотрели:

  • Управляющие файлы:. Хотя можно управлять через управляющие файлы, вы должны иметь в виду, что файлы должны передаваться через сетевую файловую систему среди задействованных машин. Таким образом, сетевая файловая система служит абстракцией фактической сетевой инфраструктуры, но не обеспечивает полную мощность и гибкость, которые обычно имеют сеть. Реализация. Практически вам нужно иметь по крайней мере два файла для каждой пары клиентов/серверов: файл, который сервер использует для отправки запроса клиенту (-ам) и файлу ответов. Если каждый процесс может взаимодействовать в обоих направлениях, вам необходимо его дублировать. Кроме того, как клиент (ы), так и сервер работают на основе "pull", то есть они должны часто пересматривать файлы управления и видеть, было ли сделано что-то новое.

    Преимущество этого решения заключается в том, что он сводит к минимуму необходимость изучения новых методов. Большой недостаток заключается в том, что он предъявляет огромные требования к программной логике; многие вещи нужно позаботиться о вас (Будут ли файлы записаны в одном виде или может случиться, что любая сторона собирает несогласованные файлы? Как часто должны выполняться проверки? Мне нужно беспокоиться о файловой системе, например, кэширование и т.д. Могу ли я добавить шифрование позже, не обойдя без каких-либо вещей вне кода программы?...)

    Если переносимость была проблемой (что, насколько я понял из вашего вопроса, не так), тогда это решение будет легко переноситься в разные системы и даже на разные языки программирования. Тем не менее, я не знаю ни одного сетевого файла ystem для iPhone OS, но я не знаком с этим.

  • Сокеты: Интерфейс программирования, безусловно, отличается; в зависимости от вашего опыта программирования сокетов, это может означать, что у вас есть больше работы, изучающей его, и отладки позже. Реализация. Практически вам понадобится аналогичная логика, как и раньше, то есть клиент и сервер (ы), обменивающиеся данными через сеть. Определенный плюс этого подхода заключается в том, что процессы могут работать на основе "push", то есть они могут прослушивать сокет до тех пор, пока не поступит сообщение, которое будет лучше проверять управляющие файлы. Сетевая коррупция и несоответствия также не являются вашей проблемой. Кроме того, вы (можете) больше контролировать способ установления соединений, а не полагаться на вещи вне вашего управления программой (опять же, это важно, если вы решите добавить шифрование позже).

    Преимущество заключается в том, что с плеч снимаются многие вещи, которые будут беспокоить реализацию в 1. Недостатком является то, что вам по-прежнему необходимо существенно изменить логику программы, чтобы убедиться, что вы отправляете и получаете правильную информацию (типы файлов и т.д.).

    В моем опыте мобильность (т.е. легкость перехода к различным системам и даже языкам программирования) очень хороша, так как работает любая даже дистанционно совместимая с POSIX.

    [ EDIT: В частности, как только вы сообщаете двоичные числа, endianess становится проблемой, и вы должны заботиться об этой проблеме вручную - это общий (!) специальный случай "правильной информации", о которой я упоминал выше. Это укусит вас, например. когда у вас есть PowerPC, разговаривающий с Intel Mac. Этот частный случай исчезает с решением 3. + 4. вместе со всеми остальными вопросами "правильной информации".]

  • +4. Распределенные объекты: Кластер классов NSProxy используется для реализации распределенных объектов. NSConnection отвечает за настройку удаленных подключений как необходимое условие для отправки информации, поэтому, поняв, как использовать эту систему, вы также понимаете распределенные объекты.; ^)

    Идея заключается в том, что ваша программная логика высокого уровня не нуждается в изменении (т.е. ваши объекты обмениваются сообщениями и получают результаты, а сообщения вместе с типами возврата идентичны тем, с которыми вы привыкли, от локальной реализации), не беспокоясь о деталях сетевой инфраструктуры. Ну, по крайней мере теоретически. Реализация: Я также работаю над этим прямо сейчас, поэтому мое понимание по-прежнему ограничено. Насколько я понимаю, вам нужно настроить определенную структуру, т.е. Вы все равно должны решить, какие процессы (локальные и/или удаленные) могут получать сообщения; это то, что делает NSConnection. На этом этапе вы неявно определяете архитектуру клиент/сервер, но вам не нужно беспокоиться о проблемах, упомянутых в 2.

    На сервере проекта Gnustep имеется введение с двумя явными примерами; он показывает, как работает эта технология, и является хорошей отправной точкой для экспериментов: http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

    К сожалению, недостатки - полная потеря совместимости (хотя вы все равно справитесь с настройкой, о которой вы упоминали Mac и iPhone/iPad) с другими системами и потерей переносимости на другие языки. Gnustep с Objective-C в лучшем случае совместим с кодом, но нет способа связи между Gnustep и Cocoa, см. Мое редактирование на вопрос № 2 здесь: CORBA на Mac OS X (Cocoa)

    [ EDIT: Я просто наткнулся на другую информацию, о которой я не знал. Хотя я проверил, что NSProxy доступен на iPhone, я не проверял, являются ли другие части механизма распределенных объектов. По этой ссылке: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (поиск по фразе "iPhone OS" ), они не являются. Это исключило бы это решение, если вы в настоящий момент требуете использовать iPhone/iPad.]

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

Ответ 2

Отказ от ответственности: распределенные объекты недоступны на iPhone.

Почему вы находите распределенные объекты inelegant? Здесь звучит неплохо:

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

Документация может заставить ее звучать как больше работы, чем она есть на самом деле, но все, что вам в основном нужно сделать, - это чистое использование протоколов и экспорт или, соответственно, подключение к корневому объекту серверов.
Остальное должно происходить автоматически за кулисами для вас в данном сценарии.

Ответ 3

Мы используем ThoMoNetworking, и он отлично работает и работает быстро. В основном это позволяет отправлять NSCoding-совместимые объекты в локальной сети, но, конечно, также работает, если клиент и сервер находятся на одной машине. В качестве обертки вокруг классов фундамента он заботится о спаривании, переподключениях и т.д.