forum.opennet.ru - "Передача данных с удаленных систем без потери данных?" (22)

"Передача данных с удаленных систем без потери данных?"

Форум Оптимизация и Промышленные системы (Увеличение наджности)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Передача данных с удаленных систем без потери данных?"	+1 +/–
Сообщение от alexkv (ok), 01-Авг-19, 17:15
Дано: -Есть условно несколько удаленных Raspberry Pi (Orange и т.д.), к каждой подключены несколько датчиков. Сами Raspberry Pi подключены к интернету различными способами - где по 3G, где по Wi-Fi где по Ethernet. Канал передачи может прерываться на определенное время. -Есть сервер с БД. Подключен постоянно к интернету. Надо: передавать данные с датчиков на сервер без потерь. Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале передачи данных эти данные в реальном времени шлются на сервер и там попадают в БД. Если канал перестал работать (пропал 3G например), то данные накапливаются на малинке. При восстановлении канала надо передать накопленные и продолжить слать в реальном времени. Подскажите пожалуйста концептуально как такое построить. Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше программировать своих велосипедов. Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое лучше сделать.
Ответить \| Правка \| Cообщить модератору

Оглавление

Концептуально - просто, достаточно простенького скрипта code ПОКА работаем , Аноним (1), 08:49 , 02-Авг-19, (1)

Кроссавчег , Аноним (-), 11:12 , 02-Авг-19, (2) –1

Кстати, да Славно навалил на ТС-а Но минус тебе все равно поставил Ибо , Andrey Mitrofanov_N0 (??), 11:15 , 02-Авг-19, (3)

Вот те на Не шалю, никого не трогаю, починяю примус и вообще,я совершенно не пон, Аноним (-), 11:29 , 02-Авг-19, (4)

Да, норм Мы тут все никого не _трогаем_ Кучи-то не трогаем, наваливаем , Andrey Mitrofanov_N0 (??), 11:36 , 02-Авг-19, (6)

gt оверквотинг удален По такой логике любые внешние задержки в сети например , ыы (?), 11:04 , 05-Авг-19, (8)

ТС просил концептуальное решение, поэтому в первом приближении полагаем линию св, Аноним (1), 14:22 , 05-Авг-19, (14)

Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому см, ыы (?), 16:11 , 05-Авг-19, (15)

И в неограниченном объеме , fantom (??), 16:31 , 05-Авг-19, (16)

Вооот Берём Реализацию выше за основу и подкладываем её же ей же в качестве пе, Andrey Mitrofanov_N0 (??), 08:16 , 06-Авг-19, (17)

gt оверквотинг удален По описанию - классическая очередь сообщений Для начала, Ann None (?), 11:30 , 02-Авг-19, (5) –1

Спасибо за совет Пошел изучать , alexkv (ok), 14:00 , 02-Авг-19, (7)

gt оверквотинг удален Одна тулза пишет данные в файл базу очередь буфер свой_в, fantom (??), 11:53 , 05-Авг-19, (9)

gt оверквотинг удален А вообще - классическая электронная почта как раз решает, fantom (??), 11:56 , 05-Авг-19, (10)

Почтовые голуби тоже Почему я не буду их использовать , alexkv (ok), 12:11 , 05-Авг-19, (11)

Это понятно Я интересовался какие именно тулзы можно использовать для решения та, alexkv (ok), 12:12 , 05-Авг-19, (12)

Хоть POST запросы посылайте в цикле пока нужный код ответа от сервера не получит, fantom (??), 12:24 , 05-Авг-19, (13)

gt оверквотинг удален Тебе хорошо подойдет smtp протокол для этого Клиенты пу, Павел Отредиез (?), 17:29 , 16-Авг-19, (18)

gt оверквотинг удален Делается элементарно Допустим у тебя raspbian с exim В, Павел Отредиез (?), 17:41 , 16-Авг-19, (19)

gt оверквотинг удален Отправка письма echo Мой текст 124 mail input 10 0 , Павел Отредиез (?), 17:47 , 16-Авг-19, (20)

БД с репликацией локально, ту же MySQL можно взять Модель данных можно придумат, Аноним (23), 17:01 , 21-Сен-20, (23)

БД На ПЛК Удачи , Брат Анон (ok), 09:25 , 19-Ноя-20, (24)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 02-Авг-19, 08:49 +/–

