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

[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 -- экзотика.

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

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

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

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

[Rst7]

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

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

Ещё небольшая тонкость с sizeof()

Какая?

разными прагмами/атрибутами в разных компиляторах

Почти везде pragma pack делает то, что надо.

порядко байтов

Да, бывает, не спорю. Но преодолимо простейшим способом. Никто же не стреляется при реализации TCP/IP на i86 - а там все перевернуто.

размером базовых типов...

В структуре написано, например, long v1, а не int v1. Это же не просто так, как Вы думаете?

Бред. Тривиальный автомат.

Это все делать надо, и не за 5 минут. Как и лекс (или вообще yacc) прикручивать (я знаю, что это такое, не считайте других глупее себя).

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

tcpip, я так понял, живет в визнете.

Остальное даже комментировать не хочу.

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

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

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

Именно. Автор явно для себя давно все уяснил. Наверняка уже и работает все, пока мы тут копья ломаем

[vvs157]

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

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

[Rst7]

гадить потребителю тоже не подобает серьезным людям.

Объясните, чем же мой вариант гадит потребителю?

[Aprox]

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

На "низшей меге" реализовать полноценный TCP/IP весьма и весьма проблематично. Я бы не взялся. Hо если у вас все же получится, то достроить до WEB-сервера останется совсем чуть чуть.

[blackfin]

... достроить до WEB-сервера останется совсем чуть чуть.

Ага, ~100 КБайт кода для WEB-сервера + N-КБайт для HTML-страниц.

[Rst7]

На "низшей меге" реализовать полноценный TCP/IP весьма и весьма проблематично. Я бы не взялся. Hо если у вас все же получится, то достроить до WEB-сервера останется совсем чуть чуть.

Ага, ~100 КБайт кода для WEB-сервера + N-КБайт для HTML-страниц.

Ну это смотря как писать.

Камень - ATMEGA168, из .map-файла IAR'овского линкера (каменты - мои)

Код

                ****************************************
                *                                      *
                *            MODULE SUMMARY            *
                *                                      *
                ****************************************

Module                  CODE           DATA
------                  ----           ----
                     (Rel)  (Abs)  (Rel)  (Abs)
?C_SHL_L01              10
?C_STARTUP              36
?FILLER_BYTES           40
  + common              64
?L_SHL_L03              16
?MOVE_LONG_L07          22
?RESET
  + common               4
?SS_SHR_L02             12
?S_SHL_L02              12
?UL_SHR_L03             16
?__exit                  6
?low_level_init          4
?segment_init           80
?strcmp_p               30
?strcpy                 32
?strcpy_p               20
?strlen                 20
?strncmp                58
;Передатчик эзернет-пакетов
mac                    398             3     10
  + shared               6                    1
  + common              64
;Приемник эзернет-пакетов
mac_rx                 402
  + common              10
;HTTP-сервер
main                 2 820           337      4
  + shared               6
;MD5 для digest-авторизации
md5cheat             2 468
;ARP,IP,ICMP,TCP
nework               2 534            26    513
  + common              60
;Данные для генерации страничек
pages                1 786
;Таблица для быстрого расчета CRC32
stuff                       1 024
N/A (command line)                   128
N/A (alignment)
----------          ------  -----    ---    ---
Total:              10 834  1 024    494    528
  + common              64

[blackfin]

Ну это смотря как писать.

Как-нибудь так: msdn: Web Server Requirements

[Aprox]

Ага, ~100 КБайт кода для WEB-сервера + N-КБайт для HTML-страниц.

Это если в лоб. Настоящие же герои всегда идут в обход. Основные килобайты, и даже мегабайты статической части страниц хранятся на http-сервере localhost компьютера. Изнутри этих страниц средствами Ajax, CGI или Flash производятся запросы данных на удаленный прибор по урлам. Эти очень короткие запросы и ответы составляют динамическое наполнение страниц. Никаких диких килобайт памяти в удаленном приборе вовсе не требуется. По-моему, эта технология называется WEB-сервисы. Но могу и ошибаться.

[GL_basik]

Вставлю свои 5 копеек.... Если надо бытро и легко передавать по сети команды то существет такой замечательный протокол SNMP. Там все уже придумано до нас. Связь идет по UDP, но для любителей предсмотрен режим связи по TCP (имхо не нужен, подтверждение не пришло - перепосылка по таймауту+сообщение пользователю). Софт для компа тоже существует, правда большинство решений платные, но где же наша не пропадала. В snmp менеджер компилятся нужные mib, что создашь то и будет. Ну а на устройство пишется простенькое ПО для отработки snmp (или не совсем простенькое, если авторизация нужна). И не надо городить web-сервер и тем более придумывать собственные протоколы.

[Aprox]

Вставлю свои 5 копеек.... Если надо бытро и легко передавать по сети команды то существет такой замечательный протокол SNMP. Там все уже придумано до нас. Связь идет по UDP, но для любителей предсмотрен режим связи по TCP (имхо не нужен, подтверждение не пришло - перепосылка по таймауту+сообщение пользователю). Софт для компа тоже существует, правда большинство решений платные, но где же наша не пропадала. В snmp менеджер компилятся нужные mib, что создашь то и будет. Ну а на устройство пишется простенькое ПО для отработки snmp (или не совсем простенькое, если авторизация нужна). И не надо городить web-сервер и тем более придумывать собственные протоколы.

Протокол SNMP, насколько я понимаю, требует IP формата кадров. Т.е. по накладным расходам мало чем отличается от UDP. Поэтому со стороны прибора с небольшим микроконтроллером внутри особого облегчения не наблюдается. Hи по ресурсам, ни по быстродействию. В то же самое время, RAW-пакеты имеют оверхед по-минимуму. Поэтому выглядят более привлекательно для использования в embedded system со связью по Ethernet, и по ресурсам, и по быстродействию. По-существу, конструкция начинает напоминать широко распространенный MODBUS по RS-485, только на два порядка быстрее. По этой причине, конструкторам малых систем имеет смысл отказаться от IP вообще и не вспоминать больше никакие UDP, TCP или SNMP.

Что касается городить web-сервер, то лучше его все-таки городить, т.к. сильно облегчает создание и сопровождение FrontEnd-ов. Городить этот сервер надо не в приборе, а на http:\\localhost, который, уже в свою очередь, перекодирует http-запросы в RAW-пакеты и обратно. Для этого существует прекрасно себя зарекомендовавший WinPCap, кстати бесплатный. Я сейчас как раз этим занимаюсь и пока все получается нормально.

[Rst7]

По этой причине, конструкторам малых систем имеет смысл отказаться от IP вообще и не вспоминать больше никакие UDP, TCP или SNMP.

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

[Dog Pawlowa]

Без рассмотрения:
- структуры прибора
- объема передаваемой информации
- цены вопроса
обсуждение протокола не имеет большого смысла.

Возможны два практически крайних варианта:
- встроенный стек TCP/IP (например, устройство на продвинутом АРМе) и большие потоки
- отдельный стек TCP/IP (например, Мега 8 и X-port или другой конвертер COM <>TCP/IP) и редкие команды управления.

В моих приборах
- структура прибора - один или несколько достаточно простых микроконтроллеров
- объем передаваемой информации - десятки команд в секунду
- цена вопроса некритична

Поэтому я использую TCP/IP и поверх него самопальный последовательный протокол ( очень упрощенный SNMP в текстовом режиме).

[blackfin]

По этой причине, конструкторам малых систем имеет смысл отказаться от IP вообще и не вспоминать больше никакие UDP, TCP или SNMP.
...
Городить этот сервер надо не в приборе, а на http:\\localhost, который, уже в свою очередь, перекодирует http-запросы в RAW-пакеты и обратно.

Сразу пара вопросов..

1. Сколько удаленных пользователей Ваш прибор может обслужить одновременно?
2. Реализован ли в вашем приборе механизм транзакций?

Поясню суть второго вопроса подробнее..

Допустим, с Вашим прибором через удаленные терминалы могут одновременно работать 100 операторов.
Допустим также, что в программе прибора существует ULONG переменная "Counter" и каждый из операторов может нажатием кнопки на HTML-странице в броузере IE увеличить значение переменной "Counter" на единицу. (Т.е. "отправить команду").
Пусть начальное значение переменной "Counter", которое мы видим в окне браузера равно 0.
Пусть также значение переменной "Counter", которое мы видим в окне браузера после нажатия кнопки равно 50.

Вопрос - можем ли мы быть уверенными в том, что:

50 = 49 + результат_нажатия_кнопки_в_окне_нашего_браузера, или
50 = 50, а результат_нажатия_кнопки_в_окне_нашего_браузера_где_то_потерялся?

[Aprox]

Сразу пара вопросов..

1. Сколько удаленных пользователей Ваш прибор может обслужить одновременно?

В теории- число клиентов ограничено лишь диапазоном физических MAC адресов. Hо на практике я встречался только с распределенными системами, когда клиент один, например SCADA на компьютере, а серверов много, несколько десятков- удаленные приборы управления и сбора информации.

2. Реализован ли в вашем приборе механизм транзакций?

Поясню суть второго вопроса подробнее..

Допустим, с Вашим прибором через удаленные терминалы могут одновременно работать 100 операторов.
Допустим также, что в программе прибора существует ULONG переменная "Counter" и каждый из операторов может нажатием кнопки на HTML-странице в броузере IE увеличить значение переменной "Counter" на единицу. (Т.е. "отправить команду").
Пусть начальное значение переменной "Counter", которое мы видим в окне браузера равно 0.
Пусть также значение переменной "Counter", которое мы видим в окне браузера после нажатия кнопки равно 50.

Вопрос - можем ли мы быть уверенными в том, что:

50 = 49 + результат_нажатия_кнопки_в_окне_нашего_браузера, или
50 = 50, а результат_нажатия_кнопки_в_окне_нашего_браузера_где_то_потерялся?

В окне броузера будет отображен установленное оператором значение. Hо в удаленном приборе это не гарантировано, поскольку позже управление может быть перезаписано другим оператором с другого клиента. Однако, если предусмотрен периодический Reload страницы, то все операторы спустя некоторое время увидят фактическое значение управления в удаленном приборе.

Необходимо напомнить, что я имею ввиду локальные сети в промышленной и научно-технической сферах. Типичное для таких сетей- один клиент и много серверов. В настоящий момент, единственное, что сдерживает применение Ethernet в таких сетях,- это избыточные навороты с протоколами и TCP/IP стеками. Мне представляется, переход к Raw-пакетам в данном случае выглядит разумным.