Есть com-port, с которого льется поток ~< 3000 characters/second.
Этот поток необходимо записывать в БД, находящуюся удаленно.
В этой связи решения два:
1) читать поток через cat, и затем передавать по TCP, что-то типо: cat /dev... | nc ..
На приемной стороне, организовать TCP сервер, на Python, например. откуда уже писать в БД.
Либо
2) писать поток в файл, каждую секунду, который затем передавать по FTP, с последующей обработкой на сервере, после приема.
В первом случае придется предусмотреть ситуации, когда БД вдруг офлайн, писать в файлы, которые затем пересылать.
Однако задержки нет, поток пришел -- сразу пишем.
Что предпочесть, может есть какие проблемы с передачей по FTP, менее стабильно../etc?
Заранее благодарен!
UPD:
Всем спасибо за дискуссию!
Выбрал такую связку: с COM_port'a лью данные в файлы (nc > filename), проверяю на той же машине на вилидность (python). Если оки -> отправляю по scp, если дошло - удаляю (scp .. && rm ..);
Я бы для начала разбил задачу на независимые куски.
С порта льется поток, который надо сохранить. Обязательно. Пусть он сохраняется в файлы с именем %Y-%m-%d_%H, например. Четко и без вариантов. Данные всегда сохранены.
Данные должны попасть в базу. Нужен сервис, который определяет, есть ли файлы с именем меньше текущего часа, и пытается их отправить. Если это проходит удачно - удаляет. Варианты исполнения такого функционала выбираем на вкус и цвет.
Я бы сначала локально лил в файл, чтобы на случай пропадания связи проблем не было.
Потом можно локально уже распарсить поток до структурного состояния, а дальше уже интереснее.
Вариант 1: прямое соединение по ssh с пробросом портов (тогда БД наружу не торчит) и лить запросами в БД
Вариант 2: небольшой веб REST сервис поднять на получателе, куда скидывать хоть через wget пакеты, которые будут обрабатываться и литься в БД.
выбор варианта сильно зависит от компа, на который приходит ком-порт. Если там достаточно ресурсов, парсить локально и лить на удаленный сервер. В этом случае больше контроля. Если будет пропадание сети, то просто будет локально копиться и ждать отправки.
Вариант с веб-сервисом - профдеформация, всю черновую работу в этом случае отдаём стороннему софту, на плечи серверного приложения остаётся только обработать пришедшие данные. Можно и TCP реализовать, не проблема.
как критично не потерять данные или можно пропустить часть данных (нужен ли надежный промежуточный буфер)
как оперативно данные должны поступать в БД (можно ли повешать на крон отсылку накопленных в буфере данных)
и сколько времени/человеческих ресурсов можно выделить для решения задачи
секьюрности проекта (если это не внутренний сервер, в небольшой конторе где не может быть атак - то еще можно использовать FTP, иначе - категорически нет).
И это будет очень большой разбег. Буквально от 10 минут до 10 дней работы
Ваш вопрос состоит в том, что вы просите нас оценить ваши особенности задачи, которые мы оценить не можем, не зная о требованиях к задаче.
2) писать поток в файл, каждую секунду, который затем передавать по FTP, с последующей обработкой на сервере, после приема.
А зачем каждую секунду писать, пишите поминутные файлы,
если 1 character = 1 byte, то минута это 180Kb примерно, хороший размер для передачи по FTP.
Раз в 5 минут, например, запускаем синхронизацию локального каталога с FTP сервера ~ 1Mb.
И тут же - файлы, например старше суток, - удаляем.
Обнаружив новые файлы, сервис на сервере, неспешно заливает их в базу - 5 минут у него есть.
Я бы:
1. Парсил прямо на машине, принимающей поток с COM-порта
2. Сливал в БД прямо с этой же машины, через SQL: "insert into туда-то values такие-то". В случае вылезшего exception (нет связности с БД, БД упала и т.д.), распарсенные значения можно было бы залоггировать локально
Простой
