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

[gladov]

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

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

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

[Rst7]

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

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

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

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

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

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

IE и Firefox

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

[vvs157]

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

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

[Rst7]

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

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

[gladov]

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

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

[vvs157]

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

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