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

А вопрос у меня такой. Есть классическая ситуация - некоторое устройство управляется компом по сети, причем находятся они в одной локалке, т.е. все быстро и условно надежно. Устройство получает от компа команды, возвращает результаты замеров, статусы и проч. Встает вопрос что использовать: 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) проще всего...

Вопрос традиций. Подавляющее число приборов с IEEE-488 (GP-IB) работают именно в текстовом формате (Agilent, Tektronix как пример). И когда у этих приборов появляется сетевой порт - система команд обычно не меняется.

Вообще-то, встроенные в прибор WEB сервера используют не статический, а динамический HTML.



Уже пару лет использую в своих приборах модуль MOD5270 фирмы NetBurner площадью с пачку сигарет и ценой в $80. В нем есть практически все, что надо для развитого управления прибором, TCP/IP стек и WEB сервер с динамическим HTML. Программируется на GNU C++. Прекрасно работает, никаких нареканий. Я не считаю этот модуль чем-то очень серьезным по сложности и цене. Кроме того, появилось много кристаллов с ядром ARM9, и для многих в качестве стандартного примера прилагается WEB сервер на С. Иными словами, совсем не так угрюмо и мрачно обстоит дело с HW для web-серверов.



В технологии flash мне удалось реализовать что-то вроде осциллографа, данные для прорисовки которому поступали от удаленного WEB сервера. Запрос и прием данных работает с очень приличной скоростью. Я могу ошибаться в терминах, но это работает.



Мне представляется, web-сервер позволяет экономить время, использовать готовые технические решения и не тратить силы на изобретение велосипедов. Данный тред тому подтверждение. А что касается обработки поступающих данных, то JavaScript в HTML или ActionScript во Flash вроде удовлетворяют стандартные запросы пользователя.



Hе знаю. Ни разу не сталкивался с такими проблемами. Рисуешь странички в DreamWeaver или в Macromedia Flash, тестируешь в IE и Firefox, закачиваешь в web-server, и все потом нормально работает в тех же самых броузерах на самых разных компах. Hу разве что, придется в IE разрешить ActiveX, или отключить блокировку POP-up окон. digest-авторизацию не использую, поэтому с проблемами не знаком.

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



HTML статичен по определению. Все остальное - сугубо костыли для обеспечения динамики.



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



Есть еще много разных других браузеров.

Весьма современное телекоммуникационное оборудование и по сей день очень часто имеет порт для конфигурирования с Telnet'ом. По поводу традиций. Эта традиция может считаться устаревшей только при замене на WEB интерфейс, так как иметь под каждое устройство специальую программу крайне не удобно. Моя точка зрения - ни при каких условиях уупрощение жизни программиста или разработчика не должно идти в ущерб интересов потребителя.

Давай мы попробуем узнать у автора темы, нужна ли ему возможность работы через Telnet, а точнее - пользоваться Telnet'ом для просмотра данных, передаваемых прибором, и отправки команд этому прибору. Мне что-то подсказывает - не нужна. Правда, он нас за ответы уже поблагодарил, но думаю, еще сюда зайдет.

Технология Ajax для JavaScript была как раз и рождена для придания пущей динамики страницам на HTML.

Да, буду всю обработку делать на ActionScript для Flash. Изюминка в том, что: и данные, и программа обработки- загружаются в компьютер из удаленного прибора в тот момент, когда броузером входите на страничку WEB-сервера. Таким образом, всегда существует полное соответствие версий данных и программы обработки. Потому, что лежат в одном месте, неразрывно связанные с прибором. Поставил другой прибор на это место- система будет продолжать работать. Очевидный плюс для сопровождения изделия, для наращивания или модификации. Что касается вашего примера с реализацией пид-регулятора на центральном компьютере, то выглядит он слегка архаично. Это задача локального контроллера.

Есть конечно. Hо другие на практике мне не встречались. И требования от заказчика на другие броузеры не поступало.

TCP соединения тоже бывают рвуться. Особенно в ОС windows...



Одна команда закончилась в её конце, а следующий байт -- следующая команда.
Вроде очевидно...



ЗАЧЕМ? Можете ввести байт-разделитель (например \n, если команды текстом даются).
Можете использовать "признак срочных данных" для маркировки каждой команды, если они не идут непрерывным потоком.



Но ведь TCP -- защищённый протокол и всё такое? А если "одна из сторон ошибётся", то она и не только в этом может ошибиться.