> Подскажите пожалуйста концептуально как такое построить.
Концептуально - просто, достаточно простенького скрипта.
ПОКА <работаем>
    ПОКА <есть_связь>
        ПЕРЕСЫЛАЕМ <данные> НА СЕРВЕР <сервер>
    ПОКА <нет_связи>
        ПИШЕМ <данные> В ФАЙЛ <аварийный_лог>
    ЕСТЬ ФАЙЛ <аварийный_лог>?
        ДА:
            ПЕРЕСЫЛАЕМ <аварийный_лог> НА СЕРВЕР <сервер>
            СТЕРЕТЬ ФАЙЛ <аварийный_лог>

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #8

2. Сообщение от Аноним (-), 02-Авг-19, 11:12 –1 +/–

Кроссавчег!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Andrey Mitrofanov_N0 (??), 02-Авг-19, 11:15 +/–

> Кроссавчег!
Кстати, да.  Славно навалил на ТС-а.
Но минус тебе все равно поставил. Ибо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от Аноним (-), 02-Авг-19, 11:29 +/–

>> Кроссавчег!
> Кстати, да.  Славно навалил на ТС-а.
> Но минус тебе все равно поставил. Ибо.
Вот те на!
Не шалю, никого не трогаю, починяю примус и вообще,
я совершенно не понимаю причин такого резкого обращения со мной.
И ещё считаю своим долгом предупредить, что аноним - древний и неприкосновенный аккаунт.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6

5. Сообщение от Ann None (?), 02-Авг-19, 11:30 –1 +/–

>[оверквотинг удален]
> Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале
> передачи данных эти данные в реальном времени шлются на сервер и
> там попадают в БД. Если канал перестал работать (пропал 3G например),
> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные
> и продолжить слать в реальном времени.
> Подскажите пожалуйста концептуально как такое построить.
> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше
> программировать своих велосипедов.
> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое
> лучше сделать.
По описанию - классическая очередь сообщений. Для начала можно посмотреть на RabbitMQ.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

6. Сообщение от Andrey Mitrofanov_N0 (??), 02-Авг-19, 11:36 +/–

> Не шалю, никого не трогаю,
> я совершенно не понимаю
>древний и неприкосновенный
> аккаунт.
Да, норм.  Мы тут все никого не _трогаем_.  Кучи-то не трогаем, наваливаем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от alexkv (ok), 02-Авг-19, 14:00 +/–

> По описанию - классическая очередь сообщений. Для начала можно посмотреть на RabbitMQ.
Спасибо за совет. Пошел изучать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от ыы (?), 05-Авг-19, 11:04 +/–

>[оверквотинг удален]
>     ПОКА <нет_связи>
>         ПИШЕМ <данные> В ФАЙЛ
> <аварийный_лог>
>     ЕСТЬ ФАЙЛ <аварийный_лог>?
>         ДА:
>
> ПЕРЕСЫЛАЕМ <аварийный_лог> НА СЕРВЕР <сервер>
>
> СТЕРЕТЬ ФАЙЛ <аварийный_лог>
>
По такой логике любые внешние задержки (в сети например) будут тормозить прием локальных данных с датчиков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #14

9. Сообщение от fantom (??), 05-Авг-19, 11:53 +/–

>[оверквотинг удален]
> Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале
> передачи данных эти данные в реальном времени шлются на сервер и
> там попадают в БД. Если канал перестал работать (пропал 3G например),
> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные
> и продолжить слать в реальном времени.
> Подскажите пожалуйста концептуально как такое построить.
> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше
> программировать своих велосипедов.
> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое
> лучше сделать.
Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант
Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта данные не считаются переданными.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #12

10. Сообщение от fantom (??), 05-Авг-19, 11:56 +/–

>[оверквотинг удален]
>> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные
>> и продолжить слать в реальном времени.
>> Подскажите пожалуйста концептуально как такое построить.
>> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше
>> программировать своих велосипедов.
>> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое
>> лучше сделать.
> Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант
> Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта
> данные не считаются переданными.
А вообще - классическая электронная почта как раз решает поставленную задачу :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от alexkv (ok), 05-Авг-19, 12:11 +/–

> А вообще - классическая электронная почта как раз решает поставленную задачу :)
Почтовые голуби тоже.
Почему я не буду их использовать????

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

12. Сообщение от alexkv (ok), 05-Авг-19, 12:12 +/–

> Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант
> Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта
> данные не считаются переданными.
Это понятно.
Я интересовался какие именно тулзы можно использовать для решения такой задачи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от fantom (??), 05-Авг-19, 12:24 +/–

>> Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант
>> Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта
>> данные не считаются переданными.
> Это понятно.
> Я интересовался какие именно тулзы можно использовать для решения такой задачи.
Хоть POST запросы посылайте в цикле пока нужный код ответа от сервера не получите.
Хоть SNMP set.
Хоть INSERT в базу пока база Ok не ответит.
Хоть в subversion тупо по крону коммитить.
Тут что вам ближе тем и пользуйтесь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

