Вам придется по любому учить HTML как минимум, для красивой динамики надо будет еще узнать про технологию AJAX (AJAH скорее в вашем случае), научиться понимать JavaScript и понимать и использовать универсальные библиотеки на JavaScript типа jQuery.
Это на стороне браузера.
На стороне сервера вам придется изучить технологию CGI и научиться связывать CGI запросы с железом на языке C-и, ну и опять разобраться с функциями которые дает серверный JavaScript.

Причем все это надо делать независимо от того насколько крутую платформу вы выберете, промышленный PC или PIC контроллер.
GoAhead интересен тем, что его исходники очень компактные, открытые и легко интегрируемые.

Стандартных решения для WEB чтобы напрямую связывали WEB сервер с железом и прикладными приложениями я что-то не видел.
Поэтому сайтостроители с опытом PHP и СMS-ов не подойдут. Скорее нужны дизайнеры с опытом JavaScript для стороны браузера.
На стороне сервера увы embedded программисту придется все делать самому.

Разложили по полочкам мои прыгающие мысли.


Большой минус для меня. Мне кажется, развивать и поддерживать сайт должен web программист.

Когда говорят WEB программист, все обычно представляют себе сервер Apache c PHP и MySQL ну или MS IIS7 c ASP .NET
При этом программисты потирают руки и представляют себе как притянут за собой еще и подготовленную под себя CMS (Content Management System) .

Если дать такому программисту embedded WEB сервер он будет в ступоре.
Многие из них даже HTML толком не знают, так как в CMS весь дизайн уже готов.
Но от CMS во встроенном сервере никакого толка если он должен показывать динамические данные от железа и работать не с MySQL, а с файловыми структурами на Serial Flash.
В принципе можно напряч WEB дизайнера чтобы он сделал макет страниц, но конкретно состав аргументов CGI запросов, сценарии обработки ошибок, валидацию данных, выборку данных для отображений на графиках и т.д. может сделать только embedded программист.
И это относится к любому встроенному WEB серверу, какой бы не выбрали.

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

Похоже, Вы не совсем понимаете как это работает. Для такой атаки надо детально знать код.
Просто так stack overflow вызвать НЕВОЗМОЖНО.




То о чем Вы говорите не имеет никакого отношения к ембеддед вебсерверу.
Все тоже самое будет происходить и с обычным PC.
Файрволл не уменьшает количество обращений и не предотвращает ДОС атаки.
Единственно, что это немного разгружает процессор, но имплементация такого файрволла
на микроконтроллере займет пару строчек.

А в чем проблема-то? Надежность разъема с золочеными контактами не устраивает? В мобильниках и фотиках работает надежно, а уж как только их не бросают. В любом случае это намного надежнее, чем обычный винчестер. Но уж если непременно хотите встроенную флэшку, то прикрутите сами снаружи. Разъем расширения с SPI+I2C там есть.

Или вот еще вариант: http://netduino.com/ Правда, послабее и подороже. Но зато железо открыто, можете переделать по-своему.

Обычный PC обычен только для дилетанта, а разработчика со стороны даже близко не подпустят к технологии его сетевых чипов.
Подите найдите описание контроллера Etherneta на тот же Raspberry Pi.
Это черные ящики. Если он начнет падать, то есть полная гарантия что вы никогда не узнаете почему.

Файрволл полностью может закрыть трафик к внутреннему серверу защитив его от перегрузок.
Софтварная импмлементация простейшего файрвола довольно сложна (сложнее простейшего WEB сервера) и ресурсоемка.
Но мы наверно о разном

На PC файрволл и сетевой чип - это параллельные прямые.
Вся коммуникация идет через драйвер и кернел API.
Во вторых, закрытость чипа определяется политикой компании производителя, а не наличием/присутствием его в PC.
Broadcom знаменит своим "не пущать!", так что Ваш пример ничего не доказывает.
В сурсах Линукса море драйверов для разных нетворк чипов.
Зачем они правда нужны для имплементации файрволла на PC, я не понял.

Да, наверное, мы о разном. Я говорю конкретно о теме, Вы же предлагаете подменить ембеддед вебсервер целой сетью с файрволлом на входе,
судя по Вашему посту.

Кстати, простейший файрволл тупо сравнивает IP источника и не пропускает пакеты с запрещеным IP, где Вы видели проще HTTP server?

Эт что, в надежде что линукс большой и такие голословные утверждения никто не проверит?
Нут так в директории линукса с linux.org относительно сетевых физических контроллеров только 19 файлов!
Причем такого размера, что на драйвера не тянут. Это вообще ноль!
Конкретно файлов касающихся сетевых чипов там можно на пальцах пересчитать и видно, что функциональность их обрезана.

Embedded web cервер не файрволами надо обкладывать, а вообще нельзя в публичный интернет выставлять.
Да и функцию файрвола вы в моем контексте исказили.

а как посчитали количество? у меня в /usr/src/linux/drivers/net побольше всего, подскажите, pls где туплю

Сообщение отредактировал Idle - Aug 2 2012, 13:07

А что за сайт предполагается на встраиваемом устройстве?
У меня дома встраиваемым устройством является контроллер ванной комнаты с возможностью через интернет по пути домой заказать набранную ванну с заданной температурой воды.
Так вот я захожу на динамический сайт с обычным CMS расположенный на хостинге, захожу на страницу ванной комнаты и задаю параметры. Контроллер ванной комнаты так же периодически обращается к сайту на хостинге и если обнаруживает измененные параметры, то принимает их и выполняет. Так я избавил контроллер с ограничеными ресурсами от необходимости обрабатывать WEB интерфейс, значительно упростил систему.
Возможно вам необходимо что-то подобное.

Интересно!
Можно пару вопросов?
1. Какое у Вас подключение к провайдеру? (DSL, ETHERNET, WiMax,...)
2. IP-адрес выделенный?

Спасибо!

... да. Это вариант. Надо подумать.

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

а это не оверкилл? может достаточно верхнего слива в сифоне?

/usr/src/linux/drivers/net/phy

а то в /net там записаны IrDA, CAN, WiMax и т.д.



Хостинг выбирают с Node.js. Тогда можно делать управление в риалтайме.

Но в моих дивайсах делается по другому.
По VPN дивайсы через NAT сервер провайдера (так стандартно бывает при GPRS соединении) по VPN организуют постоянный канал к домашней сети (можно просто роутер с поддержкой VPN) и там объявляются на фиксированных частных IP адресах.
Когда надо поуправлять дивайсом из публичного интернета, заходим опять же по VPN в свою домашнюю (частную, корпоративную) сеть и получаем доступ к WEB серверу дивайса по известному частному адресу.
В данном случае дивайсы защищены NAT сервером провайдера. Домашняя сеть защищена домашним роутером. Обмен же происходит в риалтайме.