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 тут самое оно, особенно если (а иногда важная команда должна быть обязательно доставлена, причем выполнена только один раз).

[Rst7]

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

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

[tag]

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

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

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

struct
{
...
} mes;

/* ожидаем прием пакета */
while(recv(socket_fd, (void *) &mes, sizeof(mes), MSG_PEEK) < sizeof(mes));

/* считываем пакет */
recv(new_us, (void *) &mes, sizeof(mes), 0);

[iosifk]

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

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


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

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

Ну, вот вроде далее все просто. Считайте что если Ваши машины сумеют разобраться с ВАШИМ протоколом, то все остальное только передача сообщений....

Удачи!

[KRS]

А TCP потоковый! Он мне даже не скажет, где одна команда закончилась и новая началась. Т.е. мне надо вводить некий механизм синхронизации чтобы отлавливать начало очередного пакета.

TCP гарантирует, последовательность и целостность данных, ни порядок не поменяется и не один байт не пропадет. Но реализация TCP довольно сложна, и требует довольно много ресурсов. Самое простое взять lwip ucip или что то подобное.

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

[gladov]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Postoroniy_V]

Это значит, что работа с TCP сокетом полностью аналогична работе с файлом, т.е. делаю тот же read() которому Я говорю, сколько байт вычитать из сокета, а не ОН МНЕ сообщает, сколько пришло. Конечно, можно его попросить не блокироваться и отдавать не столько, сколько я попросил, а столько, сколько пришло сейчас, но тогда будет срабатывать на недоконца доставленные пакеты (фрагменты).
Вопрос не ясен. Я посылаю именно столько, сколько нужно, а вот приемник совсем не знает сколько ему сейчас нужно принять.
Читал, и не только это.
Порядок безусловно будет соблюден, но кто гарантирует, что байт с длиной будет принят правильно? Знаете, что ТСР проверяет целостность данных даже не по CRC? Там контрольная сумма считается гораздо проще и давно признана ненадежной.
Значит, что фрагмент данных будет доставлен и что он окажется в нужном месте потока, но, повторюсь, НЕ ГАРАНТИРУЕТ достоверность доставленных данных. Да, вероятность мала, но она есть!
Это и ежику понятно, только вот что вы будете делать, если побьется очередной байт с длиной пакета? Если бы из-за этого я потерял один пакет - ерунда. Но связь будет оборвана ПОЛНОСТЬЮ. Отсюда и идея с байт-стаффингом.
И, кстати, битые байты в пакетах ТСР ситуация не гипотетическая. Коллега на эти грабли наступал. Случается крайне редко, но бывает.

про битые пакеты не понятно, куда смотрит МАК уровень?если в пакете исказилась длина пакета
и если Вы ловите такие пакеты, то ИМХО всё равно что использовать хоть ТСР хоть UDP
какая разница?

[Rst7]

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

У вас же Эзернет. Поверх этой красоты есть еще и CRC32 самого эзернета. Вам мало? Тогда положите в каждый свой пакет еще и свою контрольную сумму. При неправильном байте длинны, например, у вас не срастется ваша CRC. Оптимально в этом случае закрыть соединение (причем с флагом RST), а потом открыть его заново. Но, поверьте, такой ситуации у вас не будет, а если будет - то надо выкинуть используемый стек или MAC-уровень.

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

[Aprox]

Может, я чего-то не понимаю в тонкостях задачи, но по-моему самый распространённый метод управления прибором по Ethernet- это встроенный в прибор WEB сервер. Максимальная степень отлаженности решения и практически стопроцентная готовность. Ничего не надо изобретать самому и вообще разбираться с TCP и UDP. Если кроме управления нужно еще принимать данные от прибора, то на помощь приходят "HTTPзапросы", которые используются в броузерах по технологии Ajax или Flash.

[Rst7]

Может, я чего-то не понимаю в тонкостях задачи, но по-моему самый распространённый метод управления прибором по Ethernet- это встроенный в прибор WEB сервер.

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

