Каковы плюсы и минусы PyRo и RPyC библиотек Python?

Question

Я ищу механизм удаленного вызова процедур для Python и обнаружил, что PyRo (удаленный объект Python) и RPyC (удаленный вызов Python) являются вещь, которую я ищу.

Однако мне любопытно узнать, как они соотносятся друг с другом и каковы их плюсы и минусы?

Answer 1

Лично я нахожу их примерно эквивалентными, но автор RPyC ( здесь ) заявляет о большей простоте (и, возможно, для кого-то, кто не все, кто привык к распределенным вычислениям, у него есть точка зрения; я, возможно, слишком привык к этому хорошо судить ;-). Цитирую его ...:

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

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

Более независимый голос, Дэвид Мерц, предлагает здесь хорошее объяснение RPyC (PyRO существует намного дольше, и Дэвид указывает на предыдущие статьи, освещающие его). «Классический режим» представляет собой полностью общую и простую часть с нулевой безопасностью, «по сути, идентичную Pyro (без дополнительной системы безопасности Pyro)»; «сервисный режим» более безопасен (все, что явно не разрешено, по умолчанию запрещено), и, по словам Дэвида, «сервисный режим по сути является RPC (например, XML_RPC), по модулю некоторых деталей о соглашениях и реализации вызовов». Мне кажется, это справедливая оценка.

Кстати, мне не особенно нравятся одноязычные RPC-системы - даже если Python покрывает 99% моих потребностей (и это не совсем так ;-), мне нравится тот факт, что я могу использовать любой язык для оставшиеся 1% ... Я не хочу отказываться от этого на уровне RPC! -) Я бы лучше сделал, например, JSON-RPC через этот модуль или тому подобное ...! -).

Answer 2

YMMV, но вот мои результаты оценки RPyC, Pyro4 и ZeroRPC для использования в предстоящем проекте. Обратите внимание, что нет углубленных тестов, и это не является углубленным обзором, а лишь мои заметки о том, насколько хорошо каждый из них работает для нужд моего будущего проекта.

ZeroRPC:

• довольно много зависимостей
• очень молодой проект (основная поддержка от dotCloud)
• очень мало документации
• не может получить доступ к атрибутам удаленного объекта, только методы
• Из-за отсутствия доступа к атрибутам завершение вкладки IPython не работает на удаленных объектах

Pyro4:

• Поддержка Python3
• Хорошая, обильная документация
• зрелый проект
• Нет доступа к атрибуту / завершение вкладки IPython

Pyro3:

• поддержка доступа к атрибутам (заявлено в документации; не проверено)
• Нет поддержки Python3

RPyC:

• доступ к атрибуту, завершение вкладки IPython для удаленных объектов
• Поддержка Python3 (заявлено в документации; еще не подтверждено)
• пятнистая документация

FWIW:

Мне нравится RPyC (может, потому что это был мой первый? ;-), но его документация скудна. Это было мое первое знакомство с RPC, и мне потребовалось много времени, чтобы понять, как заставить вещи работать Автор (Томер) очень полезен и отвечает на вопросы в списке Google RPyC.

Если вы новичок в RPC, я бы предложил начать с Pyro и воспользоваться его обширной документацией для изучения веревок. Переходите к RPyC, ZeroRPC и т. Д. В соответствии с вашими потребностями.