Ex "Пинговалка", Вынесено из "Владеем небольшой сеткой" Опции

[Mihail Gluhowche...]

спаять дома 200 плат с заказанными на заводе платами...

евро стоит 42 рубля а доллар 30... давайте вообще перейдем на золото, оно никогда не подешевеет

Здрасте у золота не цена а курс )) Экономика батенька. Недавно оно стоили 250 за унцию

Реально на BF532 но только в партии 10000 штук они тогда по 5.32

[Rst7]

Реально на BF532 но только в партии 10000 штук они тогда по 5.32

Вы, видимо, кроме BF других камней не знаете? Не говоря уже о том, сколько будет стоить его запаять

[Mihail Gluhowche...]

Знаю но все они подороже стоят немного так )) А на него встает линукс и все задачи решаются, тоесть разработка софта сводится к простой компиляции uClinux с параметрами + небольшая програмка которая сохраняет /etc в пару разделов флешки. ARM стоит дороже. MIPS редко получалось быстро собрать ядро и запустить переферию.

Сообщение отредактировал Mihail Gluhowchenko - Jan 12 2009, 09:23

[AlexandrY]

Совать сюда Blackfin - это наиболее бредовая идея из всех предложенных.
Blackfin-ы одни из самых неэффективных процессоров для сетевых приложений.
Греются как утюги, не технологичный корпус, требуют три разных питания, отсутствие внутренней Flash-и, средства отладки либо дубовые либо дорогие.
В программном плане более глючного решения чем uLinux придумать даже трудно.
Как виснет линукс темы возникают регулярно чуть ли не каждую неделю: http://electronix.ru/forum/index.php?showtopic=57717
Скорее всего такие дивайсы сами будут требовать постоянного наблюдения за собой.

Если нужен один ICMP то это потянет любой микроконтроллер с RAM в объеме до 2Кб еще и операционка поместится.
Это могут быть и AVR-ы и MSP и PIC-и и т.д.
Но рекомендовал бы ARM-ы на ядре Cortex как наиболее продвинутые и позволяющие лучше сохранить инвестиции.
Например STM32F101C6T6 стоит те самые 5$ в партии от 200 шт. и могут с успехом изобразить и ICMP и SMTP и Telnet и все что нужно.

Другое дело что я сильно сомневаюсь, что челу действительно нужен просто пинг.
Никогда дело этим не кончалось.
Когда обнаруживалось что роутеры виснут, клиенты всегда хотели знать почему виснут.
Обычно выдвигаются две версии - плохая температура эксплуатации и плохое питание.
И сразу же встает проблема серьезного мониторинга и другая тема: http://electronix.ru/forum/index.php?showtopic=57061

Знаю но все они подороже стоят немного так )) А на него встает линукс и все задачи решаются, тоесть разработка софта сводится к простой компиляции uClinux с параметрами + небольшая програмка которая сохраняет /etc в пару разделов флешки. ARM стоит дороже. MIPS редко получалось быстро собрать ядро и запустить переферию.

[Rst7]

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

Лично я человеку банальный отвечатель на ICMP-пакеты не предлагал. Я ему предлагал - http://shop.wild-mix.com/images/docs/PWD.doc

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

[AlexandrY]

Неплохой у вас дивайс.
Неужто всего за пару десятков баксов продаете?

Кстати не пробовали web страницы во Flash делать?
Например используя среду разработки Adobe Flex.
Можно получить шикарный дизайн и пользовательский интерфейс как у standalone приложения.

Лично я человеку банальный отвечатель на ICMP-пакеты не предлагал. Я ему предлагал - http://shop.wild-mix.com/images/docs/PWD.doc

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

[Rst7]

Неужто всего за пару десятков баксов продаете?

200 штук по $21.6. Розница $25. В эпоху стабильности было даже дешевле (в цену комплектухи трейдеры не закладывали неизвестность завтрашнего курса бакса).

Кстати не пробовали web страницы во Flash делать?

Нет. Пользуюсь java-script и XMLHttpRequest. Ну и еще небольшим гейтом HTTP<->MySQL, на данный момент сделаном на IIS+JScript. Хотя, с тем же успехом, это может быть апач+пхп, там 15 строк кода.

А как кстати сейчас с Flash'ом на младших братьях - в смысле, на КПК? Дело в том, что Опера 9.5 работает совершенно одинаково (имеется в виду Javascript, DOM, фичи HTML5) , что на большом брате, что на младшем, нет проблем с переносом, одни и те же веб-страницы с file://localhost/ работают. Из КПК прикольные беспроводные ДУшки получаются

[AlexandrY]

Надо же какой демпинг!
А зачем "гейт" если там у вас трапы посылаются? Или что такое "гейт" у вас?

На Flash и перешел именно из-за переносимости, тяжеловато приводить JavaScript и HTML к единому виду в IE, FF, Хроме и Опере
Опера у меня в телике стоит, Flash в ней работает.

200 штук по $21.6. Розница $25. В эпоху стабильности было даже дешевле (в цену комплектухи трейдеры не закладывали неизвестность завтрашнего курса бакса).


Нет. Пользуюсь java-script и XMLHttpRequest. Ну и еще небольшим гейтом HTTP<->MySQL, на данный момент сделаном на IIS+JScript. Хотя, с тем же успехом, это может быть апач+пхп, там 15 строк кода.

А как кстати сейчас с Flash'ом на младших братьях - в смысле, на КПК? Дело в том, что Опера 9.5 работает совершенно одинаково (имеется в виду Javascript, DOM, фичи HTML5) , что на большом брате, что на младшем, нет проблем с переносом, одни и те же веб-страницы с file://localhost/ работают. Из КПК прикольные беспроводные ДУшки получаются

[Rst7]

Надо же какой демпинг!

Никакого демпинга. Оно примерно столько и стоит в серийном производстве.

А зачем "гейт" если там у вас трапы посылаются? Или что такое "гейт" у вас?

Трапы там исключительно для тех, кто жить не может без snmp.

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

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