14. Сообщение от Аноним (1), 05-Авг-19, 14:22 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15

15. Сообщение от ыы (?), 05-Авг-19, 16:11 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16

16. Сообщение от fantom (??), 05-Авг-19, 16:31 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от Andrey Mitrofanov_N0 (??), 06-Авг-19, 08:16 +/–

>>> прямой, передаваемые данные - шарообразными и неупругими...
>> Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу...
> И в неограниченном объеме :)
Вооот!  Берём Реализацию выше за основу и подкладываем её же ей же в качестве первого приближения реализации линии связи.  Увеличиваем вложенность до тех пор, пока задача не сойдётся.
Профит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

18. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:29 +/–

>[оверквотинг удален]
> Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале
> передачи данных эти данные в реальном времени шлются на сервер и
> там попадают в БД. Если канал перестал работать (пропал 3G например),
> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные
> и продолжить слать в реальном времени.
> Подскажите пожалуйста концептуально как такое построить.
> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше
> программировать своих велосипедов.
> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое
> лучше сделать.
Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp сервера, которые копят очередь и отсылают на центральный сервер. На центральном сервере транспортом пайп можно письма парсить и вносить в БД.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

19. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:41 +/–

>[оверквотинг удален]
>> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные
>> и продолжить слать в реальном времени.
>> Подскажите пожалуйста концептуально как такое построить.
>> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше
>> программировать своих велосипедов.
>> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое
>> лучше сделать.
> Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp
> сервера, которые копят очередь и отсылают на центральный сервер. На центральном
> сервере транспортом пайп можно письма парсить и вносить в БД.
Делается элементарно. Допустим у тебя raspbian с exim. Все шлют на input@10.0.0.1 согласно политике повторов и по cron прогоном очереди. На сервере в ложишь /home/input/.forward с содержимым "| input.sh ". Каждое входящее письмо попадает в экземпляр input.sh на stdin. Все конфигурации exim дефолтные ничего не нужно придумывать. При наличии связи экзим доставляет немедленно, при отсутствии копит очередь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #20

20. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:47 +/–

>[оверквотинг удален]
>>> лучше сделать.
>> Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp
>> сервера, которые копят очередь и отсылают на центральный сервер. На центральном
>> сервере транспортом пайп можно письма парсить и вносить в БД.
> Делается элементарно. Допустим у тебя raspbian с exim. Все шлют на input@10.0.0.1
> согласно политике повторов и по cron прогоном очереди. На сервере в
> ложишь /home/input/.forward с содержимым "| input.sh ". Каждое входящее письмо попадает
> в экземпляр input.sh на stdin. Все конфигурации exim дефолтные ничего не
> нужно придумывать. При наличии связи экзим доставляет немедленно, при отсутствии копит
> очередь.
Отправка письма echo "Мой текст" | mail input@10.0.0.1

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

23. Сообщение от Аноним (23), 21-Сен-20, 17:01 +/–

БД с репликацией локально, ту же MySQL можно взять.
Модель данных можно придумать такую, чтобы это был кольцевой буфер и не нужно было специально удалять старые данные, чтобы они перезаписывались при нормальной работе.
replace into data_table ( KEY, TS, VALUE) values ( количество секунд от начала суток, время, значение)
На том конце выбираете по TS и что-то делаете.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

24. Сообщение от Брат Анон (ok), 19-Ноя-20, 09:25 +/–

> БД с репликацией локально, ту же MySQL можно взять.
> Модель данных можно придумать такую, чтобы это был кольцевой буфер и не
> нужно было специально удалять старые данные, чтобы они перезаписывались при нормальной
> работе.
БД? На ПЛК? Удачи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 02-Авг-19, 08:49	+/–
> Подскажите пожалуйста концептуально как такое построить. Концептуально - просто, достаточно простенького скрипта. ПОКА <работаем> ПОКА <есть_связь> ПЕРЕСЫЛАЕМ <данные> НА СЕРВЕР <сервер> ПОКА <нет_связи> ПИШЕМ <данные> В ФАЙЛ <аварийный_лог> ЕСТЬ ФАЙЛ <аварийный_лог>? ДА: ПЕРЕСЫЛАЕМ <аварийный_лог> НА СЕРВЕР <сервер> СТЕРЕТЬ ФАЙЛ <аварийный_лог>
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2, #8

