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

[gladov]

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

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

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

[Rst7]

На телнет неделю?

Об этом - чуть ниже, не Вы один тут удивляетесь

Предлагаете сниффер как универсальное средство отладки и мониторинга межприборного взаимодействия

Как одно из необходимых средств - конечно. А также надо использовать хотя-бы отладчики для ускорения процесса.

Или быстренько изучить работу с сокетами и под любую задачу лихо писать программку на С?

Ага, вы предлагает вообще не изучать ничего и гнать данные в текстовом виде? Глубину этого заблуждения я сейчас постараюсь продемонстрировать. Вам и Kirill Frolov'у, который

Я б вам не доверил. Не неделю. Пол-часа.

Давайте посмотрим, как будет выглядеть вариант с передачей бинарных данных и с передачей в виде ascii-строк.

Допустим, у нас есть набор переменных v1, v2 ... vn, которые надо передать в другой софт на другом компе через сеть используя TCP/IP

Мой вариант (конечно, все условно)

Код

//Передача

stuct
{
long v1;
float v2;
....
short v3;
}VARS;

...

if (send(sock,&VARS,sizeof(VARS),0)!=sizeof(VARS))
{
//Ошибка
....
}

//Прием

stuct
{
long v1;
float v2;
....
short v3;
}VARS;

...

int res;
if (ioctlsocket(sock,FIONREAD,&res)) //Вариант для винды
{
//Ошибка
}
if (res<sizeof(VARS))
{
//Еще нет достаточного количества данных
}
if (recv(sock,&VARS,sizeof(VARS),0)!=sizeof(VARS))
{
//Ошибка
}

Есть небольшая тонкость, связаная с выравниваем полей в структурах, это решается при помощи #pragma pack(1).

Теперь посмотрим, что надо сделать для работы с ascii

Код

//Передача

char s[100];
int l;
sprintf(s,"%d %d %d\r\n",v1,v2,...);
l=strlen(s);
if (send(sock,s,l,0)!=l
{
//Ошибка
}

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

Теперь обратим внимание на то, что у автора в приборе стоит весьма маленький по ресурсам камень. Напомню, что formatted_write с поддержкой плавающей запятой - килобайт под 8, и еще ему нужен огромный размер стека. Если надо будет разбирать числа при приеме, то sscanf - тоже весьма немалая процедура. Вот отсюда, кстати, и растут ноги упомянутого мной членомерства. Так сколько времени человек будет делать это все? За неделю, я думаю, как раз справится.

Так что, господа - любители телнета, тут вы погорячились.

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

Да Вы просто в душе хакер!

А Вы завидуете черной завистью?

[Kirill Frolov]

Допустим, у нас есть набор переменных v1, v2 ... vn, которые надо передать в другой софт на другом компе через сеть используя TCP/IP
Мой вариант (конечно, все условно)

Код

//Передача
stuct
{
long v1;
float v2;
....
short v3;
}VARS;

...

if (send(sock,&VARS,sizeof(VARS),0)!=sizeof(VARS))
{
//Ошибка

Угу. Ошибка. Такое в реальной жизни не работает. Начать можно хоть с man xdr(3)

Код

if (recv(sock,&VARS,sizeof(VARS),0)!=sizeof(VARS))
{
//Ошибка
}

Есть небольшая тонкость, связаная с выравниваем полей в структурах, это решается при помощи #pragma pack(1).

Ещё небольшая тонкость с sizeof(), разными прагмами/атрибутами в разных компиляторах, порядко байтов, размером базовых типов... ЭТО НЕ РАБОТАЕТ в обще случаем. Частноости (win32<->win32) не интересны.

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

Бред. Тривиальный автомат. Если допустима блокировка на чтении, то возможно делать просто fscanf(). Про lex вы тоже не в курсе...

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

Между /можно допустить/ и *уже* *не* *работает* -- гигантская пропасть. Допустить ошибку можно практически везде.

Теперь обратим внимание на то, что у автора в приборе стоит весьма маленький по ресурсам камень.

tcp/ip стек на порядок тяжелее printf'а.

Напомню, что formatted_write с поддержкой плавающей запятой - килобайт под 8,

В приличной libc можно подключить версию без плавающей точки.

и еще ему нужен огромный размер стека.

Аж полсотни байт!

Если надо будет разбирать числа при приеме, то sscanf - тоже весьма немалая процедура.

Для тех кому очень неймётся есть atoi(3)... А вот itoa -- экзотика.

Вот отсюда, кстати, и растут ноги упомянутого мной членомерства. Так сколько времени человек будет делать это все? За неделю, я думаю, как раз справится.

Неплохо, если за неделю. А сколько он будет самодельные велосипеды вместо библиотечных функций изобретать и отлаживать?

А Вы завидуете черной завистью?

Нет. Я думаю, я зря трачу своё время на бесполезные споры.