TCP или UDP?, Подскажите способ реализации Опции

[gladov]

Поздравляю всех с наступающими праздниками!!!

А вопрос у меня такой. Есть классическая ситуация - некоторое устройство управляется компом по сети, причем находятся они в одной локалке, т.е. все быстро и условно надежно. Устройство получает от компа команды, возвращает результаты замеров, статусы и проч. Встает вопрос что использовать: TCP или UDP?

В пользу TCP говорит тот факт, что не надо проверять доставку (а иногда важная команда должна быть обязательно доставлена, причем выполнена только один раз). Тут появляется большое "но". Фактически, те данные, которые я буду передавать (например, команды) - это пакеты. Т.е. явная пакетная передача данных. А TCP потоковый! Он мне даже не скажет, где одна команда закончилась и новая началась. Т.е. мне надо вводить некий механизм синхронизации чтобы отлавливать начало очередного пакета.
Первое что в голову приходит - самому на своем уровне добавлять в пакет его длину. Но если одна из сторон хоть раз ошибется или сетка сглючит и длина пакета окажется неправильной, то я никогда уже не поймаю начало очередного пакета.
Можно вместо длины (или вместе с ней) пометить сигнатурой начало пакета, а в самом пакете делать байт-стаффинг чтобы она там не повторилась. Не нравится - как-то тяжеловесно получается.
Можно сделать по UDP, но там придется городить подтверждение доставки и контроль на недублирование пакетов. Тоже гемор.
Короче, варианты решения я вижу, но все они мне не нравятся. Мне кажется, что есть какое-то простое и красивое решение, а я заблудился в трех соснах. Т.к. ситуация классическая для большинства встроенных систем, поделитесь плз опытом, кто как решает подобные задачи.

[GL_basik]

Вставлю свои 5 копеек.... Если надо бытро и легко передавать по сети команды то существет такой замечательный протокол SNMP. Там все уже придумано до нас. Связь идет по UDP, но для любителей предсмотрен режим связи по TCP (имхо не нужен, подтверждение не пришло - перепосылка по таймауту+сообщение пользователю). Софт для компа тоже существует, правда большинство решений платные, но где же наша не пропадала. В snmp менеджер компилятся нужные mib, что создашь то и будет. Ну а на устройство пишется простенькое ПО для отработки snmp (или не совсем простенькое, если авторизация нужна). И не надо городить web-сервер и тем более придумывать собственные протоколы.

[Aprox]

Вставлю свои 5 копеек.... Если надо бытро и легко передавать по сети команды то существет такой замечательный протокол SNMP. Там все уже придумано до нас. Связь идет по UDP, но для любителей предсмотрен режим связи по TCP (имхо не нужен, подтверждение не пришло - перепосылка по таймауту+сообщение пользователю). Софт для компа тоже существует, правда большинство решений платные, но где же наша не пропадала. В snmp менеджер компилятся нужные mib, что создашь то и будет. Ну а на устройство пишется простенькое ПО для отработки snmp (или не совсем простенькое, если авторизация нужна). И не надо городить web-сервер и тем более придумывать собственные протоколы.

Протокол SNMP, насколько я понимаю, требует IP формата кадров. Т.е. по накладным расходам мало чем отличается от UDP. Поэтому со стороны прибора с небольшим микроконтроллером внутри особого облегчения не наблюдается. Hи по ресурсам, ни по быстродействию. В то же самое время, RAW-пакеты имеют оверхед по-минимуму. Поэтому выглядят более привлекательно для использования в embedded system со связью по Ethernet, и по ресурсам, и по быстродействию. По-существу, конструкция начинает напоминать широко распространенный MODBUS по RS-485, только на два порядка быстрее. По этой причине, конструкторам малых систем имеет смысл отказаться от IP вообще и не вспоминать больше никакие UDP, TCP или SNMP.

Что касается городить web-сервер, то лучше его все-таки городить, т.к. сильно облегчает создание и сопровождение FrontEnd-ов. Городить этот сервер надо не в приборе, а на http:\\localhost, который, уже в свою очередь, перекодирует http-запросы в RAW-пакеты и обратно. Для этого существует прекрасно себя зарекомендовавший WinPCap, кстати бесплатный. Я сейчас как раз этим занимаюсь и пока все получается нормально.

