Обмен данными с удаленными клиентами

Question

[digdream]

Имеется задача организовать ПО для сбора информации — будет некоторое количество клиентов, каждый со своей БД (порядка 30 шт). на клиентах набивается эта самая база, которая частями должна сливаться в общую базу в центральное хранилище. клиенты находятся в полях со слабеньким непостоянным доступом в интернет посредством мобильной сети.
какие можно применить способы обмена информацией? обратной связи тоже хотелось бы, чтобы и сервер в случае чего мог послать дамп клиенту.
пока видится только ftp c именованием файлов согласно номеру клиента и постфиксами в виде номер пакета/случайного значения

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

Comments

[frostosx]

Какое оборудование у клиентов, у сервера?
Операционная система у клиентов, у сервера?
В какие форматы возможен экспорт данных?

[digdream]

win32, импорт и экспорт в любом виде, так как софт будет писаться на delphi+embedded mysql

Answer 1

[KEKSOV]

Для Ваших условий подходит CouchDB. Репликация/синхронизация уже реализована. Эта БД доступна на многих платформах, простой и понятный API

Comments

[KEKSOV]

Кстати, не углядел тег Delphi в топике. Это дает ответы на многие вопросы. Если интересно, то под D7, т.е. без выкрутасов, написал библиотеку для работы с CouchDB, если интересно, то могу поделиться исходниками.

Answer 2

[lubezniy]

Ещё вариант способа обмена информацией — E-Mail. Клиент подготовил набитые данные, приаттачил к письму, подключился к сети и выслал, а сервер принял, обработал и отправил обратно сообщение, что такие-то записи получены и обработаны, больше их слать не надо. В таком раскладе серверу не нужен постоянный ip-адрес в Интернете — достаточно завести виртуальный хостинг с нужным количеством почтовых ящиков или вообще какие-нибудь Mail.ru. Недостатки — возможная задержка писем антиспамом и не ахти какая безопасность.

Comments

[digdream]

да, такую штуку я уже делал на базе the bat!
с ftp мне кажется понадежнее будет

[lubezniy]

По FTP возможна коллизия, когда сервер пытается скачать и обработать недозакачанный клиентом (из-за совпадения по времени или разрыва неустойчивого соединения) файл. С E-Mail, как я понимаю, дело проще обстоит: пока сообщение полностью не передастся, получателю оно не пойдёт.

[digdream]

тут есть варианты обхода, например: закачиваем файл с одним расширением например file01.up, по окончании загрузки переименовываем файл в нормальный вид file01.rar.
либо — файл семафор, при наличии которого сервер не будет пытаться скачивать содержимое, пока он есть. — тут тоже возможны косяки в большей мере чем в первом случае

[lubezniy]

Согласен.
А в качестве значений ключевых полей в таких распределённых БД, наверное, менее проблематично использовать GUID.