Здравствуйте, 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 встречается очень часто, к тому же протокол весьма прост и позволяет
работать как работать с файлами, так и расширять функциональность
с производительностью надо пробовать, может хватит, а может и нет
Для промышленной автоматизации нужно использовать Modbus TCP, стандартный порт 502. Новички очень любят использовать FTP, уж не знаю почему он им так нравится, но всегда всё заканчивается большим фейлом. Вот уж где можно с уверенностью говорить об ужасной реализации. Не лучше дело обстоит и с самопальными протоколами. Отечественная промышленность выпустила не мало подобного мусора.
В контроллерах традиционно стоят какие-нибудь атмелы, прекрасно известно на что они способны и чем программируется (Atmel Studio, FastAVR). Так сделайте поддержку Modbus TCP, будет не контроллер, а конфета. Пусть он даже жёстко прошит или работает только со своими датчиками.
Всё на самом деле очень просто, данные идут от датчиков в контроллер. Далее они могут использоваться или другим контроллером или уйти в ПК. В том же ПК уже есть огромное количество готового софта, в том числе и бесплатного типа OpenSCADA, и весь этот софт практически всегда поддерживает Modbus TCP.
А это множество возможностей, архивация в базу данных, интерактивное отображение графических интерфейсов в клиенте и даже в вебе, телеметрия, управление, графики, таблицы, отчёты и многое другое. Новички в автоматизации не понимают таких простых вещей. В итоге каждый создаёт свой протокол, в том же FTP внутри всё равно свой формат данных. Причём сам FTP будет глючить нещадно, так как промышленная сеть рассчитана на безотказную работу годами.
Вообще говоря rsdn это не совсем тот форум, где стоит обсуждать подобные вопросы. Существуют форумы по промышленной автоматизации. Если человек, например, всю жизнь ваял веб, но никогда не видел контроллеров, то опыт будет ему подсказывать использовать совершенно неуместные решения.
Здравствуйте, 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.
V>Для промышленной автоматизации нужно использовать Modbus TCP, стандартный порт 502.
Все верно, добавлю еще, что существует понятие Industrial Ethernet, там перечислены основные протоколы и стандарты.
Здравствуйте, 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 — это прямое копирование между серверами. Для клиент-сервера он малопригоден.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 карту (как путь последнего выбора, в случае длительной потери связи с АРМ-ом).
Очевидно, слушатель может слать хартбиты с номером последнего принятого пакета- в таком случае девайс при переполнении кольцевого буфера сможет его "голову" выгружать в файл на флеш карте. Но если хартбиты приходят вовремя и память не переполняется, не изнашивать понапрасну флеш.