Вообщем это выглядит так:

Структура страниц у меня там примерно такая. Есть корневой хтмл, который грузит мой фреймворк для работы с мостом хтмл - модбас, в нем делается необходимое количество iframe'ов, в каждый грузится хтмл, уникальный для каждого типа приборов, который производит визуализацию и обработку органов управления конкретно для данного типа девайсов. Конфигурация, зависящая от объекта (адреса модулей на шине модбас, доменные имена мостов, имена таблиц архивов в мускуле и т.д.) передаются из корневого хтмл через урлы загрузки подчиненных страниц.

Собственно фреймворк один и тот же для всех модулей. Для заточки под объект необходимо в корневом хтмл размножить необходимое количество ифреймов, изменить названия хтмл-файлов, которые загружаются туда, и откорректировать адреса. После открытия корневого файла система работоспособна. Ах да, еще надо позапускать скрипты для создания баз/таблиц/встраиваемых процедур в мускуле. Вообщем, доступно любому вебпрограммеру средней руки

[AlexandrY]

Хм, если понял правильно вашу технологию,
то скажем клиенту в обсуждаемом случае придется сделать страницу содержащую 200! iframe ради возможности управлять всеми дивайсами одновременно.
Каждый из iframe должен как-то из JavaScript организовать ping.
Хотя я не знаю как с помощью JavaScript можно сгенерировать ping. Ведь это не HTTP поверх TCP, а более низкий слой.
Зная проблемы стабильности JavaScript в броузерах и неудобные средства отладки это очень опасное решение.
Может оказаться, что вообще 200 потоков скриптов не смогут в броузере работать.

Если речь идет об MySQL то тут наверно дивайсы в вашей технологии сами должны слать пакеты на IIS.
Т.е. сервер должен открыть публичный порт для некоего приложения у себя написанного под IIS.
Самого приложения для Ping-ов как я понял еще нет.
Странно что предлагая ставить ваши устройства в отдельный VLAN у вас нет настройки тега VLAN в устройствах.

Это все к вопросу о конечной цене решения.
Она далеко не так ясна как кажется.
Программист даже "средней руки" бесплатно работать наверно не будет.

А вот ActionScript в технологии Adobe Flash может создать сокетное подключение с любым бинарным протоколом и реально мог бы из броузера управлять двумя сотнями дивайсов.

Никакого демпинга. Оно примерно столько и стоит в серийном производстве.

Вообщем это выглядит так:

Структура страниц у меня там примерно такая. Есть корневой хтмл, который грузит мой фреймворк для работы с мостом хтмл - модбас, в нем делается необходимое количество iframe'ов, в каждый грузится хтмл, уникальный для каждого типа приборов, который производит визуализацию и обработку органов управления конкретно для данного типа девайсов. Конфигурация, зависящая от объекта (адреса модулей на шине модбас, доменные имена мостов, имена таблиц архивов в мускуле и т.д.) передаются из корневого хтмл через урлы загрузки подчиненных страниц.

Собственно фреймворк один и тот же для всех модулей. Для заточки под объект необходимо в корневом хтмл размножить необходимое количество ифреймов, изменить названия хтмл-файлов, которые загружаются туда, и откорректировать адреса. После открытия корневого файла система работоспособна. Ах да, еще надо позапускать скрипты для создания баз/таблиц/встраиваемых процедур в мускуле. Вообщем, доступно любому вебпрограммеру средней руки

[Rst7]

Каждый из iframe должен как-то из JavaScript организовать ping.
Хотя я не знаю как с помощью JavaScript можно сгенерировать ping.

А не нужно. Если девайс отвечает на HTTP-запросы, то, значит, коннект с ним есть Пингать в него - это лишнее.

Может оказаться, что вообще 200 потоков скриптов не смогут в броузере работать.

javascript в браузерах исполняется в один поток (по крайней мере в пределах одного окна). Никакой многопоточности.

Если речь идет об MySQL то тут наверно дивайсы в вашей технологии сами должны слать пакеты на IIS.
Т.е. сервер должен открыть публичный порт для некоего приложения у себя написанного под IIS.

Ну тут я делаю примерно так - аварийные ситуации, которые летят по snmp, можно сливать в мускул банальным выполнением insert через консоль СУБД. Т.е. в конфигурации snmptrapd делается выполнение mysql -e INSERT blablabla по приходу моих трапов. Это предназначено только для сохранения текущих событий.

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

Самого приложения для Ping-ов как я понял еще нет.

Да оно и не нужно. См. выше.

Странно что предлагая ставить ваши устройства в отдельный VLAN у вас нет настройки тега VLAN в устройствах.

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

Да и вообще. Устройство расказывает от своем состоянии через Modbus over TCP. Можно прикрутить к любой SCADA-системе. Например сюда - http://oscada.diyaorg.dp.ua/index.php?id=2&L=1

[Клим]

javascript в браузерах исполняется в один поток (по крайней мере в пределах одного окна). Никакой многопоточности.

Хм. Всегда считал, что ajax-запросы выполняются параллельно (Максимум одновременно - количество одновременных соединений к сайту в настройках)

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

P.S. А если уж очень хочется совместимость SCADA и прочими системами, то неплохо было бы реализовать протокол OPC. Хотя лично я слабо себе представляю, как его реализовать в простых контроллерах.

[Rst7]

Хм. Всегда считал, что ajax-запросы выполняются параллельно

Запросы - да. А вот само исполнение javascript'а - один поток.

Параллельность там из-за того, что после .send() надо ждать DOM-сообщения. В это время можно запустить еще один запрос, или что-то другое сделать. Но, если, например, после .send() сделать for(;;), то сообщения Вы никогда не получите, потому как поток - один.

P.S. А если уж очень хочется совместимость SCADA и прочими системами, то неплохо было бы реализовать протокол OPC. Хотя лично я слабо себе представляю, как его реализовать в простых контроллерах.

Да берется просто готовый OPC-сервер протокола Modbus over TCP и все.

