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

[gladov]

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

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

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

[Rst7]

Когда начинаются разговоры, о том дескать, что никаких протоколов не надо -- всё сводится либо к форматам (плюс какой-то неопределённый алгоритм обмена данными с использованием оных), либо к какой-то форме RPC. В последней случае действительно "протоколов не надо", они диктуются уровнем RPC (XML-RPC, DCOM, Corba, SOAP...) Вместо них появляются типы данных, объекты, методы... Классы и состояния.

Зачем человеку городить это все? Чтобы было?

Я на FTP ссылку не просто так давал. Там ПЕРЕДАЮТСЯ ГОЛЫЕ БИНАРНЫЕ ДАННЫЕ. В отдельном соединении. Это действительно проще, чем HTTP.

Ага, конечно. 2 соединения проще одного, причем в одном текстом команды гонять, в другом - данные? Смысл???

Самое плохое, что такие приборы и программы не поддаются никакой автоматизации сторонними разработчиками.

А может человек за комплекс програмных и аппаратных средств берет деньги и ему совсем не нужны шаловливые ручки "сторонних разработчиков", которые будут там чего-то изменять в его комплексе? Рассмотрите вопрос в таком аспекте. И время, затраченное на разработку. Я тоже больше денег заработаю, если просто передам send'ом структуру и все, а не буду неделю изготавливать фронт-энд для даже просто телнета.

Ну и отладка. Что проще, отладить комплекс из программы под Win и программы в железе, либо что-то одно используя при этом элементарный телнет.

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

Третий аспект -- бинарных данных не бывает. Байт -- абстракция верная только для данной ЭВМ. Текст более универсален. Текст позволяет без проблем передавать простые типы данных так, что они будут корректно прочитаны и представлены на обоих ЭВМ (как там число в IEEE754 вручную записать?)

Простите, но протокол TCP/IP оперирует именно БАЙТАМИ в канале передачи. Так что это неуместное замечание.

Предлагаю автору тему закрыть, а то мы тут подеремся