К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
Рад, что статьи пригодятся.
Значит не зря в свое время пошел именно по этому пути:
В 2015 году (когда я впервые рассказал основную идею LLTR) мне предложили сделать свою Ph.D-диссертацию именно на эту тему. Но видя, что получается в итоге у других, защитивших свою диссертацию (все 1в1 как описано в этой заметке), решил сделать что-то лучшее (более полезное для других), чем диссертация.
добавить DOI — для тех, кто захочет сослаться на статьи, используя DOI;
загрузить на GitHub Pages «Часть 0» — для тех, кому понравилось оформление остальных частей на GitHub Pages.
И поделится некоторыми другими вещами, например, из области "Анализ сигналов"+"Учебный процесс в IT": я как-то сделал квест (рассказ/история, совмещенная с задачей — для того, чтобы «открыть» следующую главу истории — нужно выполнить некоторые действия главного героя) для студентов (заочников). История происходит во «вселенной бондианы» (кстати, многие преподаватели не знают про такую возможность, возможно это даже к лучшему — некоторые могут испортить изначальный образ, созданный автором). Вот начало истории, вот info о квесте/курсе, а вот файл, который понадобится для прохождения квеста (он будет генерировать ссылки на «следующие главы») — перед использованием его нужно скопировать в свой Google Drive.
Либо из области "настрой под себя": некоторым людям нравится вид папок/файлов как в Explorer в Windows XP (и старше):
размер иконок 32x32;
имена расположены под иконками
работает автоматическое выравнивание (тот режим, в котором можно вручную менять местами файлы/папки).
На форумах есть хаки, которые это делают, но они нестабильны, и увеличивают нагрузку на CPU. Поэтому я поступил проще — сделал патчи (x64dbg помог мне в этот раз).
Есть и другие патчи, например, один патч восстанавливает в системе четкий «однопиксельный» рендер шрифтов (небольшого размера), для тех программ, которые используют DirectWrite (когда из Chromium удалили рендеринг шрифтов через GDI, оставив только DirectWrite — было много недовольных «размытым текстом»), а т.к. в Windows 10 многие системные утилиты используют именно DirectWrite, то система становится «четкой» :-)
(на самом деле, т.к. в основном в Win10 используется отнюдь не маленький размер шрифта, то эффект мало заметен).
Либо "ADSL (14 Mbps) vs GPON (75 Mbps)" (часть 1), но в них было сделано много предположений, а я так и не смог установить точную причину падения скорости (дропов и ретрансмитов).
Note: мне очень нравился ADSL — со свежими конденсаторами и «подобранными/вычисленными параметрами» я получал 21-23 Mbps (предел скорости входящего потока 24 Mbps) ADSL2+ Annex M (восходящий был 2.1-2.4-2.7 Mbps).
Либо из области фотоники: «всегда хотел сделать для себя процессор». Либо (см. пасхалки).
P.S. После использования bookmarklet'а, я разделил экран на две части (2 окна): в левой — этот tutorial, а в правой — Simulation Manual. Было очень удобно — клик по ссылке в tutorial сразу пролистывает Simulation Manual на нужное место.
Она большая, очень большая. Если «Часть 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-ссылок в абзаце — они начинают отвлекать.
Еще один нюанс (если не устали читать этот поток мыслей)
Иногда авторы используют внутристрочные блоки кода (<code>) для разметки многострочных фрагментов (либо для вывода не кода моноширинным шрифтом), вместо использования <source> или <pre>. При этом код начинает выглядеть как «многострочная колбаска»…
В этом случае поможет «анти-колбасочный стиль»: с border-top-style: none; и border-bottom-style: none;. С ним и границы кода видны, и нет «колбасок». Но в своем UserCSS я не использую его — мне нравится полный вариант border.
P.S. для разметки не кода подходит тег <samp>.
P.P.S. мне вначале показалось, что на help.github.com тоже используется <samp> для вывода «терминала», но оказалось, что там просто использовали <pre class="command-line">.
Нужна помощь: следующая часть будет посвящена разработке, но единственный хаб связанный с сетью в потоке разработка называется Mesh-сети (есть еще близкие хабы: Twisted, «Разработка систем связи» и «Системы обмена сообщениями»).
Нужно выбрать наиболее подходящий хаб для статьи. Точнее наоборот — чтобы статья подходила для читателей этого хаба.
Прототип (модель) протокола будет создаваться в OMNeT++, в котором также моделируют и Mesh-сети. Однако в моей статье не будет ни слова про Mesh-сети.
Код в ней будет написан на C++, но эта статья не про язык/стандарт C++.
В ней будет немного реверс-инжиниринга, но это не основная тема статьи.
разместить в Разработка → Mesh-сети (и в начале статьи извиниться перед его [хаба] читателями)
попросить создать новый хаб, например, Разработка → Сетевые протоколы (но если бы каждый создавал хаб для своей статьи, то получился бы хаос)
В общем, идеального варианта нет.
P.S. было бы здорово, если хабы из Администрирования имели зеркальную копию в Разработке, ведь то, что администрируют изначально было кем-то разработано.
… но оптимальная цепочка пиров все же будет построена, и «полная скорость сети» будет достигнута.
Более корректный ответ: в этих условиях можно не получить оптимальную цепочку — придется делать перебор вариантов. Однако предварительное «сканирование» (LLTR) сети позволит (в некоторых случаях) сократить количество перебираемых вариантов.
Но я не зацикливался на подобных случаях (все равно количество перебираемых вариантов будет велико), оставаясь в пределах оговоренных ограничений:
… все соединения дуплексные, и скорость всех соединений одинаковая.
+ точность результатов сканирования может уменьшить активность сторонних узлов сети в момент сканирования. Это придется учитывать и подстраиваться, что приведет к усложнению алгоритма работы (выбор параметров сканирования, последовательности сканирования, обработка полученных данных).
Поэтому «не все сразу» — при создании модели (Часть 1) добавится еще одно ограничение — отсутствие посторонней активности в сети.
В этой «нулевой» части всего лишь было «немного» теории с "идеальными условиями":
… все соединения дуплексные, и скорость всех соединений одинаковая.
, и встроенным в текст «расширителем кошелка Миллера» (пригодится для следующих частей ;)
В следующих частях я выложу «нюансы» (но конкретно эти условия сохранятся).
И да, для описанной конфигурацией коммутаторов доступа (с портом, скорость которого превышает суммарную скорость основных портов):
коммутаторы доступа имеют производительность того же порядка, что и скорость аплинка
полную (физическую) топологию сети этим способом не получить (это будет выглядеть как один большой свитч, или несколько, если в сети будут «узкие места»), но оптимальная цепочка пиров все же будет построена, и «полная скорость сети» будет достигнута.
А также, если ранее не "замораживали системы" (не использовали immutable/non-persistent хранилища для виртуальных машин, или Aufs/UnionFS, или EWF, или Deep Freeze/Shadow Defender/Comodo Time Machine/…), то столкнетесь с одной проблемой, решение которой заключается в заморозке времени системы (восстановление даты после перезагрузки).
Если не заморозить время (либо периодически не "размораживать" систему), то программы, имеющие встроенный "планировщик заданий" будут со временем все больше и больше тормозить систему.
Поясню: в таких "планировщиках заданий" задания выглядят примерно так: если с момента предыдущего запуска задания прошло больше двух недель, то "запустить задание" (заданием может быть, например, оптимизация кеша {очистка, перестройка}). А т.к. запись о моменте предыдущего запуска хранится на VHD (перезагрузка системы приводит систему в исходное состояние), то спустя 2 недели после заморозки, задание начнет выполняться после каждой перезагрузки (планировщик обновляет дату последнего запуска задания, но после перезагрузки дата возвращается назад, и планировщик опять запускает задание ...).
P.S. важно понимать, что это только часть защиты, остальную часть я нигде не описывал
Но одно из основных правил очень простое:
— все, что можно изменить — нельзя выполнить
и наоборот:
— все, что можно выполнить — нельзя изменить.
Стандартными средствами первое решается с помощью ACL в NTFS и политик.
Второе — с помощью dVHD и ACL в NTFS.
Под «все, что можно изменить» подразумеваются файлы пользователя, хранящиеся на отдельном разделе (вне VHD).
Если пользователю все-таки понадобится выполнить один из своих файлов, то для этого я создал symbolic link / junction point (на разделе в VHD), ведущей к директории с файлами пользователя. Важно, чтобы это была не корневая директория, иначе будет трудно корректно настроить наследование прав доступа (ACL в NTFS).
Ничего нового за это время не появилось (все и так работает). Несколько раз обновлял bat'ники. В статье все ссылки указывают на последнюю версию.
P.S. важно понимать, что это только часть защиты, остальную часть я нигде не описывал (часть из нее в принципе не могу описать), но если это все реализовать, то вполне можно использовать такую систему для хакерских конкурсов (поиск по «hacker vs laptop»).
Да, про него в следующих частях.
Следующая часть («Часть 1») выйдет скоро. Надеюсь, что успею ее обработать (сверстать, ...) менее чем за 1 неделю.
До середины прочитал и у меня чуть не взорвался мозг,… или просто конец рабочего дня о себе дает знать.
Перед публикацией статьи я давал прочитать ее нескольким людям, и одному из них было трудно воспринять всю информацию за один раз. Тогда я ему посоветовал «забить» на текст и посмотреть на схемы (предварительно прочитав в тексте про обозначения). Это ему помогло.
P.S. Я и сам представляю (в голове) все это графически (в виде схем, анимаций, ...).
А неуправляемые комутаторы «превратят» multicast в broadcast.
К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
Значит не зря в свое время пошел именно по этому пути:
Жалко, что не получилось описать больше (создание одной только анимации бинаризации) заняло больше месяца...).
В оставшееся время я хочу еще:
И поделится некоторыми другими вещами, например, из области "Анализ сигналов"+"Учебный процесс в IT": я как-то сделал квест (рассказ/история, совмещенная с задачей — для того, чтобы «открыть» следующую главу истории — нужно выполнить некоторые действия главного героя) для студентов (заочников). История происходит во «вселенной бондианы» (кстати, многие преподаватели не знают про такую возможность, возможно это даже к лучшему — некоторые могут испортить изначальный образ, созданный автором).
Вот начало истории, вот info о квесте/курсе, а вот файл, который понадобится для прохождения квеста (он будет генерировать ссылки на «следующие главы») — перед использованием его нужно скопировать в свой Google Drive.
Либо из области "настрой под себя": некоторым людям нравится вид папок/файлов как в Explorer в Windows XP (и старше):
На форумах есть хаки, которые это делают, но они нестабильны, и увеличивают нагрузку на CPU. Поэтому я поступил проще — сделал патчи (x64dbg помог мне в этот раз).
Есть и другие патчи, например, один патч восстанавливает в системе четкий «однопиксельный» рендер шрифтов (небольшого размера), для тех программ, которые используют DirectWrite (когда из Chromium удалили рендеринг шрифтов через GDI, оставив только DirectWrite — было много недовольных «размытым текстом»), а т.к. в Windows 10 многие системные утилиты используют именно DirectWrite, то система становится «четкой» :-)
(на самом деле, т.к. в основном в Win10 используется отнюдь не маленький размер шрифта, то эффект мало заметен).
Либо "ADSL (14 Mbps) vs GPON (75 Mbps)" (часть 1), но в них было сделано много предположений, а я так и не смог установить точную причину падения скорости (дропов и ретрансмитов).
Note: мне очень нравился ADSL — со свежими конденсаторами и «подобранными/вычисленными параметрами» я получал 21-23 Mbps (предел скорости входящего потока 24 Mbps) ADSL2+ Annex M (восходящий был 2.1-2.4-2.7 Mbps).
Либо из области фотоники: «всегда хотел сделать для себя процессор».Либо (см. пасхалки).
ElasticO++ — An Elastic Optical Network Simulation Framework for OMNeT++
Другая статья "An Elastic Networks OMNeT++-Based Simulator" (она напрямую не связана с ElasticO++).
SimuLTE — LTE User Plane Simulation Model for INET & OMNeT++
Порядок действий: скопировать, вернутся назад (Alt+⍇), запустить.
Запуск:
javascript
”,Альтернативные варианты.
P.S. После использования bookmarklet'а, я разделил экран на две части (2 окна): в левой — этот tutorial, а в правой — Simulation Manual. Было очень удобно — клик по ссылке в tutorial сразу пролистывает Simulation Manual на нужное место.
Неделя пролетела незаметно… Вышла новая часть!Она большая, очень большая. Если «Часть 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-ссылок в абзаце — они начинают отвлекать.<code>
) для разметки многострочных фрагментов (либо для вывода не кода моноширинным шрифтом), вместо использования<source>
или<pre>
. При этом код начинает выглядеть как «многострочная колбаска»…В этом случае поможет «анти-колбасочный стиль»: с
border-top-style: none;
иborder-bottom-style: none;
. С ним и границы кода видны, и нет «колбасок». Но в своем UserCSS я не использую его — мне нравится полный вариантborder
.P.S. для разметки не кода подходит тег
<samp>
.P.P.S. мне вначале показалось, что на help.github.com тоже используется
<samp>
для вывода «терминала», но оказалось, что там просто использовали<pre class="command-line">
.Нужно выбрать наиболее подходящий хаб для статьи. Точнее наоборот — чтобы статья подходила для читателей этого хаба.
Прототип (модель) протокола будет создаваться в OMNeT++, в котором также моделируют и Mesh-сети. Однако в моей статье не будет ни слова про Mesh-сети.
Код в ней будет написан на C++, но эта статья не про язык/стандарт C++.
В ней будет немного реверс-инжиниринга, но это не основная тема статьи.
Варианты:
В общем, идеального варианта нет.
P.S. было бы здорово, если хабы из Администрирования имели зеркальную копию в Разработке, ведь то, что администрируют изначально было кем-то разработано.
Но я не зацикливался на подобных случаях (все равно количество перебираемых вариантов будет велико), оставаясь в пределах оговоренных ограничений:
+ точность результатов сканирования может уменьшить активность сторонних узлов сети в момент сканирования. Это придется учитывать и подстраиваться, что приведет к усложнению алгоритма работы (выбор параметров сканирования, последовательности сканирования, обработка полученных данных).
Поэтому «не все сразу» — при создании модели (Часть 1) добавится еще одно ограничение — отсутствие посторонней активности в сети.
Повествование я хотел строить в направлении от абстракций (Часть 0) к реальным условиям (Часть 7), тем самым полностью описав процесс создания LLTR (таким, каким этот процесс был в реальности).
В этой «нулевой» части всего лишь было «немного» теории с "идеальными условиями":
, и встроенным в текст «расширителем кошелка Миллера» (пригодится для следующих частей ;)
В следующих частях я выложу «нюансы» (но конкретно эти условия сохранятся).
И да, для описанной конфигурацией коммутаторов доступа (с портом, скорость которого превышает суммарную скорость основных портов):
полную (физическую) топологию сети этим способом не получить (это будет выглядеть как один большой свитч, или несколько, если в сети будут «узкие места»), но оптимальная цепочка пиров все же будет построена, и «полная скорость сети» будет достигнута.
А также, если ранее не "замораживали системы" (не использовали immutable/non-persistent хранилища для виртуальных машин, или Aufs/UnionFS, или EWF, или Deep Freeze/Shadow Defender/Comodo Time Machine/…), то столкнетесь с одной проблемой, решение которой заключается в заморозке времени системы (восстановление даты после перезагрузки).
Если не заморозить время (либо периодически не "размораживать" систему), то программы, имеющие встроенный "планировщик заданий" будут со временем все больше и больше тормозить систему.
Поясню: в таких "планировщиках заданий" задания выглядят примерно так: если с момента предыдущего запуска задания прошло больше двух недель, то "запустить задание" (заданием может быть, например, оптимизация кеша {очистка, перестройка}). А т.к. запись о моменте предыдущего запуска хранится на VHD (перезагрузка системы приводит систему в исходное состояние), то спустя 2 недели после заморозки, задание начнет выполняться после каждой перезагрузки (планировщик обновляет дату последнего запуска задания, но после перезагрузки дата возвращается назад, и планировщик опять запускает задание ...).
Но одно из основных правил очень простое:
— все, что можно изменить — нельзя выполнить
и наоборот:
— все, что можно выполнить — нельзя изменить.
Стандартными средствами первое решается с помощью ACL в NTFS и политик.
Второе — с помощью dVHD и ACL в NTFS.
Под «все, что можно изменить» подразумеваются файлы пользователя, хранящиеся на отдельном разделе (вне VHD).
Если пользователю все-таки понадобится выполнить один из своих файлов, то для этого я создал symbolic link / junction point (на разделе в VHD), ведущей к директории с файлами пользователя. Важно, чтобы это была не корневая директория, иначе будет трудно корректно настроить наследование прав доступа (ACL в NTFS).
P.S. важно понимать, что это только часть защиты, остальную часть я нигде не описывал (часть из нее в принципе не могу описать), но если это все реализовать, то вполне можно использовать такую систему для хакерских конкурсов (поиск по «hacker vs laptop»).
Да, про него в следующих частях.
Следующая часть («Часть 1») выйдет скоро. Надеюсь, что успею ее обработать (сверстать, ...) менее чем за 1 неделю.
Перед публикацией статьи я давал прочитать ее нескольким людям, и одному из них было трудно воспринять всю информацию за один раз. Тогда я ему посоветовал «забить» на текст и посмотреть на схемы (предварительно прочитав в тексте про обозначения). Это ему помогло.
P.S. Я и сам представляю (в голове) все это графически (в виде схем, анимаций, ...).