[AlexandrY]

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

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

Движок скрипта в одном потоке выполняет лишь процедуры реакции на ивенты написанные в HTML странице.
А по сути асинхронные запросы (AJAX) выполняются в отдельных потоках.
Т.е. каждый HTTPRequest вызывает образование нового потока. Это свободно можно наблюдать c помощью ProcessExplorer
И вот эти потоки реквестов и есть основная причина торможения и зависаний броузеров ибо логика таймаутов там на рудиментарном уровне пока еще.

Не скажу что решение вообще неработоспособно, но такой винегрет из опенсорсных утилит, MySQL и скриптов наверно и достоин быть оценен в 20$

А не нужно. Если девайс отвечает на HTTP-запросы, то, значит, коннект с ним есть Пингать в него - это лишнее.

javascript в браузерах исполняется в один поток (по крайней мере в пределах одного окна). Никакой многопоточности.

[Rst7]

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

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

Более того, вынужден процитировать фразу заказчика после прочтения им описания:

Почитал, все вроде подходит.

А мы с Вами можем обсуждать философию построения таких систем/устройств хоть до китайской пасхи, лично мне беседа с Вами приносит только удовлетворение, всегда приятно поговорить с умным человеком

Можем, в частности, попросить модераторов отделить обсуждение в отдельную ветку, где и продолжим. Тут это, все-же, оффтоп.

[AlexandrY]

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

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

Более того, вынужден процитировать фразу заказчика после прочтения им описания:


А мы с Вами можем обсуждать философию построения таких систем/устройств хоть до китайской пасхи, лично мне беседа с Вами приносит только удовлетворение, всегда приятно поговорить с умным человеком

Можем, в частности, попросить модераторов отделить обсуждение в отдельную ветку, где и продолжим. Тут это, все-же, оффтоп.

[Mihail Gluhowche...]

Добрые люди модераторы перенесите ветку. И я наконец объясню теоретикам почему устройство с простеньким стеком и контроллером не выживет в реальной не управляемой сети И про глючной камень ещё добавлю

Сообщение отредактировал Mihail Gluhowchenko - Jan 14 2009, 02:43

[zltigo]

Moderator:
Выделено из темы http://electronix.ru/forum/index.php?showtopic=57576&hl=

[MrYuran]

На Flash и перешел именно из-за переносимости, тяжеловато приводить JavaScript и HTML к единому виду в IE, FF, Хроме и Опере
Опера у меня в телике стоит, Flash в ней работает.

заранее сорри за оффтоп,
но я лично на предложения установить флеш-плейер, адд-оны, плаг-ины и прочую требуху типа актив-Х матерно жму кнопку "ни в коем случае!"
Так что для Вас я и подобные мне товарищи - потерянные потенциальные клиенты.
Всегда надо предлагать людям альтернативу, пусть это даже будет простейшая табличная вёрстка без картинок
А привычка такая пошла с тех времён, когда тратить несколько метров траффика на загрузку одной страницы было непозволительной роскошью
Всё, закончил, ещё раз извините.

[Rst7]

И я наконец бъясню теоретикам почему устройство с простеньким стеком и контроллером не выживет в реальной не управляемой сети.

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

И про глючной камень ещё добавлю

Это про какой?

[one_man_show]

А мы с Вами можем обсуждать философию построения таких систем/устройств хоть до китайской пасхи, лично мне беседа с Вами приносит только удовлетворение, всегда приятно поговорить с умным человеком

Можем, в частности, попросить модераторов отделить обсуждение в отдельную ветку, где и продолжим. Тут это, все-же, оффтоп.

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

Друзья! Побольше бы такого "оффтопа", о котором Вы говорили, жить было бы интереснее))))

[Rst7]

Побольше бы такого "оффтопа"

Это мы запросто

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

С другой стороны, у нас на форуме редко поднимаются такие вопросы. Непонятно, кстати, почему.

[Mihail Gluhowche...]

Камень BF532.

Простой котроллер != полноценный IP стек, работать просто небудет долго и стабильно, как он переживет стандартные IP MAC шторм например? Или другие каки которые пользователи могут организовать намеренно?
Не полноценные LwIP, или свой маленький наложили структурку разобрали пакетик, гарантированно жить небудут.

[Rst7]

наложили структурку разобрали пакетик, гарантированно жить небудут.

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

работать просто небудет долго и стабильно,

Обоснуйте. Утверждение голословно. На все 100.

как он переживет стандартные IP MAC шторм например

И что такое "стандартный IP MAC шторм"? Это какой RFC?

[AlexandrY]

B это все!?

Камень BF532.

Простой котроллер != полноценный IP стек, работать просто небудет долго и стабильно, как он переживет стандартные IP MAC шторм например? Или другие каки которые пользователи могут организовать намеренно?
Не полноценные LwIP, или свой маленький наложили структурку разобрали пакетик, гарантированно жить небудут.

Жалко, я ожидал полного разгрома.
Профи по Blackfin-ам не должен отделываться такими слабыми аргументами.
Проблема видимо в uCLinux. Эта штука может лишить здравого смысла любой процессор.

На самом деле придираться к ненадежности работы на физическом уровне low-end микроконтроллеров не стоит.
Если уж совсем не сделано безобразно, как например, китайцы любят трансформатор в Ethernet заменять резисторами.

Плотно работая с локальным клиентом, вполне можно сделать достаточно надежное решение на уровне передач по TCP/IP.
И дешевое будет экстремально.
Вот апнот от Microchip-а, где они дают раскладку ресурсов на их PIC-и при реализации TCP/IP.
http://ww1.microchip.com/downloads/en/AppNotes/00833c.pdf
Имея в виду что чип стоит 3-и бакса, плата однослойная может быть сделана полукустарно за 0.5$ и трансформатор заменен резисторами получаем себестоимость изделия в пределах 5$ вместе с упаковкой.

Не намного дороже будет если делать на Luminary Micro и на их бесплатном стеке, зато будет MDIX и 100Base-T.

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

