LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?

Для восстановление сети из неуправляемых коммутаторов после грозы потребуется очень много времени и ресурсов! (с) forum.nag.ru

До середины прочитал и у меня чуть не взорвался мозг, особенно в выборе unicast src и dst или просто конец рабочего дня о себе дает знать.
Программный сканер-то написали уже? Который бы рисовал гипотетическую топологию?

Интересно!
Но в основе идеи лежат «идеальные» свичи. В то время как реальные коммутаторы доступа имеют производительность того же порядка, что и скорость аплинка.

Нужна помощь: следующая часть будет посвящена разработке, но единственный хаб связанный с сетью в потоке разработка называется Mesh-сети (есть еще близкие хабы: Twisted, «Разработка систем связи» и «Системы обмена сообщениями»).
Нужно выбрать наиболее подходящий хаб для статьи. Точнее наоборот — чтобы статья подходила для читателей этого хаба.

Прототип (модель) протокола будет создаваться в OMNeT++, в котором также моделируют и Mesh-сети. Однако в моей статье не будет ни слова про Mesh-сети.
Код в ней будет написан на C++, но эта статья не про язык/стандарт C++.
В ней будет немного реверс-инжиниринга, но это не основная тема статьи.

Варианты:

• разместить в Администрирование → Сетевые технологии (но статья не относится к администрированию)
• разместить в Разработка → Mesh-сети (и в начале статьи извиниться перед его [хаба] читателями)
• попросить создать новый хаб, например, Разработка → Сетевые протоколы (но если бы каждый создавал хаб для своей статьи, то получился бы хаос)

В общем, идеального варианта нет.

_{P.S. было бы здорово, если хабы из Администрирования имели зеркальную копию в Разработке, ведь то, что администрируют изначально было кем-то разработано.}

Неделя пролетела незаметно … Вышла новая часть!

Она большая, очень большая. Если «Часть 0» (эта часть) занимала 20 страниц, то «Часть 1» занимает 138 страниц (вместе с содержимым спойлеров). Сейчас некоторые сайты показывают время чтения статьи (например: «6-12 мин.»), ну что же, если бы на Хабре было такое поле, то в нем было бы написано «4-6 дн.» … хорошо, что такого поля нет.
И, т.к. это tutorial, а они обычно предполагают воспроизведение действий читателями, то в конце добавил опрос, чтобы узнать, сколько людей дошли до конца, и пора ли публиковать следующую часть.

Заодно обновил UserCSS (только с ним я могу читать такие «объемные» тексты).
Изменений несколько, и все они связаны с <code>.

---

Первое изменение можно назвать "Anti quotes-hell".
Допустим, есть фрагмент кода, который читатель может скопировать и использовать (вставить в командную строку, код программы, …) (эффект лучше заметен, если для основного текста и для inline-<code> используется один и тот же размер шрифта):

• foo + bar + 19
• -foo=bar
• foo + bar & baz + zzz

Где здесь код, и где текст? Точнее где здесь границы кода?

Чтобы границы были лучше видны, я заключаю блоки кода в кавычки:

• “foo + bar +” 19
• “-foo=bar ”
• “foo + bar” & “baz + zzz”

Но как это будет выглядеть, если сам блок кода содержит кавычки в начале и конце (например, чтобы показать, что число надо задавать в виде строки):

• “"8"”
• “"foo" + "bar"”
• “"6" + "9" == "69"”

Слишком много кавычек. При большой концентрации кавычек в тексте они перестают помогать и начинают отвлекать. Получается рябь/мусор из кавычек.

Поэтому я (как читатель) предпочитаю подсвечивать фон и границы блоков кода. У меня это настроено в стилях браузера (UserCSS).

Поэтому я (как писатель) предпочитаю, вместо задания визуального представления (использования кавычек) в разметке — разделять разметку и оформление (подсвечивание фона и границ блоков кода). То есть писать так:

• foo + bar + 19
• -foo=bar
• foo + bar & baz + zzz

И как раз здесь возникает проблема, если начальные стили сайта (AuthorCSS) не задавали фон/границу для внутристрочных блоков кода, и заходит читатель, который в своем UserCSS не задает оформление внутристрочных блоков кода.

Поэтому мне (как писателю) приходится добавлять кавычки (получая в итоге «quotes-hell»), и (как читателю) использовать UserJS, который убирает обрамляющие блоки кода кавычки.

---

Второе изменение убирает фон у внутристрочных блоков кода.
Если сравнить два представления одного и того же текста: одно — оригинальное (без UserCSS; без затенения фона у <code>), другое — измененное (с UserCSS), то в измененном варианте <code> начинают акцентировать на себя внимание. Но автор текста не хотел делать акцент на всех <code>! Для создания акцента он использует <strong> (и <em>).

Решение проблемы: убрать затемнение фона, но оставить чуть заметный border.
Кстати, после этого изменения, кажется что <code> дополнительно подсвечены изнутри, т.е. кажется, что их фон ярче, чем фон обычного текста.

И что самое приятное — теперь мы можем при помощи затемнения фона создавать акцент на выборочных <code> с использованием разметки: <strong><code>...</code></strong>!

Похоже, в GitHub при создании help.github.com задумались об этом, и пришли к тому же выводу. И дополнительно добавили изменение цвета border для случая <a><code>...</code></a> — я попробовал добавить это в UserCSS, и оказалось, что при большой концентрации code-ссылок в абзаце — они начинают отвлекать.

---

Похоже, через Yandex многие ищут «OMNeT++ учебник на русском» (запрос подсказки для "OMNeT++"):

(
    GET /suggest-opera?part=OMNeT%2B%2B&n=5 HTTP/1.1
    Host: suggest.yandex.ru
    Accept-Language: ru
)(
    ["omnet++",["omnet++","omnet++ учебник на русском", ...]]
)

В Google тоже есть похожие запросы:

(
    GET /complete/search?q=OMNeT%2B%2B&client=opera&hl=ru HTTP/1.1
    Host: clients1.google.com
    Accept-Language: ru
)(
    ["OMNeT++",[4x...,"omnet++ на русском","omnet++ installation guide",...]]
)

Вполне подходящие название для «Часть 1»: это tutorial (учебник), он про OMNeT++, и он написан кириллицей :-)
Да будет так: "OMNeT++ учебник на русском".