На самом деле, первое что приходит в голову -- команды текстом, строка -- команда. Проблем нет.



Это называется телнет. Так тяжело, аж неподъёмно. Я всё же советую посмотреть/почитать о принципах работы telnet и rlogin. А также ftp ещё.





man ifconfig /mtu

Бред.





Для этого ум иметь надо. А он приходит только с большим опытом, да и то не всегда.

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

Этот прибор для Вас лично, или его планируется тиражировать? Если тиражировать - то поинтересуйтесь мнением пользователей, которым приходится подобное оборудование обслуживать.
Я, например очень не люблю приборы, с которомы можно общаться только посредством авторской программы. Пример - программа по Win, а у меня Linux или программа по каким-то причинам перестала запускаться под последним творением M$.

Можно конечно ещё в книжку ткнуть пальцем, где про 7-уровневую модель и всё такое. "Никаких протоколов кроме 802.3 не надо..." -- вполне эквиэвалентное по абсурдности утверждение.

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




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





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

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

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

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



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



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



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



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

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

Прошу прощения за некоторую тормознутость, но что следует из Вашего фейерверка умозаключений?
В контексте вопроса автора.. Если можно, попроще..

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


Это Вы про что? Предлагаете сниффер как универсальное средство отладки и мониторинга межприборного взаимодействия? Или быстренько изучить работу с сокетами и под любую задачу лихо писать программку на С? Да Вы просто в душе хакер!
А производители измерительного оборудивания и не знают, что они обречены, ибо живут "во вчерашнем дне" обеспечивая ASCII интерфейс.

Ага, структуру... Я б вам не доверил.

Не неделю. Пол-часа.





Я не нанимался отвечать на конкретные вопросы. Это, наверное, и многим тут совершенно не интересно. А пришёл, так, языком потрепать.




В чём-то он прав. Это вчерашний день, а сегодня модно врукопашную на C структуру в сокет засовывать.
Только кто сказал, что день вчерашний безусловно так уж и плох? Я ж сказал -- ум, опыт надо, и даже этого мало. У дня вчерашнего он есть, на собственных ошибках поо крайней мере.

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



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



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



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

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

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


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

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



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

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

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

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




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

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



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



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



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



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



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



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



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



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



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

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



Какая?


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


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



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



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



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

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



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



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

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

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

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

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

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

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

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

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

Вставлю свои 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, кстати бесплатный. Я сейчас как раз этим занимаюсь и пока все получается нормально.

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Если сеть со временем меняет топологию или расширяется, рано или поздно возникнет ситуация когда два клиента попытаются обратиться к одному серверу.

ИМХО, ничто не сдерживает применение Ethernet Internet'a в таких сетях, ибо никакой избыточности в TCP/IP нет.
Может, есть недостаток ресурсов выбранного МК, но это вопрос грамотности разработчика.

Мне, напротив, это кажется неразумным, но нужно ли спорить о вкусах?

Если есть время сначала создавать устройство, потом писать под него софт, а потом под устройство подстраивать топологию сети, тогда можно использовать все что угодно. Но времени обычно нет. А обычно есть сеть и есть информационная система, которая собирает данные о состоянии сети. Соотвественно при проектировании устройства нужно ориентироваться на стандартные протоколы. Чтоб монтажник мог придти в подъезд обжать кабель подключить девайс и уйти, а дейвайс сам бы себя сконфигурил и вписался в информационную систему. Здесь уж RAW пакетами не обойтись...

Делаю распределенную систему на базе свитча, но не хаба. К свитчу пока нареканий нет.



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



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

Switch, конечно, тоже будет работать, но ограничение на максимальное кол-во хостов в Вашей локальной сети остается - максимум 96 хостов. Возможно, в Вашем конкретном случае это не проблема.


Новые клиенты могут появиться, если пользователь запустит несколько экземпляров браузера на одном компьютере.. Что тогда?


Согласен, если число пакетов в секунду велико, а размер каждого пакета мал, переход к RAW-ethernet пакетам может дать существенный выигрыш в производительности сети.. Но стоит ли рассчитывать на устойчивую работу сети на пределе производительности?

Кроме того, при использовании switch'а лишенного внутреннего буфера для хранения пакетов могут появиться проблемы с коллизиями пакетов в сегменте switch<->PC. Как следствие - потеря пакетов и т.д. и т.п.

Впрочем, насколько мне известно, Вы эту проблему уже обсуждали: подключение устройства к ethernet.

Это откуда такое ограничение?