С другой стороны мы не знаем на чем у уважаемого Rst7 сделан дивайс.
Он может в принципе быть сделан и на STR912 или ColdFire, тоже в принципе весьма недорогих микроконтроллерах.
Вот они могут фильтровать трафик по тэгу VLAN в Ethernet пакете и могут стоять прямо в линии где гуляет 100 мегабитный поток и при этом не захлебываться трафиком.
ColdFir-ы еще и могут обнаружить и сообщить о преднамеренном флуде и атаках на MAC уровне не теряя связи с целевым хостом.


О применимости простых решений может свидетельствовать тот факт, что сверхдешевые Ethernet модули широко распространены в хакерском бизнесе по удаленному шарингу различных смарткарт.
Суть очень схематично такова: вы имеете знакомого с SIM картой в Австралии и хотитет позвонить используя эту карту из Москвы.
Знакомый берет и подключает эту карту к инету. Вы из инета подключаете карту к мобиле и звоните. Естественно такой расшаренной картой может пользоваться еще пол интернета.
Виденное мной подобное решение на PIC18 показало полную жизнеспособность при работе в открытом интернете. При этом плотность трафика там требовалась больше чем в обсуждаемом варианте с пингами.

Риски дешевых решений проявляются только когда клиент удаленный и для наблюдения нужна система , вот тут можно поприкалываться над PIC-ами.

[MALLOY2]

Камень BF532.

Простой котроллер != полноценный IP стек, работать просто небудет долго и стабильно, как он переживет стандартные IP MAC шторм например? Или другие каки которые пользователи могут организовать намеренно?
Не полноценные LwIP, или свой маленький наложили структурку разобрали пакетик, гарантированно жить небудут.

Будет он работать пока не рассосутся все електроны в полупроводниках, по поводу всяких штормов проводил специальный тест, 2 платы STR912FA включены в общую сеть конторы. На одной плате крутится LwIP, 2 плата не используя никаких стеков, на МАКСИМАЛЬНОЙ СКОРОСТИ броадкастомом пуляет в сеть рандом данные, так вот компы начали умирать, плата с стеком LwIP начала терять пакеты пинг вырос сильно (MAC захлебнулся), после выключения 1 платы 2 плата сразу начала работать нормально, а вот компы некоторые пришлось перезагрузить.

Я вам скажу что мелкий конртроллер с мелким стеком будет работать надежней и стабильней любого WIN и LINUX и других операционок, а если есть какието проблемы у мелкго контроллера так надо копать в программе че там на програмлено.

[Rst7]

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

Ну и фиг с ним. Девайс его ребутнет да и все, это если из-за заливания потоком не будет проходить ICMP-пакеты. Если роутер поднимется после ребута в нормальном режиме - то все отлично. Не поднимется - никакая пинговалка, хоть на PPC G4, его не поднимет, надо идти разбираться ручками.

Вообще желательно конфигурировать сеть так, чтобы устройства управления сидели в отдельном VLAN'е. Тогда мультикастовые потоки в общедоступной части сети будут мало волновать.

Вот они могут фильтровать трафик по тэгу VLAN в Ethernet пакете и могут стоять прямо в линии где гуляет 100 мегабитный поток и при этом не захлебываться трафиком.

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

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

[AlexandrY]

Был у нас один прецедент.
Деталей не помню, но смысл в том, что многочисленные неконтролируемые сбросы роутеров приводили к сносу у них настроек.
Сбросы или не сбросы были в этом виноваты, но виноватым назначили того кто сбрасывал.
В дешевых роутерах особо не заботятся о целостности файловой системы ибо полагаются, что юзер где-то рядом и всегда все перенастроит согласно инструкции.
Судя по клиенту здесь как раз случай с дешевыми роутерами.
А сброс предпологается делать снятием питания.
Логично ожидать что и блоки питания будут дешевыми с экономией на обмотке и железе, и из-за того огромными скачками напряжения при коммутации. Заземление у них там тож вероятно в дефиците будет.
Дивайсы фазу напряжения как понял не ищут для подходящего времени отключения.

Вообщем роутеры обычно любят вести лог. Это означает что файловая система у них все время активна.
Отключение питания приводит к появлению сначала мощного импульса перенапряжения на вводе питания в роутер и оно уходит через плату и оплетку подключенных кабелей STP в землю и спустя милисекунды только напряжение питания начинает падать.
За это время NAND Flash на роутере из-за наводки успевает несколько раз ошибиться в адресации и вписать данные не туда куда надо.
Поскольку блоки в файловых системах пишуться не меньше чем по 512 байт то целостность файловой системы будет однозначно нарушена либо сразу
либо позже когда будет запись в грязный кластер считающийся чистым.
С большой вероятностью роутер вообще перестает отвечать на пинги.
Дивайс в свою очередь до отупения будет продолжать его сбрасывать, пока у роутера от ESD вообще не пробъет PHY драйвер.
Пробитый драйвер начинает неимоверно греться и вслед за ним начинает перегреваться блок питания, у дешевого трансформатора от перегрева начинают замыкать витки в обмотке от чего он еще сильнее перегревается и загорается.
Хорошо если сработает защита от KЗ в электрошкафу. Но сомневаюсь, что она будет стоять там где применяют Ethernet пробник за 20$
Итого все сгорает.

Вот такие вот риски..

Можете считать шуткой.

Ну и фиг с ним. Девайс его ребутнет да и все, это если из-за заливания потоком не будет проходить ICMP-пакеты. Если роутер поднимется после ребута в нормальном режиме - то все отлично. Не поднимется - никакая пинговалка, хоть на PPC G4, его не поднимет, надо идти разбираться ручками.

[Rst7]

Был у нас один прецедент.

Ооо, какая страшилка на ночь. Детям хоть своим не рассказывайте

Я тут как Станиславский - НЕ ВЕРЮ!

Первый вопрос - какого же хрена девайсы сбрасывались так часто, что случилась такая беда?

