Я сейчас изучаю те же вопросы. Для меня возможность добавления клиентов Windows позже усложняет ситуацию; в вашем случае ответ кажется более простым.
Управляющие файлы: Хотя обмен данными через управляющие файлы возможен, вы должны помнить, что файлы должны передаваться через сетевую файловую систему среди задействованных машин. Таким образом, сетевая файловая система служит абстракцией реальной сетевой инфраструктуры, но не обеспечивает полной мощности и гибкости, которые обычно имеет сеть. Реализация: На практике вам потребуется как минимум два файла для каждой пары клиент / сервер: файл, который сервер использует для отправки запроса клиенту (-ам), и файл для ответов. Если каждый процесс может взаимодействовать в обоих направлениях, вам необходимо продублировать это. Кроме того, как клиент (ы), так и сервер (ы) работают по принципу «извлечения», то есть им необходимо часто пересматривать контрольные файлы и проверять, доставлено ли что-то новое.
Преимущество этого решения заключается в том, что оно сводит к минимуму необходимость изучения новых методов. Большой недостаток в том, что он предъявляет огромные требования к логике программы; Вы должны позаботиться о многих вещах (Будут ли файлы записаны в виде одного куска или может случиться так, что какая-либо сторона получит несогласованные файлы? Как часто следует проводить проверки? Нужно ли беспокоиться о файловой системе, например, кеширование и т. д. Могу ли я добавить шифрование позже, не разбираясь с вещами вне моего программного кода? ...)
Если бы переносимость была проблемой (что, насколько я понял из вашего вопроса, не так), тогда это решение было бы легко перенести на разные системы и даже на разные языки программирования. Однако я не знаю никаких сетевых файлов для iPhone OS, но я не знаком с этим.
Сокеты: Интерфейс программирования, безусловно, отличается; в зависимости от вашего опыта программирования сокетов, это может означать, что у вас больше работы, сначала изучая его, а потом отлаживая. Реализация : На практике вам потребуется аналогичная логика, как и раньше, т. Е. Клиент (ы) и сервер (ы), взаимодействующие через сеть. Несомненным плюсом этого подхода является то, что процессы могут работать в режиме «push», то есть они могут прослушивать сокет до тех пор, пока не прибудет сообщение, которое лучше, чем регулярная проверка управляющих файлов. Повреждение сети и несоответствия также не являются вашей заботой. Более того, вы (можете) лучше контролировать способ установления соединений, чем полагаться на вещи, находящиеся вне контроля вашей программы (опять же, это важно, если вы решите добавить шифрование позже).
Преимущество состоит в том, что с ваших плеч снимается много вещей, которые мешают реализации в 1. Недостатком является то, что вам все еще нужно существенно изменить логику программы, чтобы убедиться, что вы отправляете и получаете правильную информацию (типы файлов и т. д.).
По моему опыту переносимость (т. Е. Простота перехода на другие системы и даже языки программирования) очень хороша, так как работает все, даже удаленно совместимое с POSIX.
[ РЕДАКТИРОВАТЬ: В частности, как только вы сообщаете двоичные числа, возникает проблема с бесконечностью, и вы должны решить эту проблему вручную - это распространенный (!) Особый случай «правильного» информационный вопрос, о котором я упоминал выше. Это будет кусать вас, например когда у вас 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 (Какао)
[ РЕДАКТИРОВАТЬ: Я только что наткнулся на другую информацию, которую я не знал. Хотя я проверил, что NSProxy доступно на iPhone, я не проверял, есть ли другие части механизма распределенных объектов. По этой ссылке: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (поиск на странице по фразе «iPhone OS») они не являются. Это исключило бы это решение, если вы хотите использовать iPhone / iPad в данный момент.]
Итак, в заключение следует отметить, что существует компромисс между усилиями по изучению (и внедрению и отладке) новых технологий, с одной стороны, и ручному кодированию низкоуровневой коммуникационной логики, с другой. В то время как подход с распределенными объектами берет на себя большую нагрузку на ваши плечи и влечет за собой наименьшие изменения в логике программы, он труднее всего изучать, а также (к сожалению) наименее переносим.