>[оверквотинг удален]
>     ПОКА <нет_связи>
>         ПИШЕМ <данные> В ФАЙЛ
> <аварийный_лог>
>     ЕСТЬ ФАЙЛ <аварийный_лог>?
>         ДА:
>            
> ПЕРЕСЫЛАЕМ <аварийный_лог> НА СЕРВЕР <сервер>
>            
> СТЕРЕТЬ ФАЙЛ <аварийный_лог>
>

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

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

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

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

Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу...

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

И в неограниченном объеме :)

>>> прямой, передаваемые данные - шарообразными и неупругими...
>> Причем линия связи передает данные мгновенно, вопреки всем реалиям и здравому смыслу...
> И в неограниченном объеме :)

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

Профит.

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

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

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

Спасибо за совет. Пошел изучать.

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

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

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

А вообще - классическая электронная почта как раз решает поставленную задачу :)

> А вообще - классическая электронная почта как раз решает поставленную задачу :)

Почтовые голуби тоже.
Почему я не буду их использовать????

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

Это понятно.
Я интересовался какие именно тулзы можно использовать для решения такой задачи.

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

Хоть POST запросы посылайте в цикле пока нужный код ответа от сервера не получите.
Хоть SNMP set.
Хоть INSERT в базу пока база Ok не ответит.
Хоть в subversion тупо по крону коммитить.
Тут что вам ближе тем и пользуйтесь.

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

Тебе хорошо подойдет smtp протокол для этого. Клиенты пусть имеют локальные smtp сервера, которые копят очередь и отсылают на центральный сервер. На центральном сервере транспортом пайп можно письма парсить и вносить в БД.

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

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

>[оверквотинг удален]
>>> лучше сделать.
>> Тебе хорошо подойдет 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

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

replace into data_table ( KEY, TS, VALUE) values ( количество секунд от начала суток, время, значение)

На том конце выбираете по TS и что-то делаете.

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

БД? На ПЛК? Удачи.