Python и взаимодействие приложений по сети.

multiprocessing?

http://a-iv.ru/pyart/mysocket-I.pdf

если будет интересно, пишите в почту.

веб-приложение, которое чуть-чуть управляет серверами.

почитаю чуть внимательнее, но первое впечатление, что Ваша реализация похожа Pyro.

Не исключено - хорошие мысли приходят в разные головы независимо, а про Pyro я не знаю;-)

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

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

No-no-no, это название пакета из стандартной библиотеки, который может помочь в твоей проблеме.

Предоставляет обертки над сокетами, для организации транспорта, обеспечивающего передачу примитивных питонячьих объектов.

Такие обертки пишутся руками, занимают строк 10-20. Это все что он умеет?;-)

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

Рекомендую twisted. Для удаленного запуска кода можно использовать компонент Perspective Broker. Ну и данные просто по TCP (или какой вы протокол планируете использовать) можно гонять, конечно.

Он случаем человеческие шреды не реализует???

Он случаем человеческие шреды не реализует???

Из документации:

multiprocessing — Process-based “threading” interface

Но человеческими их можно назвать с большой натяжкой. Специфика IPC все-таки присутствует в достаточном количестве.

Он предоставляет threading-like API только с созданием множественных процессов. Ну, в том числе (но не только!), чтобы обойти GIL.

И да, если нет опыта работы с twisted, вполне вероятно, что проще / быстрее будет действительно использовать multiprocessing, а не разбираться в twisted.

Не, тогда не то, но все равно гляну. Спасибо;-)

А почему просто не взять xmlrpc?

Можно просто взять Pyro, но в этом случае слушатель Pyro будет везде и на каждый запрос будет инициироваться новое соединение. Не знаю как текущая реализация, но оно еще не умело ставить запросы в очередь. Ее надо прикручивать руками. Есть замечательная штука - D-Bus. Вот хотелось бы аналог и по сети :)

ZeroMQ вас не устроит?

>на каждый запрос будет инициироваться новое соединение.
и?

Еще вариант взять какой-нибудь mq и не знать бед.

спасибо, похоже то что нужно.

потому и обратился за советом к знатокам :)

берешь примитивные методы интеграции - SOAP, JSON-RPC и крутишь вертишь как хочешь.

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

>Есть замечательная штука - D-Bus. Вот хотелось бы аналог и по сети :)

а с каких это пор дбас у нас по сети не умеет работать?

> спасибо, похоже то что нужно.

*задумчиво* и на что только питоноводы готовы идти лишь бы не учить нормальных языков

*задумчиво*

Иди думай дальше, толстячок.