Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
На АРМе работает приложение, собирающее и обрабатывающее записи от прибора.
Данных от прибора достаточно много, на на приборе имеется сжатие данных.
Примерная оценка траффика (самая пессиместичная): 204 кб/сек.
Реально, за счет сжатия данных, траффик будет значительно меньше.
Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину.
Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей.
Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.
Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.
Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи.
ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
На мой взгляд, работа через специализированный протокол удобнее и гибче.
Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
Коллега аргументирует свой критерий выбора FTP, тем, что на приборе все равно будут формироваться файлы.
Эти файлы записываются на flash карту (как путь последнего выбора, в случае длительной потери связи с АРМ-ом).
Здравствуйте, AlexGin, Вы писали:
AG>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей.
А почему бы тогда не использовать UDP и уже поверх него продумывать систему надежной доставки? Все равно будете изобретать все с нуля.
AG>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей. AG>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи. AG>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
FTP умеет докачивать. И, в принципе, умеет работать со структурой файла типа "запись" или передавать данные блоками.
AG>На мой взгляд, работа через специализированный протокол удобнее и гибче. AG>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
Любой протокол, который умеет работать над TCP уже решил для себя эти проблемы, которые Вы будете решать по новой.
Здравствуйте, AlexGin, Вы писали:
AG>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей. AG>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи. AG>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
AG>На мой взгляд, работа через специализированный протокол удобнее и гибче.
UDP. прибор тупо шлет пакеты с данные на адрес получателя. есть связь — нету связи, не важно.
TCP. прибор шлет пакет с данными. а потом ждет подтверждение успешного приема от получателя. нет подтверждения — перепосылает тот же пакет.
AG>Коллега аргументирует свой критерий выбора FTP, тем, что на приборе все равно будут формироваться файлы.
ни какой связи с файлами тут нет, от слова вообще.
AG>Эти файлы записываются на flash карту (как путь последнего выбора, в случае длительной потери связи с АРМ-ом).
AG>А какие ваши предложения, уважаемые коллеги?
я так понимаю — рассматривается связь в одну сторону. syslog.
я бы лил данные "как есть" непрерывным потоком по UDP. соответственно со стороны получателя типа syslog сервер, слушает получаемые данные, и делает из них файлы по своему усмотрению: из принятого потока данные одного датчика в один файл, от того датчика — с нарезкой поминутно по файлам в другой. А эта группа датчиков пишется сразу в БД.
Плюс к этому предусмотреть со стороны прибора возможность отдать данные за прошлый период. Например за время пропадания связи или перезапуска принимающей службы.
Вот тут уже можно со стороны прибора сделать FTP сервер.
Для управления пользоваться отдельным потоком, отдельным протоколом, по tcp.
Здравствуйте, AlexGin, Вы писали:
AG>А какие ваши предложения, уважаемые коллеги?
в FTP есть докачка, но сам протокол древний и кривой.
на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
в твоем случае HTTP подходит. я бы даже взял WebDAV (раз уж FTP в принципе годится), тут можно будет вообще как диск примонтировать в некоторых ОС.
для HTTP/WebDAV навалом готовых клиентов, масса готовых реализаций сервера под любые нужды, в том числе и для микроконтроллеров.
Здравствуйте, LuciferSaratov, Вы писали:
LS>в FTP есть докачка, но сам протокол древний и кривой.
Чем он кривой? Со своей основной задачей — передачей файлов справляется вполне успешно и надежно.
LS>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов. Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, AlexGin, Вы писали:
AG>>А какие ваши предложения, уважаемые коллеги?
LS>в FTP есть докачка, но сам протокол древний и кривой.
Вот именно это, меня и смущает...
LS>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
Вопрос насчет HTTP — ИМХО здесь его применять не следует.
Так как, гипертекстовых — да и вообще текстовых — данных в моей задаче нет.
LS>в твоем случае HTTP подходит.
Каким же образом?
я бы даже взял WebDAV (раз уж FTP в принципе годится), тут можно будет вообще как диск примонтировать в некоторых ОС.
У нас приложение для Windows, посему данный аспект неактуален. LS>для HTTP/WebDAV навалом готовых клиентов, масса готовых реализаций сервера под любые нужды, в том числе и для микроконтроллеров.
Спасибо! Покапаем в этом направлении.
Здравствуйте, Nikolay_Ch, Вы писали:
LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP. N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов.
В том смысле, чтобы приложение АРМ-а работало с прибором (как клиентское приложение) через HTTP?
Есть также вариант — работа в среде веб-броузера. Это также интересный вариант. Пока даже не задумывались над этим...
N_C>Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
+100500
Вот я также об этом думал! Ведь тех функций, что в HTTP, мне здесь совсем и не надо!
P.S. Работа с прибором через веб-броузер не актуальна.
Все данные от прибора, перед визуализацией пользователю, нуждаются в больших доп-расчетах (в т.ч. БПФ),
которые должны выполняться быстро — в скрипте это не сделать.
Посему, считаю реально рассматривать варианты протоколов
a) Низкоуровневые — TCP или UDP;
b) Высокоуровневые — FTP или HTTP.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, LuciferSaratov, Вы писали:
LS>>в FTP есть докачка, но сам протокол древний и кривой. N_C>Чем он кривой? Со своей основной задачей — передачей файлов справляется вполне успешно и надежно.
два соединения, невозможность работы за натом без пассивного режима, отсутствие шифрования (в http стандартным образом подключаеся TLS).
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов. Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
http намного менее кривой и значительно более продуманный.
масса готовых клиентов сэкономит много времени при отладке.
Здравствуйте, AlexGin, Вы писали:
AG>Вопрос насчет HTTP — ИМХО здесь его применять не следует. AG>Так как, гипертекстовых — да и вообще текстовых — данных в моей задаче нет.
по http прекрасно передаются любые данные, докачка тоже предусмотрена и массой клиентов поддерживается.
LS>>для HTTP/WebDAV навалом готовых клиентов, масса готовых реализаций сервера под любые нужды, в том числе и для микроконтроллеров. AG>Спасибо! Покапаем в этом направлении.
webdav это протокол поверх http, аналог ftp.
при наличии http-сервера реализовать read-only webdav несложно.
Здравствуйте, LuciferSaratov, Вы писали:
LS>два соединения, невозможность работы за натом без пассивного режима, отсутствие шифрования (в http стандартным образом подключаеся TLS).
Ну, во-первых не два, а столько, сколько качаете + 1. Во-вторых — в HTTP вообще нет возможности выбрать, как сервер открывает сокет активно/пассивно — он там всегда пассивен. Ну и в-третьих с FTP тоже можно работать поверх SSL.
LS>http намного менее кривой и значительно более продуманный. масса готовых клиентов сэкономит много времени при отладке.
Кривость FTP, простите, не увидел. А для передачи одного файла, повторюсь, использовать HTTP — это перебор.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, AlexGin, Вы писали:
AG>>Вопрос насчет HTTP — ИМХО здесь его применять не следует. AG>>Так как, гипертекстовых — да и вообще текстовых — данных в моей задаче нет.
LS>по http прекрасно передаются любые данные, докачка тоже предусмотрена и массой клиентов поддерживается.
Спасибо, уважаемый LuciferSaratov!
Вполне возможно, что на этом варианте и остановим выбор.
LS>>>для HTTP/WebDAV навалом готовых клиентов, масса готовых реализаций сервера под любые нужды, в том числе и для микроконтроллеров. AG>>Спасибо! Покапаем в этом направлении.
LS>webdav это протокол поверх http, аналог ftp. LS>при наличии http-сервера реализовать read-only webdav несложно.
Я даже не знаю — есть ли поддержка webdav для Visual Studio (на MFC, или на .NET) — поэтому тут пока ничего не ясно.
Здравствуйте, AlexGin, Вы писали:
AG>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину. AG>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей. AG>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.
Посмотрите на zeromq: http://zeromq.org/
AG>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.
А кто их стирать оттуда будет, эти файлы?
AG>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи. AG>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться.
AG>На мой взгляд, работа через специализированный протокол удобнее и гибче. AG>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, AlexGin, Вы писали:
AG>>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину. AG>>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей. AG>>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.
Pzz>Посмотрите на zeromq: http://zeromq.org/
Спасибо, поищу это всё под Visual Studio (именно она у нас применяется).
Еще такой вопрос — как поддержать это дело на стороне прибора?
AG>>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.
Pzz>А кто их стирать оттуда будет, эти файлы?
ПО прибора будет удалять файлы, после того, как они окажутся невостребованными (по типу кольцевого буфера).
AG>>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи. AG>>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
Pzz>Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться.
Уважаемый Pzz, насчёт двух соединений — можно как-то поподробнее? Мне пока видится только одно (HTTP или TCP соединение)...
AG>>На мой взгляд, работа через специализированный протокол удобнее и гибче. AG>>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
Pzz>С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями.
Возможно.
Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО);
а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.
Здравствуйте, AlexGin, Вы писали:
Pzz>>Посмотрите на zeromq: http://zeromq.org/ AG>Спасибо, поищу это всё под Visual Studio (именно она у нас применяется). AG>Еще такой вопрос — как поддержать это дело на стороне прибора?
Есть какие-то "легкие" реализации. Специально для "приборов". Посмотрите по ссылкам с сайта.
Pzz>>А кто их стирать оттуда будет, эти файлы? AG>ПО прибора будет удалять файлы, после того, как они окажутся невостребованными (по типу кольцевого буфера).
Не боитесь флешку до дыр протереть?
Pzz>>Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться. AG>Уважаемый Pzz, насчёт двух соединений — можно как-то поподробнее? Мне пока видится только одно (HTTP или TCP соединение)...
FTP использует два TCP-соединения: одно для команд, а другое — для данных.
Pzz>>С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями. AG>Возможно. AG>Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО); AG>а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.
Я к тому, что в самодельном протоколе должны быть предусмотрены пути расзвития. Или, как минимум, проверка совместимости версий.
Здравствуйте, AlexGin, Вы писали:
AG>Доброго времени суток, уважаемые коллеги!
AG>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
АРМ это по русски читается или по английски? Что означает аббревиатура?
Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
Насколько быстро надо выгружать данные на АРМ?
АРМ это ваша железка и вы можете развернуть там любой софт?
Что за ОС используется на приборе и АРМ?
Нужна ли транзакционность передачи данных на АРМ?
В общем виде вы хотите просто передать все собранные данные на АРМ? AG>А какие ваши предложения, уважаемые коллеги?
От протобуф, буст сериалайз до ASN.1+BER и SQL. AG>P.S. Благодарю за любые предложения!
Да нечего предлагать. Вообще ничего не понятно.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexGin, Вы писали:
AG>>Доброго времени суток, уважаемые коллеги!
AG>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ. K>АРМ это по русски читается или по английски? Что означает аббревиатура?
Автоматизированное Рабочее Место
K>Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
В данном случае запись — это единица информации, характеризующая набор отсчетов от датчиков прибора.
Это нейкий законченный набор отсчетов, над которым АРМ выполняет определенные математические расчеты.
K>Насколько быстро надо выгружать данные на АРМ? K>АРМ это ваша железка и вы можете развернуть там любой софт?
Нет — АРМ это обычный комп (под Виндой).
Данные от прибора на этот комп поступают в real-time. Насчет трафика, я упоминал в стартовом посте.
K>Что за ОС используется на приборе и АРМ?
На АРМ — Windows 7 32/64 (SP1) и выше.
На приборе — как таковая ОС отсутствует.
Там совершенно специализированная система, на базе микроконтроллеров Atmel.
Собственно говоря, все что на приборе — это наша проприетарная разработка.
K>Нужна ли транзакционность передачи данных на АРМ?
Нет, это не финансовые данные, и не управление атомной станцией.
K>В общем виде вы хотите просто передать все собранные данные на АРМ?
Да, именно так. Конечно, контроль за целостностью данных должен быть, но каких-либо жестких требований тут нет.
AG>>А какие ваши предложения, уважаемые коллеги? K>От протобуф, буст сериалайз до ASN.1+BER и SQL.
Протобуф — это что за зверь?
Насчет буста — подумаю. Пока мне этот вариант не представляется более предпочтительным, нежели WinInet.
Так как для разработки применяем Visual Studio — то тут критерии выбора MFC или .NET.
MS SQL сервер у нас применяется — только на уровне БД АРМ. Для прибора связь с СУБД не актуальна.
AG>>P.S. Благодарю за любые предложения! K>Да нечего предлагать. Вообще ничего не понятно.
Сорри, если описал ситуацию немного в нашей терминологии.
Здравствуйте, AlexGin, Вы писали:
AG>Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО); AG>а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.
Про свой протокол сразу забудьте и все. Вы убьете кучу ресурсов на его поддержку, следующие разработчики, которым достанется непонятное пятилапое чудище будут вас материть.
Как верное сказали используете готовые протоколы, для которых уже написаны клиенты и можно спокойно отлаживать, либо использовать готовые компоненты, плюс нет проблем с документацией и use — cases.
То что протокол древний возможно наоборот хорошо — много готовых компонентов, глюки пофиксены, грабли известны.
Здравствуйте, steep8, Вы писали:
S>Здравствуйте, AlexGin, Вы писали:
AG>>Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО); AG>>а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.
S>Про свой протокол сразу забудьте и все. Вы убьете кучу ресурсов на его поддержку, следующие разработчики, которым достанется непонятное пятилапое чудище будут вас материть.
Т.е. — предлагается не мастерить очередной "велосипед" на базе TCP, а использовать FTP либо HTTP? Пожалуй, это вполне логично.
Насчет "чудища" — понятно, что это не есть хорошо, но это делается не от хорошей жизни
Если бы с той стороны канала, где имеется прибор, был бы Windows (да даже Linux) — проблем и вопросов бы не было!
Тогда бери FTP или HTTP — и вперед!
S>Как верное сказали используете готовые протоколы, для которых уже написаны клиенты и можно спокойно отлаживать, либо использовать готовые компоненты, плюс нет проблем с документацией и use — cases. S>То что протокол древний возможно наоборот хорошо — много готовых компонентов, глюки пофиксены, грабли известны.
Как я уже указывал, на стороне "железки" (прибора) стандартной ОС нет.
То есть, там работает своё собственное ПО (на уровне прошивки в микросхему ПЗУ).
Если найдутся исходники (на C или C++) для протоколов FTP либо HTTP — то их применение и будет, ИМХО, самым правильным выбором.
Здравствуйте, AlexGin, Вы писали:
AG>Доброго времени суток, уважаемые коллеги!
AG>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ. AG>На АРМе работает приложение, собирающее и обрабатывающее записи от прибора. AG>Данных от прибора достаточно много, на на приборе имеется сжатие данных. AG>Примерная оценка траффика (самая пессиместичная): 204 кб/сек. AG>Реально, за счет сжатия данных, траффик будет значительно меньше.
в сторону modbus посмотреть не пробовали?
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Ну, во-первых не два, а столько, сколько качаете + 1. Во-вторых — в HTTP вообще нет возможности выбрать, как сервер открывает сокет активно/пассивно — он там всегда пассивен. Ну и в-третьих с FTP тоже можно работать поверх SSL.
Ещё
Замечательно наблюдать семейство best practices вокруг того, кто как понимает "недоговорённости" в протоколе FTP. Смена одной либы на другую может дать катастрофический эффект.
Опять же, имена файлов — некоторые либы позволяют использовать хоть в UTF-8 с нацсимволами, а другие ни шагу далее ASCII 7bit, при этом формально оба правы — т.к. никто не отклоняется от RFC.
При большом количестве мелких файлов команда LIST может "залипать" — в результате отвал по таймауту.