[blackfin]

Я тут как Станиславский - НЕ ВЕРЮ!

Присоединяюсь!

Тем более, что никак не пойму логики автора:

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

Насколько мне известно, в имульсных блоках питания при отключении внешнего источника питания, т.е. до диодного моста, импульсный преобразователь начинает "высасывать" энергию, запасенную в электролитическом конденсаторе входного фильтра. При этом ШИМ-контроллер, регулируя скважность импульсов, будет еще некоторое время стабилизировать напряжение на выходе БП (те самые милисекунды) после чего, напряжение действительно начнет падать.. Но откуда "БРОСОК" напряжения на выходе БП???

[AlexandrY]

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

Присоединяюсь!

Тем более, что никак не пойму логики автора:
Насколько мне известно, в имульсных блоках питания при отключении внешнего источника питания, т.е. до диодного моста, импульсный преобразователь начинает "высасывать" энергию, запасенную в электролитическом конденсаторе входного фильтра. При этом ШИМ-контроллер, регулируя скважность импульсов, будет еще некоторое время стабилизировать напряжение на выходе БП (те самые милисекунды) после чего, напряжение действительно начнет падать.. Но откуда "БРОСОК" напряжения на выходе БП???

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

Первый вопрос - какого же хрена девайсы сбрасывались так часто, что случилась такая беда?

[Rst7]

А через какое время сбрасывает ваш прибор если его клиент не пингуется?

Через заданное в настройках.

И есть ли у него предел количеству сгенерированных сбросов.

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

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

[AlexandrY]

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

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

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

[Rst7]

Характерно, что вы не стали жестко отрицать что такого не бывает.

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

НЕ ВЕРЮ!

Про песни с выжиганием phy от выключения 220В спорить не буду. Вам хочется, чтобы импульс был, пусть будет.

[AlexandrY]

Легко.
У нас подлетное время IT специалистов по траблам составляет 24 часа (рабочих часа) по договору.
В реале не раньше чем через 2-е суток.

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

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

НЕ ВЕРЮ!

Про песни с выжиганием phy от выключения 220В спорить не буду. Вам хочется, чтобы импульс был, пусть будет.

[Rst7]

Легко.
У нас подлетное время IT специалистов по траблам составляет 24 часа (рабочих часа) по договору.
В реале не раньше чем через 2-е суток.

Круто. Пионернет на обслуживании удаленной организацией. Вот такое точно никогда не видел. Это, конечно, люди сами себе злобные буратины.

Объясню, почему пионернет. Из Ваших слов я делаю вывод, что одно нарушение линка привело к тому, что началась групповая перезагрузка оборудования. А это значит только одно - гирлянды коммутирующего оборудования на магистрали (обычно - гирлянды неуправляемых мыльниц) без резервного линка с другого конца. Даже, хотя-бы, поднимаемого вручную (ну или полу-вручную, через скрипты). Про STP я вообще молчу.

Да и фраза про отсутствующее заземление... А значит, и отсутствие грозозащиты Сколько мешков свичей в сезон меняют?

Вообщем, нападение Ваше мимо на все 100.

[Клим]

Круто. Пионернет на обслуживании удаленной организацией. Вот такое точно никогда не видел. Это, конечно, люди сами себе злобные буратины.

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

[Rst7]

Аж интересно стало, как у вас в Харькове домовые сетки работают.

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

Есть конечно, в отдельно взятых сегментах/районах исключения из правила. Но очень мало. Некоторые до продажи старались, что-то делали, как только продались - все, как отрезало. Гори все огнем...

Время реагирования 24 часа - это еще хороший показатель.

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

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

[Mihail Gluhowche...]

У нас в народ продовался по 400 - 600 а если напрямую то по 1к
Простые пинговалки это как временная затычка, а поповоду исключительных сетуаций они бывают очень часто, потому как сеть она большая а если неуправляемая то вироятность близка к 0.7

[Microwatt]

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

Хо-хо!
Шутите, парниша?
Любой источник должен быть:
-правильно спроектирован и изготовлен
-правильно применяться.

[Rst7]

то вироятность близка к 0.7

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

[Mihail Gluhowche...]

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

Вероятность вредоносного трафика на 1000 абонентов. Тоесть какой либо трафик который вырубит сетевой интерфейс, а устройство будет думать, что нет связи, и дернет коммутатор

[Rst7]

Вероятность вредоносного трафика на 1000 абонентов.

Мда. Вы хотя бы знаете, что такое "вероятность"?

Хотя бы книжку какую умную почитали, перед тем, как ляпнуть.

[Mihail Gluhowche...]

Мда. Вы хотя бы знаете, что такое "вероятность"?

Хотя бы книжку какую умную почитали, перед тем, как ляпнуть.

Давайте ещё пальцы веером выложим. Есть теория растущих сетей, можете почитать много интересного узнаете. А ещё есть практика, эксплуатации устройств передачи данных на сети связи

Сообщение отредактировал Mihail Gluhowchenko - Feb 11 2009, 12:07

[Rst7]

Давайте ещё пальцы веером выложим.

Давайте. У кого пальцы составят базис в пятимерном пространстве, тот и царь

По делу. Раскройте Ваш тезис о "вероятности вредноносного траффика 0.7 на 1000 абонентов". Это вероятность чего? Что 1000 абонентов с вероятностью 0.7 положат любую (любую - потому что топология сети не рассматривалась Вами вообще) сеть? Или что? Обьясните. И не забудьте методику получения числа 0.7. А пока все Ваши реплики - лишь набор бессвязных терминов. Это заставляет усомнится в Вашем понимании предмета обсуждения.

[Aprox]

Давайте. У кого пальцы составят базис в пятимерном пространстве, тот и царь