2. Сообщение от Аноним (-), 02-Авг-19, 11:12	–1 +/–
Кроссавчег!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Andrey Mitrofanov_N0 (??), 02-Авг-19, 11:15	+/–
> Кроссавчег! Кстати, да. Славно навалил на ТС-а. Но минус тебе все равно поставил. Ибо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от Аноним (-), 02-Авг-19, 11:29	+/–
>> Кроссавчег! > Кстати, да. Славно навалил на ТС-а. > Но минус тебе все равно поставил. Ибо. Вот те на! Не шалю, никого не трогаю, починяю примус и вообще, я совершенно не понимаю причин такого резкого обращения со мной. И ещё считаю своим долгом предупредить, что аноним - древний и неприкосновенный аккаунт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #6

5. Сообщение от Ann None (?), 02-Авг-19, 11:30	–1 +/–
>[оверквотинг удален] > Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале > передачи данных эти данные в реальном времени шлются на сервер и > там попадают в БД. Если канал перестал работать (пропал 3G например), > то данные накапливаются на малинке. При восстановлении канала надо передать накопленные > и продолжить слать в реальном времени. > Подскажите пожалуйста концептуально как такое построить. > Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше > программировать своих велосипедов. > Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое > лучше сделать. По описанию - классическая очередь сообщений. Для начала можно посмотреть на RabbitMQ.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7

6. Сообщение от Andrey Mitrofanov_N0 (??), 02-Авг-19, 11:36	+/–
> Не шалю, никого не трогаю, > я совершенно не понимаю >древний и неприкосновенный > аккаунт. Да, норм. Мы тут все никого не _трогаем_. Кучи-то не трогаем, наваливаем.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

7. Сообщение от alexkv (ok), 02-Авг-19, 14:00	+/–
> По описанию - классическая очередь сообщений. Для начала можно посмотреть на RabbitMQ. Спасибо за совет. Пошел изучать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

8. Сообщение от ыы (?), 05-Авг-19, 11:04	+/–
>[оверквотинг удален] > ПОКА <нет_связи> > ПИШЕМ <данные> В ФАЙЛ > <аварийный_лог> > ЕСТЬ ФАЙЛ <аварийный_лог>? > ДА: > > ПЕРЕСЫЛАЕМ <аварийный_лог> НА СЕРВЕР <сервер> > > СТЕРЕТЬ ФАЙЛ <аварийный_лог> > По такой логике любые внешние задержки (в сети например) будут тормозить прием локальных данных с датчиков.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #14

9. Сообщение от fantom (??), 05-Авг-19, 11:53	+/–
>[оверквотинг удален] > Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале > передачи данных эти данные в реальном времени шлются на сервер и > там попадают в БД. Если канал перестал работать (пропал 3G например), > то данные накапливаются на малинке. При восстановлении канала надо передать накопленные > и продолжить слать в реальном времени. > Подскажите пожалуйста концептуально как такое построить. > Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше > программировать своих велосипедов. > Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое > лучше сделать. Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта данные не считаются переданными.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10, #12

10. Сообщение от fantom (??), 05-Авг-19, 11:56	+/–
>[оверквотинг удален] >> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные >> и продолжить слать в реальном времени. >> Подскажите пожалуйста концептуально как такое построить. >> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше >> программировать своих велосипедов. >> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое >> лучше сделать. > Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант > Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта > данные не считаются переданными. А вообще - классическая электронная почта как раз решает поставленную задачу :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от alexkv (ok), 05-Авг-19, 12:11	+/–
> А вообще - классическая электронная почта как раз решает поставленную задачу :) Почтовые голуби тоже. Почему я не буду их использовать????
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

12. Сообщение от alexkv (ok), 05-Авг-19, 12:12	+/–
> Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант > Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта > данные не считаются переданными. Это понятно. Я интересовался какие именно тулзы можно использовать для решения такой задачи.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от fantom (??), 05-Авг-19, 12:24	+/–
>> Одна тулза пишет данные в файл/базу/очередь/буфер/свой_вариант >> Вторая- вынимает и пропихивает дальше по принципу транзакций, пока транзакция не закрыта >> данные не считаются переданными. > Это понятно. > Я интересовался какие именно тулзы можно использовать для решения такой задачи. Хоть POST запросы посылайте в цикле пока нужный код ответа от сервера не получите. Хоть SNMP set. Хоть INSERT в базу пока база Ok не ответит. Хоть в subversion тупо по крону коммитить. Тут что вам ближе тем и пользуйтесь.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

14. Сообщение от Аноним (1), 05-Авг-19, 14:22	+/–
> По такой логике любые внешние задержки (в сети например) будут тормозить прием > локальных данных с датчиков. ТС просил концептуальное решение, поэтому в первом приближении полагаем линию связи - прямой, передаваемые данные - шарообразными и неупругими...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #15