Максимальная степень отлаженности решения и практически стопроцентная готовность. Ничего не надо изобретать самому и вообще разбираться с TCP и UDP.

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

Если кроме управления нужно еще принимать данные от прибора, то на помощь приходят "HTTPзапросы", которые используются в броузерах по технологии Ajax или Flash.

А вот это костыль, предназначеный для преодоления изначально статической природы HTTP/HTML. Который совсем не нужен для того, чтобы носить данные из прибора в обрабатывающую программу. Да и вообще, термин "HTTP-запросы" не есть прерогатива аякса или флеша, это и есть название одной из стадий обмена информацией по протоколу HTTP.

И вообще, я считаю, что организовывать web-сервер в приборе имеет смысл только для избавления от софта верхнего уровня на компе, причем софт этот используется для визуализации данных. В этом случае браузер используется в качестве некоего терминала, а вам не надо писать софт верхнего уровня (актуально, например, если хост может работать как под линухом, там и под виндой). Однако, тут много своих граблей - например, разная интрерпретация разными браузерами HTML-кода, особенно, с новомодными примочками, или реализация digest-авторизации - везде разная, и полностью RFC не соответствующая (хорошо, если просто чего-то не выполняется, Опера, например, не поддерживает ключ next_nonce, а IE только с 7го начал поддерживать такую авторизацию, да только совсем вольно трактует мелкософт понятие URL, а для своего прибора еле нашел консольный браузер под никсы, который вообще асиливает digest - ведь одмины у нас страсть как не любят окошки )... короче, грабли, грабли, и еще грабли...

[tag]

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

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

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

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

...есть вероятность что на Вас может упасть метеорит

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

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

[gladov]

...есть вероятность что на Вас может упасть метеорит

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

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

Полностью согласен. HTTP в данном случае принесет лишние бестолковые проблемы. Вообще, огромное спасибо всем и особенно Rst7 за консультации на тему.

[vvs157]

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

Используйте протокол Telnet. Прост до неприличия, работать при желании (отладка, например) можно из большинства терминальных программ для связи по RS-232. Достоверность данных обеспечивается протоколом TCP и можете не заморачивать себе голову. Я ни разу не видел, чтоб при связи по Telnet'у данные искажались даже на очень полохой линии.

[Rst7]

Используйте протокол Telnet. Прост до неприличия, работать при желании (отладка, например) можно из большинства терминальных программ для связи по RS-232. Достоверность данных обеспечивается протоколом TCP и можете не заморачивать себе голову. Я ни разу не видел, чтоб при связи по Telnet'у данные искажались даже на очень полохой линии.

Вот тут тоже не согласен. Зачем человеку брать бинарные данные, делать из них ASCII-коды, передавать, на приемной стороне делать из ASCII-данных бинарные и обрабатывать их дальше? Это все ради того, чтобы на начальном этапе увидеть эти данные в Telnet? А потом будет просто какой-то софт верхнего уровня? Да и отладить сейчас софт на большом брате проблем нет никаких - все среды с отладчиками, терминальная отладка особо не нужна.

Результат повальных увлечений терминалом вообще плачевный - просто так пропускную способность канала опускают в два раза, а потом в других темах меряются пиписьками, как быстрее напечатать unsigned short в десятичную строку . Хотя struct OUT_DATA {... ... .. . } buf; send(sock,&buf,sizeof(buf),0) проще всего...

[vvs157]

Вот тут тоже не согласен. Зачем человеку брать бинарные данные, делать из них ASCII-коды, передавать, на приемной стороне делать из ASCII-данных бинарные и обрабатывать их дальше?

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

[Aprox]

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

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

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

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

А вот это костыль, предназначеный для преодоления изначально статической природы HTTP/HTML. Который совсем не нужен для того, чтобы носить данные из прибора в обрабатывающую программу. Да и вообще, термин "HTTP-запросы" не есть прерогатива аякса или флеша, это и есть название одной из стадий обмена информацией по протоколу HTTP.

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

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

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

