Возникла задача - сделать синхронизацию данных между приложениями. Приложения могут быть на любом языке, данные представляют из себя и выборки из базы и бинарные мультимедийные данные.
Данные могут передаваться независимыми блоками (связанные записи из нескольких таблиц). Размер блока - несколько сотен байт. Максимальное количество блоков за один сеанс синхронизации - несколько десятков тысяч.
Пока интересует реализация этого на Питоне, но с учетом того, что это должно быть легко реализуемо и на другом языке.
Хочется сделать это портабельным, быстрым и с минимумом внешних зависимостей, поэтому на twisted я не смотрел.

Пока пробовались 3 вещи - xml-rpc(SimpleXMLRPCServer), json-rpc(SimpleJSONRPCServer взятый с activestate) и tcp поток(SocketServer.StreamRequestHandler), в который суется xml по мере генерации и инкрементально парсится на другой стороне.
Пробовалось только на выборках из базы, без бинарных данных.

Результаты неутешительные - первые 2 кандидата жутко тормозят, причем даже если все данные совать в один rpc вызов, что мне непонятно.
Поток работает в несколько десятков раз быстрее, но как работать из-за прокси непонятно (через 'connect' не везде получится).

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

Кто-нибудь может мне рассказать что я делаю не так и как это делать правильно? И что делать с бинарными данными? Или хотя бы в какую сторону копать?

Спасибо.

Я бы начал с D-Bus.

Посмотри как передаются двоичные данные (jpeg, png, swf и т.д.) по HTTP, и поступи аналогичным образом, если провайдерские фильтры HTTP действительно создают проблемы. Но ты вряд-ли сможешь застраховаться от жесткого кеширования, когда прокси будут просто игнорировать заголовки принуждающие не кешировать контент и будут поступать по своему. Возможно есть стандарты, которые позволяют передавать произвольные пакеты данных по HTTP, но я с ними не знаком, сделать велосипед не должно быть сложнее чем искать и изучать чужой API со своими ограничениями.
А вообще. С такими ограничения следует бороться другими методами.

..bw

Опиши подробнее систему и требования.
Пример вопросов, которые возникли сразу:
1. Где физически раположены приложения?
2. Какие каналы связи существуют и какие можете обеспечить?
3. Диапазон размеров передаваемой инфы в Мб (Кб)?
4. Связанность передавамой инфы?
5. Необходимость обеспечить транзакции при передаче данных?
6. Известные ограничения?
7. Аппаратные средства, на которых крутятся программы?

ЗЫ
А зачем в поток пихать тормознутый XML? Неужели нет других форматов?

ZZZ
Я бы начал с D-Bus.

Упс. Можно поподробнее? Я считал, что D-BUS имеет немного другую область применения.

Lexander
Опиши подробнее систему и требования.

Пример вопросов, которые возникли сразу:
1. Где физически раположены приложения?
Где угодно. Они могут запускаться на телефоне, наладоннике, десктопе. Это может быть и веб приложение.

2. Какие каналы связи существуют и какие можете обеспечить?
Это не корпоративное приложение, ничего обеспечивать не нужно. Соответственно каналы - от GPRS до локалки.
Основная среда работы - интернет. Как наиболее близкий пример можно привести синхронизацию контактов/todo/tasks.

3. Диапазон размеров передаваемой инфы в Мб (Кб)?
Я указал:
Данные могут передаваться независимыми блоками (связанные записи из нескольких таблиц). Размер блока - несколько сотен байт. Максимальное количество блоков за один сеанс синхронизации - несколько десятков тысяч.

4. Связанность передавамой инфы?
Вроде тоже написал.

5. Необходимость обеспечить транзакции при передаче данных?
Только в пределах одного блока, то есть практически нет.

6. Известные ограничения?
В основном то, что оба приложения могут быть запущены где угодно и должны уметь синхронизироваться.

7. Аппаратные средства, на которых крутятся программы?
см. выше.

ЗЫ
А зачем в поток пихать тормознутый XML? Неужели нет других форматов?

Только из-за того, что парсинг xml - стандартная процедура и найти парсер для любой платформы не составляет труда. Собственно из-за этого были рассмотрены и xml/json-rpc.
Производительность варианта с ленивым запихиванием xml и инкрементальным парсингом его на другом конце, кстати, вполне устраивает. Работает в десятки раз быстрее, чем
rpc варианты. Не устраивает только возня с прокси, возможно непреодолимая.

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

bw
сделать велосипед не должно быть сложнее чем искать и изучать чужой API со своими ограничениями.

Может и так. Просто в один момент я подумал, что, блин, это же классическая проблема - передать данные из одного
места в другое, должно быть классическое решение.
Посмотрел вокруг и не обнаружил такового. И не поверил, что его нет.

А вообще. С такими ограничения следует бороться другими методами.

И какими, если не секрет?

/Offtop
Отличная задача для Limbo
С питоном труднее.

Хочется сделать это портабельным, быстрым и с минимумом внешних зависимостей

Все довольно трудно.

>> А вообще. С такими ограничения следует бороться другими методами.
> И какими, если не секрет?

Дать админу сети водяры пузырь. Или по морде. Действовать по обстоятельствам в общем.

..bw

Ed
3. Диапазон размеров передаваемой инфы в Мб (Кб)?
Я указал:

По указанным данным получается, что по ГПРС нужно будет передавать пакеты мегабайт эдак в 15 за раз. Что, конечно, бред.
А вообще то я специально запросил диапазон, а не примерное значение. Ну да ладно, не хочешь, так и не надо.

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

Если не накладывается ограничение на тип сети, то я бы посмотрел в сторону централизованного управления в противовес p2p с возможностью работы и как p2p именно на этапе передачи данных для тех устройств, где это возможно. С грамотной разбивкой пакетов (на сервере). И протокол передачи данных свой бы сделал - под те типы данных, что передаются. Использовал бы сокеты.