Варианты обмена пакетами

[Игорь Столяров]

Привет всем !
Есть вопрос по поиску оптимальной идеи для построения обмена данными.

ЗАДАЧА:
Есть два приложения, которые должны обмениваться пакетами данных (файл).
Расположение и платформа (ОС) приложений - произвольные, и их много.
Пользователь у нас не ботан и вообще не обладает техническими ресурсами.
В идеале:
- нажал кнопку в 1-ом приложении данные выгрузились.
- нажал кнопку в 2-ом приложении данные загрузились.

РАБОЧИЙ ВАРИАНТ:
- В приложении пользователь единоразово создаёт настройку обмена и ключ (GUID).
- Передаёт ключ (GUID) во второе приложение - и там тоже создаётся настройка обмена.

- При обмене создаётся файл, [шифруется ключом,] формируется имя файла (как HASH от ключа)
и под этим именем пакет (файл) записывается в публичный FTP раздел.
- Второе приложение формирует имя файла (как HASH от ключа), проверяет публичный FTP раздел
на наличие файла, забирает его [и расшифровывает ключом]. Удаляет файл в FTP разделе.

Вроде бы все получается.
Кто-нибудь пробовал реализовывать такие процедуры обмена ?
Может быть есть идеи проще и лучше ? Заранее спасибо !

[finsoftrz]

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

[Игорь Столяров]

На самом деле формат самого файла не не особо важен - главное, что бы программы его понимали.
Здесь вопрос скорее по самой процедуре обмена - это всё то, что у Вас уместилось в слове "копируем".
Хорошо когда копируем рядом с компьютером. А если копируем в другой город или страну ?

[finsoftrz]

Какая разница, вас же в интернете не забанили.

[finsoftrz]

Вообще, обмен у меня по ftp/http, кроме случаев локального использования, конечно. Заморочек с шифрацией и гуидом нет, так как нет смысла. У клиента либо свой оплаченный хостинг, либо я предоставляю на своём. А дальше по потребности. Иногда, например, бывает, файл выкладывает я на фтп с каким-то переменным именем, а следом запускается скрипт на php, которому в качестве параметра передаётся имя файла (или его детерминатор). Если взаимодействие со своими веб или мобильными приложениями, то в их сторону в формате sqlite, что исключает процесс загрузки, а в обратную сторону текстовые файлы, так как с ними просто работать из клариона.

[Игорь Столяров]

Какая разница, вас же в интернете не забанили.

Не забанили - так и надо этим воспользоваться.
Давайте пожалуйста на время забудем про "мне не надо" и "у клиента есть [сервер]".
Учебная задача с выходом из зоны комфорта - это лучший фитнесса мозга.

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

Нужно нажать кнопку и отправить прайс-лист в торговую точку "A".
В торговой точке "A" нажать кнопку и загрузить этот прайс-лист (или получить сообщение, что его нет).
И это должно работать в любом городе. Вот я о чём ...

[finsoftrz]

Для удаленной кассы я делал через ftp обмен. Принцип тот же, что и у автономок. На кассе ничего нажимать не надо. Там автоматический опрос обновления прайса.
Для более оперативной работы используется решение на базе ip драйвера, которое показало себя надежным и эффективным. Торговая точка должна продавать, в этом случае продажи напрямую пишутся в базу данных учетной системы при наличии доступа через интернет. Требуется выделенный белый ip адрес на компьютере с учетной системой ("сервере").

[Игорь Столяров]

Я вот тоже склоняюсь к использованию FTP обмена как самого простого и стабильного.
Что касается IP драйвера - то его нужно устанавливать и настраивать. Не подходит.

[finsoftrz]

Ip сервер надо установить только на основном компьютере. Настраивать там, можно сказать, ничего не требуется. Плюс в том, что на сервере сразу отражаются продажи. Можно все оперативно контролировать. Из разных точек можно видеть остатки товаров в других точках. Если на точках не только продажи, то геммороя с организацией обмена документами несравнимо меньше, чем при оффлайн репликациях.

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

[RaFaeL]

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

Нужно нажать кнопку и отправить прайс-лист в торговую точку "A".
В торговой точке "A" нажать кнопку и загрузить этот прайс-лист (или получить сообщение, что его нет).
И это должно работать в любом городе. Вот я о чём ...

Через электронную почту делается на раз-два, какие фтп?
Формируете письма с определенной темой, в которых аттач с определенным именем. Программа периодически проверяет ящик, загружает почту, достает аттач и далее делаете что хотите. Ящиков можно сделать где угодно каких угодно неограниченно. У нас так репликация баз работает, например, а это посложнее, чем прайс-лист

[finsoftrz]

Как я понимаю, такое использование электронной почты тянется ещё с до интернетовских времен. Читал про подобную оффлайн репликацию оракловских баз данных в Супермаге. Сейчас особого кайфа в этом нет, кроме наличия старых отлаженных решений.

[Игорь Столяров]

У нас есть банковское приложение, которое мы сделали 15 лет назад и оно до сих пор работает.
Рассылает плановые показатели отчётности в филиалы через SMTP. Все просто и понятно.
Главный и огромный плюс - это асинхронность. Я могу не заморачиваться включен и работает сервер
в филиале или нет. Мне главное, что бы Яндекс работал ...

Основная тоска здесь - это многоходовка с получением почтового сообщения с сервера, так как POP3
доживает последние годы, а IMAP не так тривиален. Потом разбор MIME пакета с выделением файла.
Тоже не весело. Плюс постоянно СПАМ фильтры, что-то блокируют и т.д.

[finsoftrz]

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

[Игорь Столяров]

Здесь же речь шла о репликации данных между двумя приложениями.

Абсолютно верно. Рассылки - это когда передаётся информация, что-то вроде:
"Здрасьте ! У нас завоз свежего пива !" (на самом деле нет).

А у нас полноценная репликация справочников построенная на почтовой системе:
- В Центре формируются пакеты с выборкой справочников из БД и отправляются в филиалы.
- В филиалах пакет принимается, заносится в БД и отправляется квитанция о приёме.
- В центре квитанция принимается и мы видим в каких филиалах какая версия справочников.
- Ведётся протоколирование. Всё это работает само и автономно много лет (даже я уже не помню как именно !)

[finsoftrz]

У меня в одном проекте делается нечто аналогичное, только без почты. Нафига слать каждому отдельную копию справочников? Выкладываем один раз на ftp, а проверять и забирать можно http запросами.