Однако, тут много своих граблей - например, разная интрерпретация разными браузерами HTML-кода, особенно, с новомодными примочками, или реализация digest-авторизации - везде разная, и полностью RFC не соответствующая (хорошо, если просто чего-то не выполняется, Опера, например, не поддерживает ключ next_nonce, а IE только с 7го начал поддерживать такую авторизацию, да только совсем вольно трактует мелкософт понятие URL, а для своего прибора еле нашел консольный браузер под никсы, который вообще асиливает digest - ведь одмины у нас страсть как не любят окошки )... короче, грабли, грабли, и еще грабли...

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

[Rst7]

Вопрос традиций

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

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

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

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

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

IE и Firefox

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

[vvs157]

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

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

[Rst7]

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

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

[Aprox]

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

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

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

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

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

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

[Kirill Frolov]

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

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

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

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

Т.е. мне надо вводить некий механизм синхронизации чтобы отлавливать начало очередного пакета.

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

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

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

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

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

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

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

man ifconfig /mtu

Бред.

Вопрос традиций. Подавляющее число приборов с IEEE-488 (GP-IB) работают именно в текстовом формате

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

[gladov]

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

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

[vvs157]

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

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

[Kirill Frolov]

Полностью согласен с Rst7. Никаких протоколов верхнего уровня (поверх ТСР) вообще нет смысла городить.

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

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

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

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

Я, например очень не люблю приборы, с которомы можно общаться только посредством авторской программы.

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

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

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

[Rst7]

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

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

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

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

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

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

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

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

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

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

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

[blackfin]

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

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

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

[vvs157]

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

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

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

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

[Kirill Frolov]

Я тоже больше денег заработаю, если просто передам send'ом структуру и все, а не буду неделю изготавливать фронт-энд для даже просто телнета.

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

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

В контексте вопроса автора.. Если можно, попроще..

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

А производители измерительного оборудивания и не знают, что они обречены, ибо живут "во вчерашнем дне" обеспечивая ASCII интерфейс.

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

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

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

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

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

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

