Russian Qt Forum

Изменения в БД магазина доложны анализироваться на удалённом компьютере. Для этого на удалённом компьютере создаётся аналогичная база, куда будут передаваться изменения (в виде запросов) каждые 2-10 минут для синхронизации и последующего анализа.

Основная цель темы - обеспечить самую быструю и надёжную передачу данных (запросов) на удалённый компьютер.

Вопросы:
1) как лучше передавать запросы между БД магазина и удалённым компьютером? Ответ: Почитал про сокеты, потом про QNetworkAccessManager (http://qt.nokia.com/doc/4.5/qnetworkaccessmanager.html), вроде бы подходят, а что лучше (быстрее, надёжнее)?
2) как передавать данные? Нашёл такую вещь как QByteArray (http://qt.nokia.com/doc/4.5/qbytearray.html), тоже вроде бы подходит.

upd: удалённый компьютер, на котором анализируются данные находится от магазина (ов) на расстоянии от нескольких километров до двух тысяч километров.

Недавно занимался похожей темой, посмотри в сторону SOAP довольно токи удобная весчь. и у КуТе классы для работы с ним есть  http://doc.trolltech.com/solutions/3/qtsoap/qtsoap-overview.html.

ecspertiza!
похоже, то, что надо. Спасибо большое :)

Ice ?

Ice использует бинарный протокол передачи данный, и это действительно айс(уж куда пошустрее будет XML в SOAP).
Но не айс то, что технология распространяется под двойной лицензией: GNU GPL или коммерческой. Покупать возможности нет, а вот закрыть код надо.
Хотя программа будет использоваться фактически внутри фирмы. Вот тут то возникают вопросы... по поводу закрытия кода. Можно ли?

только вот незадача то:
мне же надо передать всего ничего - одну строчку(запрос). Правда в случае разрыва соединения, когда оно восстановится придется передавать десятки, возможно тысячи строчек. Хотя это не меняет сути темы.

Может все-таки QTcpSocket + QDataStream ???

Если чесно я пока не знаю что ты выбрал SOAP или Ice или что то ещё, но могу сказать про SOAP то что ты в неё можешь передавать не строчку запроса а данные из таблицы которые необходимо синхронизировать и генерить запрос на лету при приёме данных, Soap имеет замечательную особенность у него данные либо дошли либо нет. А в клиентской части пишешь грамотный парсинг и в общем то всё, там уже будет всё равно сколько строчек пришло.

Небольшое непонимание лицензии GPL. Если ты пишешь для своей организации и не собираешься продавать приложение кому-либо другому, то ты ничего не нарушаешь. Правда в случае Ice, у тебя структура системы должна измениться =)
Насчёт гарантии доставки, я пока не понял, как Ice себя ведёт в случае разрыва связи... т.е. как её грамотно восстановить =)
http://www.zeroc.com/faq/connectionClosureCallback.html

>>Правда в случае Ice, у тебя структура системы должна измениться =)
а можно по-подробнее, пожалуйста. Как это она должна измениться?

Я конечно не спец по синхронизациям БД. Но этот вопрос изучал, и кое-что делал. У меня возникли вопросы: как Вы намереваетесь обрабатывать ошибочные ситуации? Например, обрыв связи во время передачи или отключение интернета на длительное время, а также, возможное, дублирование записей (насколько я помню, это называется коллизией) и т.д. и т.п. Вообщем как будет обеспечиваться надёжность?

какая БД используется??

Подобные вопросы возникали и у меня. Только вот проект заморозился.
Планировалось использовать Mysql.

может стоит задуматся о нормальной СУБД с поддержкой репликаций...

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

посмотри google protobuf. оно, конечно, далеко от совершенства, но по возможностям сильно обходит soap

да,да, мы уже говорили об protobuf, тогда они еще назывались, вроде бы google protocols

http://wm-help.net/articles/article/28.06.20063898-0.html

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

Но там использовалась БД Firebird так что если процесс обновления не завершился удачно - то транзакция просто не подтверждалась, это позволяло избежать вставки двойных записей и т.д.

Кроме того робот мог еще и сам выслать письмецо с запросом каких-нибудь данных, на которое уже мог отреагировать клиент.

Почта использовалась чтобы не реализовывать самим транспорт и если письмо не дошло получать соответствующее сообщение от почтового сервера...

Поддерживаю на все 100!!! Все уже придумано и отлажено! Кроме того, ведение бинарных журналов очень сильно пригодится при восстановлении данных после краха базы!

Я тоже делал таким же образом, но база другая. Синхронизация БД между двумя офисами. По началу делал через почту, а потом поднял VPN и написал скрипты. Синхронизировалась раз в час.
По поводу репликации MySql - тоже пробовал. Тут встаёт другой вопрос, как часто теряется связь? Настроил и оставил посмотреть, как будет происходить (один компьтер с БД периодически выключался). Через какой-то период (не засекал), базы перестали синхронизироваться и нужно было ручками лезть восстанавливать. Мне это не очень понравилось. Если это будет часто происходить - накладно.

доставка в и накатка журнала процедура менее ресурсоемка... т.е. нагрузка на удаленные сервер меньше...

Вы, наверное, более опытны в этом вопросе. Да и я по ушёл в сторону (в требованиях раз в 2-10 минут).
А как быть с установкой блокировки на таблицы (если я не ошибаюсь), если синхронизация будет падать достаточно часто? Хотя бы для пользователей основной базы - будут неудобства.
Но говорить вообще, мне понравилась такая опция - огромная масса проблем решается.

при использовании репликации эти проблемы будет решать сервер.... при накатывании скриптов в принципе тоже...
к тому же блокировка только на запись... и чем чаще реплицируем тем меньше времени будет блокировка...