[blackfin]

По этой причине, конструкторам малых систем имеет смысл отказаться от IP вообще и не вспоминать больше никакие UDP, TCP или SNMP.
...
Городить этот сервер надо не в приборе, а на http:\\localhost, который, уже в свою очередь, перекодирует http-запросы в RAW-пакеты и обратно.

Сразу пара вопросов..

1. Сколько удаленных пользователей Ваш прибор может обслужить одновременно?
2. Реализован ли в вашем приборе механизм транзакций?

Поясню суть второго вопроса подробнее..

Допустим, с Вашим прибором через удаленные терминалы могут одновременно работать 100 операторов.
Допустим также, что в программе прибора существует ULONG переменная "Counter" и каждый из операторов может нажатием кнопки на HTML-странице в броузере IE увеличить значение переменной "Counter" на единицу. (Т.е. "отправить команду").
Пусть начальное значение переменной "Counter", которое мы видим в окне браузера равно 0.
Пусть также значение переменной "Counter", которое мы видим в окне браузера после нажатия кнопки равно 50.

Вопрос - можем ли мы быть уверенными в том, что:

50 = 49 + результат_нажатия_кнопки_в_окне_нашего_браузера, или
50 = 50, а результат_нажатия_кнопки_в_окне_нашего_браузера_где_то_потерялся?

[Aprox]

Сразу пара вопросов..

1. Сколько удаленных пользователей Ваш прибор может обслужить одновременно?

В теории- число клиентов ограничено лишь диапазоном физических MAC адресов. Hо на практике я встречался только с распределенными системами, когда клиент один, например SCADA на компьютере, а серверов много, несколько десятков- удаленные приборы управления и сбора информации.

2. Реализован ли в вашем приборе механизм транзакций?

Поясню суть второго вопроса подробнее..

Допустим, с Вашим прибором через удаленные терминалы могут одновременно работать 100 операторов.
Допустим также, что в программе прибора существует ULONG переменная "Counter" и каждый из операторов может нажатием кнопки на HTML-странице в броузере IE увеличить значение переменной "Counter" на единицу. (Т.е. "отправить команду").
Пусть начальное значение переменной "Counter", которое мы видим в окне браузера равно 0.
Пусть также значение переменной "Counter", которое мы видим в окне браузера после нажатия кнопки равно 50.

Вопрос - можем ли мы быть уверенными в том, что:

50 = 49 + результат_нажатия_кнопки_в_окне_нашего_браузера, или
50 = 50, а результат_нажатия_кнопки_в_окне_нашего_браузера_где_то_потерялся?

В окне броузера будет отображен установленное оператором значение. Hо в удаленном приборе это не гарантировано, поскольку позже управление может быть перезаписано другим оператором с другого клиента. Однако, если предусмотрен периодический Reload страницы, то все операторы спустя некоторое время увидят фактическое значение управления в удаленном приборе.

Необходимо напомнить, что я имею ввиду локальные сети в промышленной и научно-технической сферах. Типичное для таких сетей- один клиент и много серверов. В настоящий момент, единственное, что сдерживает применение Ethernet в таких сетях,- это избыточные навороты с протоколами и TCP/IP стеками. Мне представляется, переход к Raw-пакетам в данном случае выглядит разумным.

[blackfin]

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

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

Типичное для таких сетей - один клиент и много серверов.

Если сеть со временем меняет топологию или расширяется, рано или поздно возникнет ситуация когда два клиента попытаются обратиться к одному серверу.

В настоящий момент, единственное, что сдерживает применение Ethernet в таких сетях,- это избыточные навороты с протоколами и TCP/IP стеками.

ИМХО, ничто не сдерживает применение Ethernet Internet'a в таких сетях, ибо никакой избыточности в TCP/IP нет.
Может, есть недостаток ресурсов выбранного МК, но это вопрос грамотности разработчика.

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

Мне, напротив, это кажется неразумным, но нужно ли спорить о вкусах?

