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

[gladov]

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

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

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

[Aprox]

Может, я чего-то не понимаю в тонкостях задачи, но по-моему самый распространённый метод управления прибором по Ethernet- это встроенный в прибор WEB сервер. Максимальная степень отлаженности решения и практически стопроцентная готовность. Ничего не надо изобретать самому и вообще разбираться с TCP и UDP. Если кроме управления нужно еще принимать данные от прибора, то на помощь приходят "HTTPзапросы", которые используются в броузерах по технологии Ajax или Flash.

[Rst7]

Может, я чего-то не понимаю в тонкостях задачи, но по-моему самый распространённый метод управления прибором по Ethernet- это встроенный в прибор WEB сервер.

Это хорошо для начальной конфигурации прибора и для прямого управления пользователем (что-нибудь включить/выключить, например). А если вам сырые данные надо из прибора в софт на компе передавать, то HTTP - это только лишний уровень, толку от него - никакого.

Максимальная степень отлаженности решения и практически стопроцентная готовность. Ничего не надо изобретать самому и вообще разбираться с TCP и UDP.

Это если у Вас прибор с мозгом, на котором можно никса с апачем поднять, например, тогда можно говорить об "Максимальной степени..."

Если кроме управления нужно еще принимать данные от прибора, то на помощь приходят "HTTPзапросы", которые используются в броузерах по технологии Ajax или Flash.

А вот это костыль, предназначеный для преодоления изначально статической природы HTTP/HTML. Который совсем не нужен для того, чтобы носить данные из прибора в обрабатывающую программу. Да и вообще, термин "HTTP-запросы" не есть прерогатива аякса или флеша, это и есть название одной из стадий обмена информацией по протоколу HTTP.

И вообще, я считаю, что организовывать web-сервер в приборе имеет смысл только для избавления от софта верхнего уровня на компе, причем софт этот используется для визуализации данных. В этом случае браузер используется в качестве некоего терминала, а вам не надо писать софт верхнего уровня (актуально, например, если хост может работать как под линухом, там и под виндой). Однако, тут много своих граблей - например, разная интрерпретация разными браузерами HTML-кода, особенно, с новомодными примочками, или реализация digest-авторизации - везде разная, и полностью RFC не соответствующая (хорошо, если просто чего-то не выполняется, Опера, например, не поддерживает ключ next_nonce, а IE только с 7го начал поддерживать такую авторизацию, да только совсем вольно трактует мелкософт понятие URL, а для своего прибора еле нашел консольный браузер под никсы, который вообще асиливает digest - ведь одмины у нас страсть как не любят окошки )... короче, грабли, грабли, и еще грабли...

[vvs157]

Это хорошо для начальной конфигурации прибора и для прямого управления пользователем (что-нибудь включить/выключить, например). А если вам сырые данные надо из прибора в софт на компе передавать, то HTTP - это только лишний уровень, толку от него - никакого.

Используйте протокол Telnet. Прост до неприличия, работать при желании (отладка, например) можно из большинства терминальных программ для связи по RS-232. Достоверность данных обеспечивается протоколом TCP и можете не заморачивать себе голову. Я ни разу не видел, чтоб при связи по Telnet'у данные искажались даже на очень полохой линии.

[Rst7]

Используйте протокол Telnet. Прост до неприличия, работать при желании (отладка, например) можно из большинства терминальных программ для связи по RS-232. Достоверность данных обеспечивается протоколом TCP и можете не заморачивать себе голову. Я ни разу не видел, чтоб при связи по Telnet'у данные искажались даже на очень полохой линии.

Вот тут тоже не согласен. Зачем человеку брать бинарные данные, делать из них ASCII-коды, передавать, на приемной стороне делать из ASCII-данных бинарные и обрабатывать их дальше? Это все ради того, чтобы на начальном этапе увидеть эти данные в Telnet? А потом будет просто какой-то софт верхнего уровня? Да и отладить сейчас софт на большом брате проблем нет никаких - все среды с отладчиками, терминальная отладка особо не нужна.

Результат повальных увлечений терминалом вообще плачевный - просто так пропускную способность канала опускают в два раза, а потом в других темах меряются пиписьками, как быстрее напечатать unsigned short в десятичную строку . Хотя struct OUT_DATA {... ... .. . } buf; send(sock,&buf,sizeof(buf),0) проще всего...