Месяц назад вы писали, что сделали мост TCP/Modbus для доступа, по-видимому, к каким-то технологическим девайсам АСУТП. Иначе, зачем бы вообще заморачиваться на Modbus? Также вы писали, что в каждом удаленном девайсе реализовали HTTP-сервер, который отвечает на запросы Flash-плеера. Я правильно понял ситуацию? Если не очень ошибся, то скажу- это неэффективный путь именно для АСУТП. Я его прошел два года назад и сейчас уверен- для простых приборов в локальной сети не имеет никакого смысла встраивать накрученные стеки с протоколами TCP и тем более HTTP. Хранить Flash файлы или Ajax скрипты в каждом приборе и гонять их в броузер тоже неэффективно. Самое оптимальное по эффективности- обыкновенное UDP. Причем, обойтись можно даже без ARP и IP, а управлять девайсами через Вroadcast посылками на заранее выбранный порт. И это прекрасно работает в локальной сети без всякого пингования.

[Rst7]

Месяц назад вы писали

Давайте все же мух отдельно, котлеты отдельно.

Мост он нужен для того, чтобы существующему у меня ПО общаться с существующими модулями АСУ, у которых физика - RS485, транспорт - Modbus RTU.

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

Отдельно в этом же устройстве реализован функционал пинговалки (то, что нужно было заказчику у истоков этой темы). Статус этой пинговалки можно получить любым удобным вышеописанным способом, и, кроме того, девайс еще и SNMP TRAP'ы рассылает по событиям.

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

[Mihail Gluhowche...]

Давайте. У кого пальцы составят базис в пятимерном пространстве, тот и царь

По делу. Раскройте Ваш тезис о "вероятности вредноносного траффика 0.7 на 1000 абонентов". Это вероятность чего? Что 1000 абонентов с вероятностью 0.7 положат любую (любую - потому что топология сети не рассматривалась Вами вообще) сеть? Или что? Обьясните. И не забудьте методику получения числа 0.7. А пока все Ваши реплики - лишь набор бессвязных терминов. Это заставляет усомнится в Вашем понимании предмета обсуждения.

Пространство у нас 7-ми мерное. Базис надо побольше (Читаем теорию струн )

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

[Rst7]

Пространство у нас 7-ми мерное. Базис надо побольше (Читаем теорию струн )

Тогда уж 11тимерное. Только 5 пальцев могут составить базис только в 5тимерном пространстве.

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

Мда. Сильная логическая цепочка "из управляемого коммутатора сделать хаб" - "слабый контроллер и самописный стек приведут к..."

И эти люди запрещают нам ковыряться в носу

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

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

Я не знаю на какой ступени пищевой пирамиды вы в телекоме и вообще относитесь к какой либо ступени.

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

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

Мои тоже. И тоже работают. Так зачем платить больше?

[Mihail Gluhowche...]

Хе а мы GEPON выпускаем И обзоры товарища Нагибина иногда читаю. Скоро будут GPON решения. Мы работаем просто с телекомами по больше.

[Aprox]

Мост он нужен для того, чтобы существующему у меня ПО общаться с существующими модулями АСУ, у которых физика - RS485, транспорт - Modbus RTU.

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

Как я пнимаю, существующее ПО- это стандартный броузер, localhost WEB-сервер и dll-ка в каталоге CGI, которая и осуществляет мост HTTP/Modbus? Знаем, проходили. В таком подходе много проще все-таки использовать технологию Flash потому, что там более компактно передаются и автоматически парсятся переменные. Я имею ввиду класс LoadVars(). Hо это частности. В целом же, поигравшись в таком ключе, я вынес твердое убеждение- если уже есть оборудование с Modbus, то не следует затевать модные штучки с HTTP, который рассчитан все-таки как-минимум на Ethernet и крутые стеки протоколов. Труда будет затрачено много, а выигрыш- ... я лично никакого выигрыша не вижу.

Отдельно в этом же устройстве реализован функционал пинговалки (то, что нужно было заказчику у истоков этой темы). Статус этой пинговалки можно получить любым удобным вышеописанным способом, и, кроме того, девайс еще и SNMP TRAP'ы рассылает по событиям.

Я точно не знаю, но по-моему в Modbus оконечные устройства не имеют возможности самостоятельно вываливаться на шину RS-485, а только реагируют на запросы мастера. Как же тогда они у вас шлют SNMP по своим асинхронным событиям?

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

Да в сети с роутерами, маршрутизаторами и прокси, мой прием броадкастига не проходит. Hо в локалке, в которой стоят обычные свитчи- работает прекрасно. Смысл UDP-броадкастига на выделенный порт в значительном упрощении софта девайсов, подключенных по Ethernet. В них не надо реализовать громоздкие и тихоходные стеки протоколов, а значит и OC реального времени... много всего сразу упрощается.

[Клим]

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

5 раз перечитал, так и не понял, что значат первые два предложения. Наверное, девайсы автора так же работают
А на счет "слабый контролер" - бред полнейший. Есть контроллер, есть задача, которую нужно решить. Тут вполне достаточно ATMEGA или аналогичного. "слабых контроллеров" не бывает. Бывает "слабая" программа, бывает "неподходящая для данного контроллера" программа, но это все решаемо, причем без раскидывания пальцев в пространствах.
Лично мне во всей этой затее не нравится только то, что логика завязана на javascript, flash. По моей задумке должно быть один-несколько серверов, которые будут общаться с этими девайсами, ползьователь уже пусть общается с этими серверами. Если кому интересно, могу поделиться своми мыслями по данному поводу.

[Rst7]

Лично мне во всей этой затее не нравится только то, что логика завязана на javascript, flash.

Логика не завязана. Девайсы сами примут решение и выполнят перезапуск. Ума у них для этого вполне достаточно. А вот отображение информации на каком-нибудь контрольном посту можно сделать как угодно - в моем варианте это может быть браузер, который ходит к устройствам через аякс; любой существующий приниматель snmp trap'ов; любая SCADA-система через Modbus over TCP - выбирайте наиболее подходящий вариант.

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

Вообщем, аля-SCADA. Нечто подобное я неспеша сейчас пишу, но если ребята из Днепропетровска асилят стабильность своей OpenSCADA к маю сего года, как обещали, то наверное брошу.

