Вопрос традиций. Подавляющее число приборов с 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 - тоже весьма немалая процедура. Вот отсюда, кстати, и растут ноги упомянутого мной членомерства. Так сколько времени человек будет делать это все? За неделю, я думаю, как раз справится.

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

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




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