[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-пакетам в данном случае выглядит разумным.

[blackfin]

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

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

Типичное для таких сетей - один клиент и много серверов.

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

В настоящий момент, единственное, что сдерживает применение Ethernet в таких сетях,- это избыточные навороты с протоколами и TCP/IP стеками.

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

Мне представляется, переход к Raw-пакетам в данном случае выглядит разумным.

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

[GL_basik]

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

[Aprox]

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

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

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

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

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

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

[blackfin]

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

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

При этом появление новых клиентов в сети недопустимо, т.к. означает смену топологии. Заказчик против.

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

Можно смириться с избыточностью софта и подобрать нужный МК, но поднять скорость передачи данных, увеличить загрузку сети, практически невозможно.

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

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

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

[Rst7]

но ограничение на максимальное кол-во хостов в Вашей локальной сети остается - максимум 96 хостов

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

[blackfin]

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

А что, существуют switch'и на большее число портов?

[Rst7]

А что, существуют switch'и на большее число портов?

А что, соединить два или более свичей - это уже не одна сеть?

[Aprox]

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

Да, на такую возможность следует заложиться. Hапример, ограничить число подключений к серверу одной штукой.

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

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

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

Да, сегмент switch<->PC предполагается делать на 1Г Ethernet. Такие свитчи имеются а продаже. Сейчас я не готов обсуждать, какие подводные камни ждут на этом пути. Будем пробовать, и набивать шишки.

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

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

[prottoss]

Привет всем!

Прочитал в теме про упоминание AJAX - если кто то занимался этим, может наставит на истинный путь. Задача у меня, как говорили выше, классическая. Управление девайсом через WEB-интерфейс. AJAX привлекает:

1. Малая нагрузка на контроллер со стороны Ethernet

2. Динамическое изменение данных на странице без ее перезагрузки.

Возможно у кого нибудь есть наработки по этой библиотеке. Пробовал работать с JsHTTPRequest - эта библа построенна на основе AJAX - но она заточена под крупные сервера с поддержкой PHP.

[Rst7]

Возможно у кого нибудь есть наработки по этой библиотеке.

Наработок нет. Я смотрел, чего там происходит, вроде не особо сложно реализовать. Самого в принципе интересует, можем скооперироваться...

[prottoss]

Наработок нет. Я смотрел, чего там происходит, вроде не особо сложно реализовать. Самого в принципе интересует, можем скооперироваться...

Я , честно говоря, не сильно знаком с JavaScript - сложного там ничего нет, но не знание методов объектов и прочих фичей напрягает, потому как двигаю с нуля проект. Посмотрев на некоторые библиотеки, сделал вывод, что написать надо свою, компактную, потому как меньше 15 кБ не видел, да и те, как говорил выше заточенны под взаиможействие с РНР на серверной стороне... Вот счас грызу XMLHTTPRequest - это, по моему, основной объект, через который можно что то серверу послать.

[prottoss]

Все оказалось на много проще, чем я думал....пока Вот HTML-страница

Код

<script type="text/javascript" language="JavaScript">
//Кроссбраузерная функция создания XMLHttpRequest:
function getXmlHttp()
{
var xmlhttp;
  try
{
    xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
  }
catch(e)
{
   try
  {
      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    }
  catch (E)
  {
      xmlhttp = false;
    }
  }
  if(!xmlhttp && typeof XMLHttpRequest!='undefined')
{
    xmlhttp = new XMLHttpRequest();
  }
  return xmlhttp;
}

function doLoad(send_value)
{
var xmlhttp = getXmlHttp();
xmlhttp.open('POST', 'http://192.168.1.4./test.htm'+send_value, true);
xmlhttp.onreadystatechange = function()
{
   if(xmlhttp.readyState == 4)
  {
      if(xmlhttp.status == 200)
    {
        document.getElementById('recv_txt').value = xmlhttp.responseText;
      }
   }
}
  xmlhttp.send(null);
}
</script>

<form method="post" id="f" enctype="multipart/form-data" onsubmit="return false">
Send Text: <input type="text" name = "stxt" id="send_txt">
<input type="button" value="Send" id="snd" onclick="doLoad(document.getElementById('send_txt').value)">
Recv Text: <input type="text" name= "rtxt" id="recv_txt">
</form>

Я думаю, объяснений не надо. Если что то не понятно - смотрите здесь

http://javascript.itsoft.ru/ и здесь http://xmlhttprequest.ru/#use

Все, больше ниего не надо. Вот лог общения при вводе строки и нажатии на кнопку Send

POST /test.htm1234567890 HTTP/1.1
Accept: */*
Accept-Language: ru
Referer: file://E:\TEMP\2\index.htm
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 192.168.1.4.
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.0 200 OK
Server: TinyNET 3.0 server SAM7X256-EK based system.
Connection: Close

Hello, World!

[Aprox]

Привет всем!

Прочитал в теме про упоминание AJAX - если кто то занимался этим, может наставит на истинный путь. Задача у меня, как говорили выше, классическая. Управление девайсом через WEB-интерфейс. AJAX привлекает:

1. Малая нагрузка на контроллер со стороны Ethernet

2. Динамическое изменение данных на странице без ее перезагрузки.

Возможно у кого нибудь есть наработки по этой библиотеке. Пробовал работать с JsHTTPRequest - эта библа построенна на основе AJAX - но она заточена под крупные сервера с поддержкой PHP.

Я пользовал AJAX для указанных задач. Из всех библиотек больше всего понравилась простотой и компактностью XHConn, представленная в http://xkr.us/code/javascript/XHConn/ Посмотрите этот сайт, там есть и пример.

[Aprox]

Я пользовал AJAX для указанных задач. Из всех библиотек больше всего понравилась простотой и компактностью XHConn, представленная в http://xkr.us/code/javascript/XHConn/ Посмотрите этот сайт, там есть и пример.

Необходимо добавить, что когда я рыскал в поисках подходящих инструментов для динамической подгрузки страниц WEB-сервера, то понял- это целый отдельный мир WEB-дизайна, в котором запросто утонуть имея другую профессию, например, электронщика- схемотехника. Можно запросто забыть, о чем собственно речь. Поэтому решил не углубляться в дебри, а ограничился минимальным- декларацией класса XHConn и работой с DOM в javasckript. Сама же страница и ее элементы рисуются традиционно, через HTML. По-моему, это самый быстрый и простой путь освоения AJAX непрофессионалу WEB-дизайна.

Если есть время на освоение нового, то советую обратить внимание на Flash -технологии создания WEB-страниц. Это достойный конкурент AJAX. И по гибкости, и по графике, и по управлению, и по динамике, и по компактности. Плюс к тому, не зависит от заморочек броузеров. В Flash уже всторены разные классы по обмену данными http-запросами. Причем, от самого простых, до сложных XML с автоматическим парсингом. Hо увлекаться схемотехнику не следует, а то можно запросто утонуть.

[prottoss]

дабы не утонуть пока решил ограничится тем, о чем говорил выше - XMLHTTPRequest - пока для меня самое то. Полан взаимодействия примерно такой:

1.Клиент формирует запрос POST/GET на скрипт-файл c параметрами. Например GET /form1.sc

2. На стороне сервера открывается соответсвующий файл и парсится.

3. При необходимости выдаются данные клиенту...

По третьему пункту есть вариант выдавать (если GET-запрос) не данные а сразу функцию JavaScript которая рассаживает данные в форме на свои места.



Что нужно на сервере:

1. Таблица описателей переменных.

2. Функции работы с этими переменными.



Элемент таблицы может выглядеть примерно так:

Код

/* MIB object class */
typedef struct __MIB_OBJ
{
   MIB_TYPE type; /* Type of object */
MIB_ACCESS access; /* Access type */

UINT16 id;/* object ID */
   CHAR   *name; /* Name - zero terminated string */
void   *value; /* Value */
UINT16   n_len; /* Name length */
UINT16   v_len; /* Value length */

} MIB_OBJ;

Идентификация переменной по ID или name. Таким образом ЮЗЕРУ необходимо знать имена переменных в девайсе и/или их идентификаторы. ЮЗЕР создает HTML-файл и скрипты для того, что бы сервер знал, как располагать в ответе переменные и стоит ли их располагать там вообще. Кроме того сервер по таблице может определять, как работать с переменными.



Когда все отработаю, естественно встанет вопрос о защите данных. Здесь возможен вариант проверки ID сессиии.... Или нет? Или еще чего? Пока не знаю

[Rst7]

Когда все отработаю, естественно встанет вопрос о защите данных. Здесь возможен вариант проверки ID сессиии.... Или нет? Или еще чего? Пока не знаю

Методов есть много. Один из них - это действительно ID сессии. Однако большой минус, что логин и пасс надо передавать в открытом виде. Тут на помощь может прийти Digest-авторизация - там достаточно безопасный логин, и можно сделать так, что любой доступ к страничке будет с аутентификацией, а пользователю ввести логин с паролем нужно будет только один раз. В реализации - достаточно просто, из криптографии нужен только MD5.

Однако, такие способы не могут противостоять атакам Man-In-The-Middle (т.е. перехват и подмена траффика). Если надо противостоять таким методам взлома, надо делать SSL/TLS (HTTPS). Есть еще способ, который представляет из себя некую комбинацию. Все Ваши устройства находятся в одной сети (ну скажем /24), отделенной от большого итранета/интернета роутером. На роутере поднимается SSH-туннель в подсетку и более никакого доступа не дается. Тогда по большой сети данные ходят безопасно. Реализовывать SSL/TLS или SSH на камне в каждом устройстве я бы поберегся - надо реализовывать кучу криптографии, протоколы и т.д. - тут хорошим решением будет свой роутер (ну хоть на Rainbow ) с поднятым линухом.