[AlexandrY]

Давайте, делитесь.

Насчет ATMeg вы правы.
Вот эти дивайсы
http://www.hw-group.com/products/damocles/...es_2404_en.html
сделаны на ATMege.
У них и WEB, и FLASH, и SNMP, и SMTP. Все есть.

Применение SNMP как бы закрывает тему серверов и группового управления, что тут еще можно более гибкое и доступное придумать?

А на счет "слабый контролер" - бред полнейший. Есть контроллер, есть задача, которую нужно решить. Тут вполне достаточно ATMEGA или аналогичного. "слабых контроллеров" не бывает. Бывает "слабая" программа, бывает "неподходящая для данного контроллера" программа, но это все решаемо, причем без раскидывания пальцев в пространствах.
Лично мне во всей этой затее не нравится только то, что логика завязана на javascript, flash. По моей задумке должно быть один-несколько серверов, которые будут общаться с этими девайсами, ползьователь уже пусть общается с этими серверами. Если кому интересно, могу поделиться своми мыслями по данному поводу.

Не знаю как, у вас там со SCADA-ми, но солидные серверы SNMP не станут работать с дивайсом от которого только trap-ы идут.
Тот же HP OpenView откажется включать дивайс в свою базу если он не поддерживает весь SNMP протокол.
У вас же расчет на простого линуксового демона.
Вы же его логику работы переделать не можете.
Т.е. большой риск ложных срабатываний т.к. сервер не может перепроверить истинное состояние, нельзя реализовать логику принятия решений на стороне сервера, а это уже очень плохо (прежде всего для вас) так как оператор системы быстро озвереет от беспричинных неперепроверяемых алярмов.

любой существующий приниматель snmp trap'ов; любая SCADA-система через Modbus over TCP - выбирайте наиболее подходящий вариант.

[Rst7]

Т.е. большой риск ложных срабатываний т.к. сервер не может перепроверить истинное состояние,

Не пойму, если девайс принял решение о перезапуске и сообщил об этом трапом, что большому серверу перепроверять? Действительно ли у меня бит аварии в статусе поднялся???

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

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

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

В пионернетовских колхозах способ реагирования не должен отличаться. Сработка - оделся, пошел на объект.

[AlexandrY]

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

Народ вроде о более общих принципах построения сетей хочет поговорить.
Вот я и поддерживаю тему
В нормальных сетях с большой ценой простоя вами предлагаемое решение так скажем не жилец.
Ему будет трудно конкурировать с теми на которые я дал ссылку.

Не пойму, если девайс принял решение о перезапуске и сообщил об этом трапом, что большому серверу перепроверять? Действительно ли у меня бит аварии в статусе поднялся???



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

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

В пионернетовских колхозах способ реагирования не должен отличаться. Сработка - оделся, пошел на объект.

[Rst7]

В нормальных сетях с большой ценой простоя вами предлагаемое решение так скажем не жилец.

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

Ему будет трудно конкурировать с теми на которые я дал ссылку.

Чем же мое устройство в корне отличается от устройства по Вашей ссылке? Если использовать ее как пинговалку, то устройство по Вашей ссылке не обеспечивает необходимый функционал, потому как для простой работы по перезапуску какого либо оборудования в данном конкретном месте требует наличие удаленного (!!!) мозга, который примет решение и имеет надежность на порядок меньшую, чем собственно девайс.

[Mihail Gluhowche...]

5 раз перечитал, так и не понял, что значат первые два предложения. Наверное, девайсы автора так же работают
А на счет "слабый контролер" - бред полнейший. Есть контроллер, есть задача, которую нужно решить. Тут вполне достаточно ATMEGA или аналогичного. "слабых контроллеров" не бывает. Бывает "слабая" программа, бывает "неподходящая для данного контроллера" программа, но это все решаемо, причем без раскидывания пальцев в пространствах.
Лично мне во всей этой затее не нравится только то, что логика завязана на javascript, flash. По моей задумке должно быть один-несколько серверов, которые будут общаться с этими девайсами, ползьователь уже пусть общается с этими серверами. Если кому интересно, могу поделиться своми мыслями по данному поводу.

Сейчас буду бить себя пяткой в грудь и говорить, я на меге легко заставлю контроллер ложно срабатывать. Супер программистов и главное супер QA не существует дыры есть будут, я думаю через определенное время какая либо крайняя версия прошивки будет сносно работать. Linux просто убирает большую часть дыр(зарплата хорошего программиста тоже идет в цену устройства). Про javascript, flash, полностью поддерживаю это не путь Джедая . Был опыт объяснения людям что сервер конфигурации на ASP который работать на AT91rm9200 не путь. Но красиво было глаз не оторвать

[Клим]

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

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

Народ вроде о более общих принципах построения сетей хочет поговорить.
Вот я и поддерживаю тему

Об этом уже тем достаточно, только на других форумах
По этому, если хотите, то давайте это обсудим в другой теме.

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

Опять же не понимаю, что вы хотите этим сказать.
А я легко заставлю вашу железку с линухом "ложно срабатывать"
Вы сами себе противоречите. Пусть это будет хоть линух, хоть вы туда поставите писюк с windows XP и будете программу на VB.NETе писать - везде могут быть ошибки. Только если устройство с ограниченной функциональностью и все самописанное, то будет проще отловить эти ошибки. А в случае линуха или еще чего у Вас будет еще куча глюков самого линуха, помимо ваших ошибок. Потому как "Супер программистов не существует"
И вообще, чем устройство сложнее, тем его надежность меньше. Это справедливо во многих случаях и в этом тоже.

Лично я себе всю систему предствляю так:
на свитчах стоят "пинговалки", которые обладают следующими характеристиками:

• имеют свой IP-адрес
• отвечают на ICMP запросы
• имеют веб-интерфейс для конфигурирования(опционально)
• конфигурируются полностью удаленно
• имеют резервное питание и RTC (опционально)

