Каков самый легкий способ передачи данных через Интернет с помощью Python?

Вероятно, самым дешевым и простым способом передачи будет XML-RPC. Он работает через HTTP (так что вы можете защитить его таким образом), он находится в стандартной библиотеке, и, в отличие от protobuf, вам не нужно беспокоиться о создании и компиляции ваших файлов типов данных (поскольку оба конца работают под управлением Python, динамическая типизация не должно быть проблемой). Единственное предостережение заключается в том, что любые типы, не представленные в XML-RPC, должны быть обработаны или иным образом сериализованы.

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

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

Как и pickling, если я правильно понял ваше «несколько безопасное» требование: распаковка правильно сконструированной вредоносной маринованной строки может выполнить произвольный код на распаковывающей машине. На самом деле, HTTP не является «несколько безопасным» в несколько ином смысле: в этом протоколе нет ничего, что помешало бы злоумышленникам «пронюхать» ваш трафик (поэтому вам никогда не следует использовать HTTP для отправки конфиденциальной полезной нагрузки, если, возможно, вы не используете надежное шифрование на полезной нагрузки перед отправкой и отменить ее после получения). Для безопасности (опять же, в зависимости от того, какое значение вы вкладываете в это слово) вам нужен HTTPS или (проще настроить, не требует покупки сертификатов!-) SSH-туннели.

Как только вы установите туннель SSH между двумя машинами (для Python может помочь paramiko, но даже выполнение это через сценарии оболочки или иным образом, напрямую управляя клиентом командной строки ssh, не так уж плохо ;-) вы можете запускать на нем любой протокол (например, HTTP в порядке), поскольку конечные точки туннеля становятся доступными как заданные пронумерованные порты, на которых Вы можете открыть сокет. Лично я бы рекомендовал JSON вместо XML для кодирования полезной нагрузки — см. здесь XMLRPC- например, сервер и клиент RPC на основе JSON, но я думаю, что использование сервера и клиента XMLRPC, которые поставляются со стандартной библиотекой Python, еще проще, поэтому, вероятно, ближе к тому, что вы ищете. Зачем вам еще Cherpy? Не стала ли производительность вдруг превзойти простоту только для этого аспекта всей архитектуры, в то время как во всех остальных случаях простота преобладала над производительностью? Это может показаться особенно противоречивым набором архитектурных решений!-)

Или вы можете перейти прямо к библиотеке сокетов и просто передать данные в своем собственном формате.

http://www.amk.ca/python/howto/sockets/

Вы можете рассмотреть Pyro, обязательно прочитайте Глава о безопасности.

Обновление: кажется, что его проще настроить, чем протокольные буферы, и может потребоваться меньше работы, если ваши требования станут более сложными в будущем (у них есть способ сделать это... :-)

Алекс прав, конечно. Но я добавлю, что в прошлом я был очень доволен травлением данных и передачей их через SSH другому процессу для распаковки. Это так просто.

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

Google, где работает Алекс, — совсем другое дело. :-)