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

[gladov]

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

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

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

[Postoroniy_V]

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

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

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

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

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

[gladov]

а можно подробнее что значит А TCP потоковый!

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

кто заставляет Вас посылать больше чем нужно?

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

тут почитайте http://en.wikipedia.org/wiki/Transmission_Control_Protocol

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

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

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

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

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

Просто вначале пакета (сообщения) на передающей стороне вставляете длину данных и на приемной стороне выбираете (извлекаете) из сокета столько байт сколько указано в этом поле длины. Естесственно в следующей порции данных первым будет поле длины.

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

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

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