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

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

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

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

Совать сюда 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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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



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



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

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



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



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

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

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

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

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

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

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



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

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

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

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

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

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

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


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

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

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

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

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

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

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



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

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

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

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

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

Камень BF532.

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

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



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



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

B это все!?



Жалко, я ожидал полного разгрома.
Профи по 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-ами.

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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





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

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



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

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

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

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

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

НЕ ВЕРЮ!

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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



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



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



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

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