[Aprox]

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

Делаю распределенную систему на базе свитча, но не хаба. К свитчу пока нареканий нет.

Если сеть со временем меняет топологию или расширяется, рано или поздно возникнет ситуация когда два клиента попытаются обратиться к одному серверу.

После того, как система сдана и запущена в работу на промышленном производстве, заказчик костьми ляжет, но не допустит никаких смен топологии. Расширение же производится установкой другого свитча, с большим числом портов. При этом появление новых клиентов в сети недопустимо, т.к. означает смену топологии. Заказчик против.

ИМХО, ничто не сдерживает применение Ethernet Internet'a в таких сетях, ибо никакой избыточности в TCP/IP нет.
Может, есть недостаток ресурсов выбранного МК, но это вопрос грамотности разработчика.

Как показывает обсуждение в данном треде, и в ряде других на форуме, разработчики активно ищут пути не использовать стандартные решения TCP/IP. Потому, что для целей простого приборостроения этот стек протоколов дает большие накладные расходы по софту и быстродействию. Можно смириться с избыточностью софта и подобрать нужный МК, но поднять скорость передачи данных, увеличить загрузку сети, практически невозможно.

[blackfin]

Делаю распределенную систему на базе свитча, но не хаба. К свитчу пока нареканий нет.

Switch, конечно, тоже будет работать, но ограничение на максимальное кол-во хостов в Вашей локальной сети остается - максимум 96 хостов. Возможно, в Вашем конкретном случае это не проблема.

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

Новые клиенты могут появиться, если пользователь запустит несколько экземпляров браузера на одном компьютере.. Что тогда?

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

Согласен, если число пакетов в секунду велико, а размер каждого пакета мал, переход к RAW-ethernet пакетам может дать существенный выигрыш в производительности сети.. Но стоит ли рассчитывать на устойчивую работу сети на пределе производительности?

Кроме того, при использовании switch'а лишенного внутреннего буфера для хранения пакетов могут появиться проблемы с коллизиями пакетов в сегменте switch<->PC. Как следствие - потеря пакетов и т.д. и т.п.

Впрочем, насколько мне известно, Вы эту проблему уже обсуждали: подключение устройства к ethernet.

[Aprox]

Новые клиенты могут появиться, если пользователь запустит несколько экземпляров браузера на одном компьютере.. Что тогда?

Да, на такую возможность следует заложиться. Hапример, ограничить число подключений к серверу одной штукой.

Согласен, если число пакетов в секунду велико, а размер каждого пакета мал, переход к RAW-ethernet пакетам может дать существенный выигрыш в производительности сети.. Но стоит ли рассчитывать на устойчивую работу сети на пределе производительности?

Именно это я и хочу проверить. Искал похожие примеры реализаций, но не нашел. Приходится самому.

Кроме того, при использовании switch'а лишенного внутреннего буфера для хранения пакетов могут появиться проблемы с коллизиями пакетов в сегменте switch<->PC. Как следствие - потеря пакетов и т.д. и т.п.
Впрочем, насколько мне известно, Вы эту проблему уже обсуждали:

Да, сегмент switch<->PC предполагается делать на 1Г Ethernet. Такие свитчи имеются а продаже. Сейчас я не готов обсуждать, какие подводные камни ждут на этом пути. Будем пробовать, и набивать шишки.

Если есть время сначала создавать устройство, потом писать под него софт, а потом под устройство подстраивать топологию сети, тогда можно использовать все что угодно. Но времени обычно нет. А обычно есть сеть и есть информационная система, которая собирает данные о состоянии сети. Соотвественно при проектировании устройства нужно ориентироваться на стандартные протоколы. Чтоб монтажник мог придти в подъезд обжать кабель подключить девайс и уйти, а дейвайс сам бы себя сконфигурил и вписался в информационную систему. Здесь уж RAW пакетами не обойтись...

Полностью согласен- при наращивании уже готовой сети следует придерживаться тех протоколов и форматов, которые уже действуют в этой сети. Hо, когда система создается с нуля и поставляется в комплексе, то можно себе позволить некую свободу действий.