Для промышленной автоматизации нужно использовать Modbus TCP, стандартный порт 502. Новички очень любят использовать FTP, уж не знаю почему он им так нравится, но всегда всё заканчивается большим фейлом. Вот уж где можно с уверенностью говорить об ужасной реализации. Не лучше дело обстоит и с самопальными протоколами. Отечественная промышленность выпустила не мало подобного мусора.
В контроллерах традиционно стоят какие-нибудь атмелы, прекрасно известно на что они способны и чем программируется (Atmel Studio, FastAVR). Так сделайте поддержку Modbus TCP, будет не контроллер, а конфета. Пусть он даже жёстко прошит или работает только со своими датчиками.
Всё на самом деле очень просто, данные идут от датчиков в контроллер. Далее они могут использоваться или другим контроллером или уйти в ПК. В том же ПК уже есть огромное количество готового софта, в том числе и бесплатного типа OpenSCADA, и весь этот софт практически всегда поддерживает Modbus TCP.
А это множество возможностей, архивация в базу данных, интерактивное отображение графических интерфейсов в клиенте и даже в вебе, телеметрия, управление, графики, таблицы, отчёты и многое другое. Новички в автоматизации не понимают таких простых вещей. В итоге каждый создаёт свой протокол, в том же FTP внутри всё равно свой формат данных. Причём сам FTP будет глючить нещадно, так как промышленная сеть рассчитана на безотказную работу годами.
Вообще говоря rsdn это не совсем тот форум, где стоит обсуждать подобные вопросы. Существуют форумы по промышленной автоматизации. Если человек, например, всю жизнь ваял веб, но никогда не видел контроллеров, то опыт будет ему подсказывать использовать совершенно неуместные решения.
Здравствуйте, AlexGin, Вы писали:
AG>А какие ваши предложения, уважаемые коллеги?
в FTP есть докачка, но сам протокол древний и кривой.
на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
в твоем случае HTTP подходит. я бы даже взял WebDAV (раз уж FTP в принципе годится), тут можно будет вообще как диск примонтировать в некоторых ОС.
для HTTP/WebDAV навалом готовых клиентов, масса готовых реализаций сервера под любые нужды, в том числе и для микроконтроллеров.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, LuciferSaratov, Вы писали:
LS>>в FTP есть докачка, но сам протокол древний и кривой. N_C>Чем он кривой? Со своей основной задачей — передачей файлов справляется вполне успешно и надежно.
два соединения, невозможность работы за натом без пассивного режима, отсутствие шифрования (в http стандартным образом подключаеся TLS).
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов. Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
http намного менее кривой и значительно более продуманный.
масса готовых клиентов сэкономит много времени при отладке.
Здравствуйте, AlexGin, Вы писали:
AG>Доброго времени суток, уважаемые коллеги!
AG>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
АРМ это по русски читается или по английски? Что означает аббревиатура?
Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
Насколько быстро надо выгружать данные на АРМ?
АРМ это ваша железка и вы можете развернуть там любой софт?
Что за ОС используется на приборе и АРМ?
Нужна ли транзакционность передачи данных на АРМ?
В общем виде вы хотите просто передать все собранные данные на АРМ? AG>А какие ваши предложения, уважаемые коллеги?
От протобуф, буст сериалайз до ASN.1+BER и SQL. AG>P.S. Благодарю за любые предложения!
Да нечего предлагать. Вообще ничего не понятно.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Ну, во-первых не два, а столько, сколько качаете + 1. Во-вторых — в HTTP вообще нет возможности выбрать, как сервер открывает сокет активно/пассивно — он там всегда пассивен. Ну и в-третьих с FTP тоже можно работать поверх SSL.
Ещё
Замечательно наблюдать семейство best practices вокруг того, кто как понимает "недоговорённости" в протоколе FTP. Смена одной либы на другую может дать катастрофический эффект.
Опять же, имена файлов — некоторые либы позволяют использовать хоть в UTF-8 с нацсимволами, а другие ни шагу далее ASCII 7bit, при этом формально оба правы — т.к. никто не отклоняется от RFC.
При большом количестве мелких файлов команда LIST может "залипать" — в результате отвал по таймауту.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, Sinclair, Вы писали:
S>>Фичи протокола FTP заведомо избыточнее для задачи топикстартера, чем фичи HTTP. N_C>ИМХО фич у FTP поменьше будет, чем у HTTP. Протокол HTTP гораздо сложнее и в описании и в реализации, чем FTP. N_C>А зачем все эти хедеры? Поддержка соединений, куки и прочее?
В отличие от FTP, почти всё это необязательно.
А парсить чанки? А разбирать кодировку передачи, кодирование содержимого? А LIST парсить обычно и не нужно, если знаешь, что и где брать.
Всё это уже встроено в клиентах. А на сервере вы не обязаны задуряться с разнообразием кодировок — вам достаточно реализовать одну. N_C>Что, реализаций HTTP кривых нет??? Я удивлен.
Реализаций HTTP в десятки раз больше, потому что FTP малопопулярен. Шансы найти некривую реализацию — гораздо больше.
N_C>Вы уж определитесь, что Вы будете делать — реализовывать протокол или его реализацию в сторонних библиотеках. Если первое — написать клиента FTP проще.
Вы, похоже, не поняли задачу. Основная её часть — написание сервера. Сервер HTTP, который умеет отдавать ответы ровно на один запрос, можно написать за вечер с нуля на голых сокетах. Сервер FTP в этом смысле гораздо сложнее — коробочные реализации не умеют ничего, кроме как отдавать файлы. Т.е. нужно писать код, который формирует файлы; нужно как-то договариваться с клиентом о способе детектирования кодировок; нужно писать код, который чистит файлы после того, как они не нужны. HTTP-сервер может отдавать данные прямо из памяти, а все negotiations встроены прямо в протокол.
Клиент работает на PC, там естественно надо брать коробочную реализацию.
В данном случае, вообще, лучше брать конечно же промышленный стандарт — рядом в топике посоветовали, какой именно.
А вообще, ситуаций, в которых FTP был бы хоть чем то оправдан, в жизни практически не бывает. Единственное, что он умеет лучше, чем HTTP — это прямое копирование между серверами. Для клиент-сервера он малопригоден.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>Для промышленной автоматизации нужно использовать Modbus TCP, стандартный порт 502.
Все верно, добавлю еще, что существует понятие Industrial Ethernet, там перечислены основные протоколы и стандарты.
Здравствуйте, AlexGin, Вы писали:
AG>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину. AG>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей. AG>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.
Посмотрите на zeromq: http://zeromq.org/
AG>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.
А кто их стирать оттуда будет, эти файлы?
AG>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи. AG>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...
Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться.
AG>На мой взгляд, работа через специализированный протокол удобнее и гибче. AG>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями.
Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
На АРМе работает приложение, собирающее и обрабатывающее записи от прибора.
Данных от прибора достаточно много, на на приборе имеется сжатие данных.
Примерная оценка траффика (самая пессиместичная): 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.
Здравствуйте, 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.
Здравствуйте, 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) — поэтому тут пока ничего не ясно.
Здравствуйте, 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>а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.
Я к тому, что в самодельном протоколе должны быть предусмотрены пути расзвития. Или, как минимум, проверка совместимости версий.
Здравствуйте, 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 посмотреть не пробовали?
Здравствуйте, Mr.Delphist, Вы писали: MD>Замечательно наблюдать семейство best practices вокруг того, кто как понимает "недоговорённости" в протоколе FTP. Смена одной либы на другую может дать катастрофический эффект.
Не используйте те либы, которые или не полностью реализуют протокол, или реализуют его малораспространенные фичи.
MD>Опять же, имена файлов — некоторые либы позволяют использовать хоть в UTF-8 с нацсимволами, а другие ни шагу далее ASCII 7bit, при этом формально оба правы — т.к. никто не отклоняется от RFC.
Протоколом не разрешено использование UTF и что? Да, это накладывает определенные ограничения, но к автору топика они явно не относятся.
MD>При большом количестве мелких файлов команда LIST может "залипать" — в результате отвал по таймауту.
Какое имеет отношение к протоколу кривые его реализации??? Я не вижу ничего такого, что бы заставляло команду LIST отваливаться по таймауту.
Здравствуйте, AlexGin, Вы писали:
AG>Как я уже указывал, на стороне "железки" (прибора) стандартной ОС нет. AG>То есть, там работает своё собственное ПО (на уровне прошивки в микросхему ПЗУ). AG>Если найдутся исходники (на C или C++) для протоколов FTP либо HTTP — то их применение и будет, ИМХО, самым правильным выбором.
Выше предлагали modbus, присоединюсь. Если не хватит скорости/длинны линии то посмотрите profibus. Стандартны в промышленной автоматизации, много драйверов/клиентов/серверов.
Здравствуйте, AlexGin, Вы писали:
AG>Если бы с той стороны канала, где имеется прибор, был бы Windows (да даже Linux) — проблем и вопросов бы не было! AG>Тогда бери FTP или HTTP — и вперед!
Вовсе необязательно, http (точнее TCP/IP + HTTP) сервера с некоторыми ограничениями вполне реализуемы даже на AVR контроллерах.
S>Выше предлагали modbus, присоединюсь. Если не хватит скорости/длинны линии то посмотрите profibus. Стандартны в промышленной автоматизации, много драйверов/клиентов/серверов.
По-моему, Modbus тут не совсем подходит, т.к. в нем предполагается работа по схеме запрос-ответ (и соотв. master-slave устройства, master — обычно как раз компьютер) и жесткая привязка данных к определенным регистрам.
Еще хотелось бы уточнений, допускаются ли разрывы в потоке данных (т.е. можно ли проигнорировать неполученные данные) или обязательно надо собирать всю последовательность, пусть и будет при этом отставание от устройства.
Рекомендую посмотреть, как устроен протокол Motion JPEG (MJPEG), вроде очень похоже на рассматриваемый случай — после подключения клиента сервер выполняет последовательную отправку кадров изображения (тут будут блоки данных), можно взять это за основу и дополнительно в каждом кадре передавать номер последовательности, которую клиент будет указывать при необходимости после восстановления связи (это опять же получится свой протокол поверх HTTP). На сервере при этом организуется кольцевой буфер, длина выбирается исходя из максимального времени неработоспособности клиента (если решено не пропускать данные от устройства).
Здравствуйте, trkeast, Вы писали:
T>в сторону modbus посмотреть не пробовали?
ИМХО, modbus не для такого придуман. Был когда-то такой телефон Nokia N9 в котором все приложения снизу общались по d-bus шине. Всё шло гладко, но вот однажды по шине начали гонять данные больших размеров вроде смс/ммс, календарей, ответов на SPARQL запросы что в конечном счёте привело к высокой нагрузке на d-bus сервис и факапом с производительностью. Реальная история реального архитектурного фейла в масштабе платформы.
Здравствуйте, AlexGin, Вы писали:
AG>>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ. K>>АРМ это по русски читается или по английски? Что означает аббревиатура? AG>Автоматизированное Рабочее Место
Как же любите вы всё по ГОСТу описывать. AG>Данные от прибора на этот комп поступают в real-time. Насчет трафика, я упоминал в стартовом посте.
Я бы особо не парился и сделал так. На девайсе сделал циклический буфер разумного размера, а отправку сделал по UDP(если размер записи позволяет) + CRC32/16 по вкусу. Естественно, каждый UDP пакет имеет смысл ретрансмиттить 3-5 раз. Поскольку вы можете себе позволить потерять данные, то UDP будет вполне себе простым и лёгким решением. Сложность тут будет в написании алгоритма скедулера чтобы данные от каждого датчика гарантированно ушли на АРМ в некотором временном окне.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, trkeast, Вы писали:
T>>в сторону modbus посмотреть не пробовали? K>ИМХО, modbus не для такого придуман. Был когда-то такой телефон Nokia N9 в котором все приложения снизу общались по d-bus шине. Всё шло гладко, но вот однажды по шине начали гонять данные больших размеров вроде смс/ммс, календарей, ответов на SPARQL запросы что в конечном счёте привело к высокой нагрузке на d-bus сервис и факапом с производительностью. Реальная история реального архитектурного фейла в масштабе платформы.
это конечно так, но тем не менее как-то в промышленных контроллерах/приборах
modbus встречается очень часто, к тому же протокол весьма прост и позволяет
работать как работать с файлами, так и расширять функциональность
с производительностью надо пробовать, может хватит, а может и нет
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, trkeast, Вы писали: T>>в сторону modbus посмотреть не пробовали? K>ИМХО, modbus не для такого придуман. Был когда-то такой телефон Nokia N9 в котором все приложения снизу общались по d-bus шине.
Modbus придуман именно для промышленных сетей, и он не имеет никакого отношения к D-Bus. Просто для справки пока фантазия не увела слишком далеко в сторону несовместимых велосипедов.
Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):
адрес ведомого (подчинённого) устройства | код функции | данные | блок обнаружения ошибок
где адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы; код функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство; данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции, также в поле данных может быть детализация кода функции; блок обнаружения ошибок — контрольная сумма для проверки отсутствия ошибок в кадре.
Чтобы понять почему не нужно колхозить следует поработать в области промышленной автоматизации. Причём не теоретически, а практически создавая промышленные сети. В Modbus TCP уже используется TCP/IP, его понимает огромное количество контроллеров и SCADA систем.
А теперь представьте некий производитель наколхозил свой протокол обмена. И вот хоть тресни, он не подходит ни к одному устройству. Если это ПЛК, тогда программисту нужно искать зависимые от контроллера библиотеки TCP/IP, терять огромное количество времени на расшифровку колхозного протокола.
Тоже самое происходит и с ПК, только там используются возможности софтлоджик какой-нибудь скады, или опять свой программный колхоз. Да проще и дешевле выкинуть подобный контроллер и купить нормальный ПЛК с поддержкой Modbus TCP.
И я могу сказать, чем это всё закончится. Самопальная колхозная сеть развалится на части и никто не будет её чинить. А заказчик со временем или станет умнее и уйдёт на стандартные решения, или будет ходить и всем рассказывать какая автоматика ужасная вещь и что лучше с ней не связываться.
Вообще такие приборы это низший ценовой сегмент, только так их можно хоть как-то оправдать по сравнению с ПЛК, которые в любое время можно перепрошить по TCP/IP на что угодно. Если они при этом ещё и не поддерживают стандартов, тогда дело совсем уже плохо.
Здравствуйте, AlexGin, Вы писали:
AG>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину. AG>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей.
У вас прибор — умное устройство?
Смотрите в сторону IEC61850. Это PITA, но это стандартный протокол на основе MMS, то есть ASN.1/BER.
Можно еще в сторону DNP3 какого посмотреть.
Изобретать свой протокол не советую. Пожалеете трижды. Как бы не казалось, что ни один стандартный не подходит, лучше все же применить один из них.
Здравствуйте, AlexGin, Вы писали:
AG>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ. AG>На АРМе работает приложение, собирающее и обрабатывающее записи от прибора. AG>Данных от прибора достаточно много, на на приборе имеется сжатие данных. AG>Примерная оценка траффика (самая пессиместичная): 204 кб/сек. AG>Реально, за счет сжатия данных, траффик будет значительно меньше.
А транспорт какой? Везде Ethernet, или что-то другое? Какая загрузка сети, доля потерь?
Вообще при разработке любого протокола надо начать с выбора одной из вершин треугольника:
1) важнее надёжная и быстрая доставка, за счёт возможного повышения нагрузки на сеть и участников переговоров
2) важнее надёжная и спокойная доставка, торможение допустимо, буферов достаточно, сеть и участников не перегружать
3) важнее быстрая и ровная доставка, за счёт возможности некоторых потерь
в реальности тут будут по каждому фактору не да/нет/вкл/выкл, а количественные пределы.
AG>На мой взгляд, работа через специализированный протокол удобнее и гибче. AG>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.
У нас в примерно аналогичной ситуации был выбор между UUCP и Redis.
Оба обеспечивают доставку на вторую сторону данных произвольного объёма с достаточной надёжностью.
Остановились на Redis из-за встроенных возможностей просрочивания записей. Но у нас было гарантированно синхронизированное время на двух сторонах.
Здравствуйте, Nikolay_Ch, Вы писали: N_C>Не используйте те либы, которые или не полностью реализуют протокол, или реализуют его малораспространенные фичи.
Фичи протокола FTP заведомо избыточнее для задачи топикстартера, чем фичи HTTP.
Зачем ему все эти активно/пассивные моды? Зачем парсинг текстового результата команды LIST?
N_C>Какое имеет отношение к протоколу кривые его реализации??? Я не вижу ничего такого, что бы заставляло команду LIST отваливаться по таймауту.
Самое прямое. Работать-то будет не протокол, а реализация.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexGin, Вы писали: LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP. AG>Вопрос насчет HTTP — ИМХО здесь его применять не следует. AG>Так как, гипертекстовых — да и вообще текстовых — данных в моей задаче нет.
Типичная мисконцепция. В HTTP нет ничего про гипертекст, кроме названия.
Зато есть graceful degradation и negotiation. Что позволяет вам начать с примитивного сервера в 100 строчек кода, а по мере появления нужды расширять сервер плюшками, не сильно беспокоясь о синхронизации версий клиента и сервера.
Простейшая вещь: сжатие. Для начала вы можете его не делать совсем. Когда отладите протокол и решите, что на вашем канале всё сильно узко, прикрутите анализ заголовка Accept-Encoding и будете слать gzip тем клиентам, которые его умеют парсить.
При этом вы всё ещё сможете отлаживаться чем угодно — хоть браузером, хоть wget-ом, хоть фиддлером.
И такого — везде. Докачка — есть; возможность проверять наличие новых данных (aka conditional get) — есть; и ещё очень много всего, о чём вы ещё только можете задуматься.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Фичи протокола FTP заведомо избыточнее для задачи топикстартера, чем фичи HTTP.
ИМХО фич у FTP поменьше будет, чем у HTTP. Протокол HTTP гораздо сложнее и в описании и в реализации, чем FTP.
S>Зачем ему все эти активно/пассивные моды? Зачем парсинг текстового результата команды LIST?
А зачем все эти хедеры? Поддержка соединений, куки и прочее? А парсить чанки? А разбирать кодировку передачи, кодирование содержимого? А LIST парсить обычно и не нужно, если знаешь, что и где брать.
N_C>>Какое имеет отношение к протоколу кривые его реализации??? Я не вижу ничего такого, что бы заставляло команду LIST отваливаться по таймауту. S>Самое прямое. Работать-то будет не протокол, а реализация.
Что, реализаций HTTP кривых нет??? Я удивлен.
Вы уж определитесь, что Вы будете делать — реализовывать протокол или его реализацию в сторонних библиотеках. Если первое — написать клиента FTP проще. Если второе — то о каких сложностях протокола Вы говорите? Реализация в обоих случаях скроет все сложности. Но по фичам — HTTP это протокол заведомо с большими возможностями. Но нужны ли они топикстартеру — еще вопрос. Я бы в его случае вообще использовал протокол TFTP.
Здравствуйте, tyomchick, Вы писали:
T>Если есть интерес продавать прибор не только под свой верх, то лучше не изобретать велосипеды, а использовать стандартный протокол.
T>МЭК 60870-5-101 T>МЭК 60870-5-104
T>Если реализуете, то любая SCADA без выкрутасов зацепит ваш девайс.
Это большой протокол с многочисленными граблями и не до конца расписаными примерами использования. Большой риск написать самопальную реализацию, которую надо будет дописывать к каждому новому устройству. Для тех у кого нет большого опыта разработки протоколов — я бы не рекомендовал начинать с него.
Вот скажем http или modbus/tcp значительно проще в плане доступных компонентов и примеров использования.
Здравствуйте, AlexGin, Вы писали:
AG>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей. AG>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.
Поздравляю, Вы изобрели фид с биржи
Если формат записей уже известен- можно упаковывать по много записей в один пакет, добавлять к нему заголовок с порядковым номером и CRC, и слать юникастом или мультикастом. Попутно сохраняя в кольцевой буфер. На слушателе организовать проверку номера принимаемых пакетов и "склейку" в упорядоченный файл. При обнаружении пропущенного или битого пакета- запрашивать его по TCP с возвратом по TCP, либо по UDP — слать запрос на повторную отсылку пакета (хранимого в достаточного размера кольцевом буфере) в составе риалтаймового фида.
AG>Коллега аргументирует свой критерий выбора FTP, тем, что на приборе все равно будут формироваться файлы. AG>Эти файлы записываются на flash карту (как путь последнего выбора, в случае длительной потери связи с АРМ-ом).
Очевидно, слушатель может слать хартбиты с номером последнего принятого пакета- в таком случае девайс при переполнении кольцевого буфера сможет его "голову" выгружать в файл на флеш карте. Но если хартбиты приходят вовремя и память не переполняется, не изнашивать понапрасну флеш.
