Не хакеры ломать будут, а боты и вообще все соседи.
Будут во первых непрерывно сканировать порты.
Будет идти непрерывный широковещательный трафик от роутеров и прочей инфраструктуры.
Потом будут непрерывно долбить по HTTP, Telnet, FTP и т.д.
Серверу все время надо будет парсить идиотские запросы по HTTP.
В конце концов сервер упадет либо из-за нехватки памяти либо из-за ошибки в парсере.
Либо сам встроенный сервер занесут в черный список за неадекватные ответы.
Обрезание трафика по email уже обычное дело.
С провайдерами приходится ругаться чтобы дивайсы могли отправлять емайлы беспрепятственно.
Ну а Flash (вернее файловые носители на Flash) рухнет от износа.

что то новенькое.. а откуда такое ограничение то???
(дописал)я не обратил внимание на uIP изначально - именно реализация протокола накладывает ограничение. само железное решение не причём...
на 51+CS8900A подымал вэб сервак - ограничений не наблюдал. доводил до 100 далее не интересно...




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

по поводу что и каких ресурсов не хватит - если делаете стэк с учётом именно такой нагрузки - проблем НЕ будет. Вам никто не мешает сделать анализ на ликвидность приходящих пакетов, в том числе и по временному признаку. В чём проблема то???




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

Сообщение отредактировал kolobok0 - Jul 27 2012, 12:48

На нормальных осях есть нетфильтры - вся эта левая шелуха отметается, настройка их ~ +5 минут к времени работы над проектом итог - минут 20 работы.

Сообщение отредактировал sasamy - Jul 27 2012, 12:49

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

Думаете обладаете телепатическими способностями?
Нет, майлы не проходили потому что между ними был слишком короткий интервал.
Эвристика провайдера однако..




А здесь другая эвристика.
На примитивных МК ничего не записывающих во время или на старте сессий, и не дампирующих крахи нормальный WEB сервер не сделать.



Да, лучше год потерять, но зато потом за 20 мин долететь

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

Сервер то получается, но уж больно сложно поддается программированию. Там проблема хранения/обработки последовательных данных HTTP протокола. Если в PC памяти достаточно для формирования ответа сервера целиком, то на базе PIC контроллеров это дается очень не легко, приходится формировать ответ сервера только фрагментарно из-за ограничений в памяти и буферов малой длины.
В общем я несколько лет делал сервера для PC поддерживающие динамический контент. Называлось это - удаленный пользовательский интерфейс. Сейчас в основном используют PHP. Но когда попытался сделать мини подобие для PIC, был в шоке от ограниченности ресурсов. Возможно еще продолжу подобные исследования.

На 'писюке' для этого ставят firewall'ы и прочее. Делают WEB серверы, расчитанные на большое количество подключений и нагрузку.
Имелось в виду, что все это можно сделать и на встраиваемой железке, только это уже будет не встраиваемая железка с встроенным WEB сервером, в полновесный WEB сервер с небольшим довесков в виде встроенной железки
Но все это ТС не грозит, т.к. он озвучил требование, что его железка будет включаться только в локальной сети.

PS. Есть такой встроенный WEB сервер - GoAhead, видел его во многих роутерах и прочем сетевом хламе

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

В целом, задача не "для маленьких", но это лишь вопрос желания.

P.S. От дальнейших подробностей - воздержусь : )

Сообщение отредактировал _sv_ - Jul 30 2012, 14:28

один тупой вопрос:
У Вас лично есть хоть одна взломанная система, под заказчика?

Raspberry Pi. An ARM GNU/Linux box for $25. Take a byte! С эзернетом он стоит $35. Продается в Фарнелле.

Замечательная ссылка однако.
Сервер имеет CGI, SSL, аутентификацию и даже серверный JavaScript с поддержкой ASP файлов.
А главное портируется под любую RTOS. Надо изменить только пару вызовов сервисов RTOS. Хоть на FreeRTOS портируй.
256К RAM хватит за глаза такому серверу если не увлекаться CGI.

Не совсем в тему.. Может кто-нибудь подскажет более-менее приличный FTP сервер, чтобы на FreeRTOS положить без заморочек?

Мы делали сервер на LPC1768 c кайловской библиотекой. Для динамического отображения использовали json. Но у нас задачи наверное попроще - отобразить как работает прибор, поменять пару параметров, обновить софт. Число коннектов ограничили двумя. Вообще если хочется много коннектров нужна внешняя память. Для нашего сервера использовали совсем немного памяти примерно 100k flash + 10kram, потому что в основном память для приложении использована.

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


Не могу понять, а каких усилий будет стоить написание динамичного сайта для этого сервера. И кто должен прилагать эти усилия: я или можно привлечь обычного web-программиста. Т.е. можно ли применить стандартные на текущий момент решения для web разработки.