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

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

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

а можно подробнее что значит А TCP потоковый! кто заставляет Вас посылать больше чем нужно?
тут почитайте http://en.wikipedia.org/wiki/Transmission_Control_Protocol

имхо TCP тут самое оно, особенно если (а иногда важная команда должна быть обязательно доставлена, причем выполнена только один раз).

Не волнуйтесь, этот вопрос возьмет на себя TCP. Он гарантирует, что все будет доставлено в нужном порядке.

...вы противоречите сами себе. Если TCP гарантирует доставку это значит что



...в такой ситуации либо будет разорван поток (вам только остается решить как эту ситуацию разрешить), либо данные все же будут доставлены. Не нужно ничего выдумывать с байт-стаффингом. Просто вначале пакета (сообщения) на передающей стороне вставляете длину данных и на приемной стороне выбираете (извлекаете) из сокета столько байт сколько указано в этом поле длины. Естесственно в следующей порции данных первым будет поле длины. Это справедливо для пакетов переменной длины. Если же у Вас пакеты одной длины то (пример для Linux)

struct
{
...
} mes;

/* ожидаем прием пакета */
while(recv(socket_fd, (void *) &mes, sizeof(mes), MSG_PEEK) < sizeof(mes));

/* считываем пакет */
recv(new_us, (void *) &mes, sizeof(mes), 0);

Вот что Вы хотели спросить:
У Вас есть команды определенной длины. Длина команды на нижнем уровне должна быть не более 1,5К. Из этой длины вычитаем то, что займет TCP, и все что останется - это и будет максимальной длиной ВАШЕЙ КОМАНДЫ. Теперь ВСЯ ваша команда гарантированно влезет в один пакет. Таким образом, передавая пакет, вы будете в нем иметь полную синхронизацию с Вашими командами, т.е там будет все, начиная от ВАШЕГО заголовка и кончая ВАШЕЙ CRC. Если у Вас команды длинные, то можно их передавать по частям - команда "накопить действия", "проверить статус накопленног", "выполнить накопленные действия"

Ну, вот вроде далее все просто. Считайте что если Ваши машины сумеют разобраться с ВАШИМ протоколом, то все остальное только передача сообщений....

Удачи!

TCP гарантирует, последовательность и целостность данных, ни порядок не поменяется и не один байт не пропадет. Но реализация TCP довольно сложна, и требует довольно много ресурсов. Самое простое взять lwip ucip или что то подобное.

UDP намного проще в реализации. Если вам не надо передавать поток данных, а только команды и принимать ответы ( не нужно управлять скоростью потока ), то подтверждения в UDP сделать довольно просто, например пересылать с каждой командой ее номер и в ответе указыватье тот же номер, и если ответ не пришел за нужное время, повторять попытку...

Это значит, что работа с TCP сокетом полностью аналогична работе с файлом, т.е. делаю тот же read() которому Я говорю, сколько байт вычитать из сокета, а не ОН МНЕ сообщает, сколько пришло. Конечно, можно его попросить не блокироваться и отдавать не столько, сколько я попросил, а столько, сколько пришло сейчас, но тогда будет срабатывать на недоконца доставленные пакеты (фрагменты).


Вопрос не ясен. Я посылаю именно столько, сколько нужно, а вот приемник совсем не знает сколько ему сейчас нужно принять.


Читал, и не только это.


Порядок безусловно будет соблюден, но кто гарантирует, что байт с длиной будет принят правильно? Знаете, что ТСР проверяет целостность данных даже не по CRC? Там контрольная сумма считается гораздо проще и давно признана ненадежной.


Значит, что фрагмент данных будет доставлен и что он окажется в нужном месте потока, но, повторюсь, НЕ ГАРАНТИРУЕТ достоверность доставленных данных. Да, вероятность мала, но она есть!


Это и ежику понятно, только вот что вы будете делать, если побьется очередной байт с длиной пакета? Если бы из-за этого я потерял один пакет - ерунда. Но связь будет оборвана ПОЛНОСТЬЮ. Отсюда и идея с байт-стаффингом.
И, кстати, битые байты в пакетах ТСР ситуация не гипотетическая. Коллега на эти грабли наступал. Случается крайне редко, но бывает.



Почти согласен, но не будем забывать про "окно" в ТСР. Грубо, это размер свободного приемного буфера, который передается приемником передатчику вместа с Аками. Так вот мы имеем дело с микроконтроллером, который не обладает мегабайтами памяти для выделения достаточного количества буферов. Что ему делать? Конечно уменьшать окно. В процессе работы окно иногда уменьшается до нескольких байт! И независимо от настройки MTU пакет будет порван. Есть даже такое понятие как "синдром глупого окна", когда даже с нормальными объемами памяти размер этого окна очень сильно уменьшается из-за сложившихся обстоятельств. Конечно, совеременные реализации ТСР в операционках защищены от подобного эффекта, но я работаю и с мелкими реализациями ТСР для встроенных систем. Как они себя ведут с размерами окна я не знаю.

про битые пакеты не понятно, куда смотрит МАК уровень?если в пакете исказилась длина пакета
и если Вы ловите такие пакеты, то ИМХО всё равно что использовать хоть ТСР хоть UDP
какая разница?

У вас же Эзернет. Поверх этой красоты есть еще и CRC32 самого эзернета. Вам мало? Тогда положите в каждый свой пакет еще и свою контрольную сумму. При неправильном байте длинны, например, у вас не срастется ваша CRC. Оптимально в этом случае закрыть соединение (причем с флагом RST), а потом открыть его заново. Но, поверьте, такой ситуации у вас не будет, а если будет - то надо выкинуть используемый стек или MAC-уровень.

На самом деле проблема немного глубже. При своем стеке (в микроконтроллере, например), можно добиться уверенности о доставке пакета, а вот со стеком в той же винде - так не получится, send вам сказал - ушло, например, 100 байт, а на самом деле они еще болтаются в буферах, и неизвестно чьих, толи передатчика, толи приемника. Аналогично, при приеме, виндовый стек уже отправил подтверждение, а пакет еще не вытащен при помощи recv... В никсах ситуация анологичная, да и везде, где реализация сокетов - калька с BSD.

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

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



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



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

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

...Вам не кажется что Вы слишком усложняете ситуацию? Вероятность потери или порчи байта зависит от многих причин, например от качества канала связи по которому Вы гоняете информацию. Если это Ethernet между устройствами в пределах одного метра и в квартире, то сами понимаете потерять байт в данном случае практически невозможно. Далее, CRC тоже не панацея от всех бед, потому что тоже есть вероятность не распознать ошибку. И потом есть вероятность потерять и сам байт-стаффинг. Что Вы будете делать в этом случае?



...есть вероятность что на Вас может упасть метеорит





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

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




Полностью согласен. HTTP в данном случае принесет лишние бестолковые проблемы. Вообще, огромное спасибо всем и особенно Rst7 за консультации на тему.

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

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

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