15. Сообщение от ыы (?), 05-Авг-19, 16:11	+/–
>> По такой логике любые внешние задержки (в сети например) будут тормозить прием >> локальных данных с датчиков. > ТС просил концептуальное решение, поэтому в первом приближении полагаем линию связи - > прямой, передаваемые данные - шарообразными и неупругими... Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #16

16. Сообщение от fantom (??), 05-Авг-19, 16:31	+/–
>>> По такой логике любые внешние задержки (в сети например) будут тормозить прием >>> локальных данных с датчиков. >> ТС просил концептуальное решение, поэтому в первом приближении полагаем линию связи - >> прямой, передаваемые данные - шарообразными и неупругими... > Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу... И в неограниченном объеме :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от Andrey Mitrofanov_N0 (??), 06-Авг-19, 08:16	+/–
>>> прямой, передаваемые данные - шарообразными и неупругими... >> Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу... > И в неограниченном объеме :) Вооот! Берём Реализацию выше за основу и подкладываем её же ей же в качестве первого приближения реализации линии связи. Увеличиваем вложенность до тех пор, пока задача не сойдётся. Профит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16

18. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:29	+/–
>[оверквотинг удален] > Т.е. скрипт на малине собирает данные с датчиков постоянно. При работающем канале > передачи данных эти данные в реальном времени шлются на сервер и > там попадают в БД. Если канал перестал работать (пропал 3G например), > то данные накапливаются на малинке. При восстановлении канала надо передать накопленные > и продолжить слать в реальном времени. > Подскажите пожалуйста концептуально как такое построить. > Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше > программировать своих велосипедов. > Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое > лучше сделать. Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp сервера, которые копят очередь и отсылают на центральный сервер. На центральном сервере транспортом пайп можно письма парсить и вносить в БД.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #19

19. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:41	+/–
>[оверквотинг удален] >> то данные накапливаются на малинке. При восстановлении канала надо передать накопленные >> и продолжить слать в реальном времени. >> Подскажите пожалуйста концептуально как такое построить. >> Хотелось бы максимально использовать системные возможности Linux и свободного ПО, поменьше >> программировать своих велосипедов. >> Чет я потерялся, не понимаю с использованием чего (технологии, протоколы, ПО) такое >> лучше сделать. > Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp > сервера, которые копят очередь и отсылают на центральный сервер. На центральном > сервере транспортом пайп можно письма парсить и вносить в БД. Делается элементарно. Допустим у тебя raspbian с exim. Все шлют на input@10.0.0.1 согласно политике повторов и по cron прогоном очереди. На сервере в ложишь /home/input/.forward с содержимым "\| input.sh ". Каждое входящее письмо попадает в экземпляр input.sh на stdin. Все конфигурации exim дефолтные ничего не нужно придумывать. При наличии связи экзим доставляет немедленно, при отсутствии копит очередь.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #20

20. Сообщение от Павел Отредиез (?), 16-Авг-19, 17:47	+/–
>[оверквотинг удален] >>> лучше сделать. >> Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp >> сервера, которые копят очередь и отсылают на центральный сервер. На центральном >> сервере транспортом пайп можно письма парсить и вносить в БД. > Делается элементарно. Допустим у тебя raspbian с exim. Все шлют на input@10.0.0.1 > согласно политике повторов и по cron прогоном очереди. На сервере в > ложишь /home/input/.forward с содержимым "\| input.sh ". Каждое входящее письмо попадает > в экземпляр input.sh на stdin. Все конфигурации exim дефолтные ничего не > нужно придумывать. При наличии связи экзим доставляет немедленно, при отсутствии копит > очередь. Отправка письма echo "Мой текст" \| mail input@10.0.0.1
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

23. Сообщение от Аноним (23), 21-Сен-20, 17:01	+/–
БД с репликацией локально, ту же MySQL можно взять. Модель данных можно придумать такую, чтобы это был кольцевой буфер и не нужно было специально удалять старые данные, чтобы они перезаписывались при нормальной работе. replace into data_table ( KEY, TS, VALUE) values ( количество секунд от начала суток, время, значение) На том конце выбираете по TS и что-то делаете.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #24

24. Сообщение от Брат Анон (ok), 19-Ноя-20, 09:25	+/–
> БД с репликацией локально, ту же MySQL можно взять. > Модель данных можно придумать такую, чтобы это был кольцевой буфер и не > нужно было специально удалять старые данные, чтобы они перезаписывались при нормальной > работе. БД? На ПЛК? Удачи.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23