Должны обеспечивать следующие функции:

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

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

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

[AlexandrY]

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

Я как помните начал тему с представления вполне дешевых дивайсов поддерживающих технологию RMON в составе сети SNMP-оборудованных узлов
О технологии здесь - http://www.osp.ru/nets/1996/06/141763/

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

Простой пинг вполне может себе проходить раз в 5-ть минут допустим в то время как вся сеть будет стоять колом.
И та же пинговалка может методично убивать аппаратуру сбросами просто потому что сменили IP адрес у целевого узла пинговалки.
Поскольку пинговалки невозможно включить в IT структуру управления, то это создает дополнительные накладные расходы на управление и риски.

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

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

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


Чем же мое устройство в корне отличается от устройства по Вашей ссылке? Если использовать ее как пинговалку, то устройство по Вашей ссылке не обеспечивает необходимый функционал, потому как для простой работы по перезапуску какого либо оборудования в данном конкретном месте требует наличие удаленного (!!!) мозга, который примет решение и имеет надежность на порядок меньшую, чем собственно девайс.

[Mihail Gluhowche...]

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

[Aprox]

Не пойму, если девайс принял решение о перезапуске и сообщил об этом трапом, что большому серверу перепроверять? Действительно ли у меня бит аварии в статусе поднялся???
Кроме того, я, как разработчик систем пожарной безопасности...

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

[AlexandrY]

В АСУТП то зачем пинговалки?
Это не та отрасль, как я понимаю, где позволено виснуть свичерам.
Ту как бы нет предмета обсуждения.
Я вообще MAC пакетами обмен веду в реалтайме и че?

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

[Rst7]

но вопрос от дурака- почему бы не устроить простой постоянный опрос статуса устройств из центрального пульта?

Ну так для этого и нужен тот-же TCP/IP. Или, кому не нравится TCP/IP, я отдаю в виде SNMP-TRAP'ов.

"Пингование" решается автоматически, просто по таймауту?

Не понял вопроса.

Как я понимаю сеть у вас локальная, изолирована от Интернета..

Сети бывают разные.

Зачем тогда все эти навороты?

Где Вы тут у меня видите навороты? Тут минимум функционала. Навороты предлагают (а по мне, так навязывают) господа AlexandrY и Mihail Gluhowchenko.

В АСУТП то зачем пинговалки?
Это не та отрасль, как я понимаю, где позволено виснуть свичерам.

Разные АСУТП бывают. А приказом "ни шагу назад" свичам не запретишь падать.

[Клим]

В АСУТП то зачем пинговалки?

Вот давайте сюда АСУТП не будем приплетать
Изначально все пошло из темы "Владеем сеткой в 200 домов..."
Так что, лично я, отталкиваюсь именно от этого.

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

[Aprox]

В АСУТП то зачем пинговалки?
Это не та отрасль, как я понимаю, где позволено виснуть свичерам.
Ту как бы нет предмета обсуждения.
Я вообще MAC пакетами обмен веду в реалтайме и че?

В АСУТП часто виснет или выгорает периферийное оборудование. "Пинговалка", хотя вряд ли сюда подходит этот термин, поможет обнаружить с центрального поста такое зависание или выгорание. Если удаленный сервер вдруг перестает отвечать на периодические запросы клиента, то пора бежать ремонтникам к месту расположения данного сервера. У Rst7, как я понял, не Ethernet сеть, поэтому говорить про свитчи и Raw-пакеты- тоже особо не имеет смысла.

Где Вы тут у меня видите навороты? Тут минимум функционала. Навороты предлагают (а по мне, так навязывают) господа AlexandrY и Mihail Gluhowchenko.

У коллег видимо другие задачи, с выходом в Интернет, с роутерами и маршрутизаторами. Там да, - лучше выполнять все протоколы досконально.

[Rst7]

У Rst7, как я понял, не Ethernet сеть, поэтому говорить про свитчи и Raw-пакеты- тоже особо не имеет смысла.

Гм. Позвольте полюбопытствовать, почему Вы так думаете?

[AlexandrY]

Ну прям навязывают...
У каждого свой опыт просто.
Как-то пришлось участвовать в конкурсе по разработке компонентов европейской региональной системы AMR (Automated Meter Reading) для корпорации ENEL.
Там был яркий пример.
Нужно было разработать некий узел типа конвертера от электросчетчиков в интернет в частности по GSM
Взялась бригада ушлых итальянских парней и наваяла через год.
Не нашли ничего лучше чем весь обмен и удаленный в том числе сделать по типу AT команд.
Нашли даже силы сварганить сервер работающий по AT командам.
Т.е. тоже были склонны к примитивизму, процессор выбрали на базе I51.
Надо-ж было подешевле. Это было одно из главных условий конкурса.
После года мучений ENEL плюнул и организовал новый конкурс и жестко поставил условие использовать SNMP!
Само, что требования к процу тоже поднялись.
А исходники старого проекта раздали всем желающим, чтоб знали авторов того поделия и как не надо делать

Где Вы тут у меня видите навороты? Тут минимум функционала. Навороты предлагают (а по мне, так навязывают) господа AlexandrY и Mihail Gluhowchenko.

Разные АСУТП бывают. А приказом "ни шагу назад" свичам не запретишь падать.

[Aprox]

Гм. Позвольте полюбопытствовать, почему Вы так думаете?

Из упоминания про Modbus.

[Rst7]

Из упоминания про Modbus.

А Вы не знаете, что существует Modbus over TCP?

Из упоминания про Modbus.

А Вы не знаете, что существует Modbus over TCP?

[Aprox]

А Вы не знаете, что существует Modbus over TCP?

Честно отвечу- не знаю такого. Всегда думал, что Modbus- это или RS-485 или RS-422. Hо, чтобы гонять кадры Modbus в Ethernet- это выше моего воображения. Расскажите.

[Rst7]

Покурите это - http://modbus.org/docs/Modbus_Messaging_Im...Guide_V1_0b.pdf