Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Ваша серия из 3 статей — сокровище для инженеров. Честно скажу — многие вещи я услышал вообще впервые в жизни и вообще как будто читаю про будущее. Отдельное спасибо — за вёрстку, это просто космос. Разослал бывшим и нынешним коллегам ссылку, будем кое-что тащить в практику.
Рад, что статьи пригодятся.
Значит не зря в свое время пошел именно по этому пути:
В оставшееся время я хочу еще:
И поделится некоторыми другими вещами, например, из области "Анализ сигналов"+"Учебный процесс в 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).
Либо из области фотоники: «всегда хотел сделать для себя процессор».
Либо (см. пасхалки).
Значит не зря в свое время пошел именно по этому пути:
В 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).
Либо (см. пасхалки).
В оставшееся время я хочу еще:Сделано.
- добавить DOI — для тех, кто захочет сослаться на статьи, используя DOI;
- загрузить на GitHub Pages «Часть 0» — для тех, кому понравилось оформление остальных частей на GitHub Pages.
Скажите пожалуйста, а нельзя ли для этих целей (передача данных) использовать multicast? Кажется, что для минимизации трафика самое оно.
Извиняюсь, если в статьях был ответ на это предложение.
Ответ кроется в названии[и первом абзаце] части 0: "LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?".
А неуправляемые комутаторы «превратят» multicast в broadcast.
К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
А неуправляемые комутаторы «превратят» multicast в broadcast.
К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
Спасибо за развернутый ответ
На самом деле multicast не такой простой, как кажется на первый взгляд. Чтобы осознать все «нюансы» нужно хоть раз его настроить. Либо прочитать про «проблемы», с которыми сталкиваются при настройке IPTV или радио (в мире основной процент multicast трафика — это IPTV или радио).
Причем, для IPTV/радио, в плане передачи данных, все просто — используется UDP, т.к. потеря пакетов для этих данных не так страшна.
И здесь возникает еще один вопрос: если мы передаем клиентам файл (нужно, чтобы каждый клиент получил полный файл), но в процессе передачи некоторые клиенты не получили часть файла (пакеты отбросились — не дошли до клиентов), то что делать в этом случае?
Решение не так просто, как «клиенты подключаются к серверу, и скачивают (unicast, TCP) недостающие части». А если потерялась (не дошла до клиентов) большая часть файла? Запускать еще одно multicast вещание именно для этих клиентов, но с пониженной скоростью передачи данных? Либо…
Как-то (давно) я писал работу "решение проблемы 'первого часа' в p2p (bittorrent)".
Ссылки «в тему»
Причем, для IPTV/радио, в плане передачи данных, все просто — используется UDP, т.к. потеря пакетов для этих данных не так страшна.
И здесь возникает еще один вопрос: если мы передаем клиентам файл (нужно, чтобы каждый клиент получил полный файл), но в процессе передачи некоторые клиенты не получили часть файла (пакеты отбросились — не дошли до клиентов), то что делать в этом случае?
Решение не так просто, как «клиенты подключаются к серверу, и скачивают (unicast, TCP) недостающие части». А если потерялась (не дошла до клиентов) большая часть файла? Запускать еще одно multicast вещание именно для этих клиентов, но с пониженной скоростью передачи данных? Либо…
Как-то (давно) я писал работу "решение проблемы 'первого часа' в p2p (bittorrent)".
Слайды из нее
(два черных овала с белой обводкой — это сети двух разных «провайдеров»)
(на примере распространения большого обновления для операционной системы)
Часть презентации (с анимацией, которую нормально можно увидеть только в просмотрщике от MS :(
(на примере распространения большого обновления для операционной системы)
Часть презентации (с анимацией, которую нормально можно увидеть только в просмотрщике от MS :(
Ссылки «в тему»
- Multicast: Layer 2 delivery (Wikipedia)
If a switch does not understand multicast addresses then it will flood that traffic to all the members of a LAN; in this case the system's network card (or operating system) has to filter the packets sent to multicast groups they are not subscribed to.
- Layer 2 Multicasting (презентация)
- Multicast in LANs (IGMP Snooping: Pure L2 Switch, L3 Switch)
- Multicast on Wireless
- Оптимизация передачи multicast-трафика в локальной сети с помощью IGMP snooping (Хабр, ksg222 )
По умолчанию коммутатор передаёт multicast-трафик как broadcast (широковещательный), т.е. на все порты без исключения. Это обусловлено тем, что...
- Все статьи на Хабр с тегом multicast
Вопрос передачи через multucast udp частично решен в uftp, кроме ручного указания скости.
А так все верно, нюансов масса. Но и простора для творчества.
Например, первичная передача через multicast, затем передача потерянных данных по принципу ringsync, или, например, частичная синхронизация в рамках одного свитча, затем запрос остальных частей в источнике.
Хорошо начинать знакомство с передачей файлов через мультикаст по ссылке на этот RFC:
tools.ietf.org/html/rfc6968
tools.ietf.org/html/rfc6968
И заодно (в дополнении к References):
Но, как я уже писал, в сети, в которой multicast «превращается» в broadcast — это все перестает иметь смысл :(
- Fcast multicast file distribution: “Tune in, download, and drop out” (1999 год)
- Fcast Scalable Multicast File Distribution: Caching And Parameter Optimizations (DOI: 10.1109/65.819172)
Но, как я уже писал, в сети, в которой multicast «превращается» в broadcast — это все перестает иметь смысл :(
КМК, сеть на неуправляемых коммутаторах — это не индустриальное решение.
Решать индустриальные проблемы с помощью неиндустриальных решений никто никому запретить, конечно же, не может.
Спасибо за первую ссылку.
Решать индустриальные проблемы с помощью неиндустриальных решений никто никому запретить, конечно же, не может.
Спасибо за первую ссылку.
Приходилось использовать то, что было.
С другой стороны, если бы все не было так плохо, то бы и этого всего (исследований, серии статей, ...) тоже не было…
(все это напоминает фрагмент из первого "Железного человека" — заперли в «катакомбы», под рукой только металлолом, и нужно сделать...)
Спасибо за комментарии.
С другой стороны, если бы все не было так плохо, то бы и этого всего (исследований, серии статей, ...) тоже не было…
(все это напоминает фрагмент из первого "Железного человека" — заперли в «катакомбы», под рукой только металлолом, и нужно сделать...)
Намек на место, где это происходило
Порой решать индустриальные проблемы в некоторых государственных университетах весьма затруднительно.
Спасибо за комментарии.
Нашел свою старую заметку "интересных протоколов, в которых используется multicast":
- Nack-Oriented Reliable Multicast (NORM) Protocol (RFC 5740; включен в RFC 6968)
- Multicast Dissemination Protocol (MDP)
- Optimized Link State Routing (NRL-OLSR)
- Neighborhood Discovery Protocol (NRL-NHDP)
- Simplified Multicast Forwarding (NRL-SMF) for MANETs
- OSPF MANET Designated Routers
Как раз для рассылки файла мультикастом с защитой от потерь выгодно применить фонтанное кодирование. Существует ряд RFC (RFC3453, RFC5053), предлагающих стандарты для подобных применений фонтанных кодов.
Суть самого фонтанного кодирования состоит в том, что из исходного набора данных порождается неограниченное количество блоков. Принимающая сторона, получив достаточное количество полезных блоков, может с высокой степенью вероятности восстановить полное сообщение. У современных алгоритмов крайне низкая избыточность передачи — порядка нескольких лишних блоков (по сравнению с линейным разбиением на блоки) дают вероятность получения данных >99.99%.
Пользуясь такими алгоритмами, передачу можно просто не прекращать никогда — у неё нет начала и конца.
Суть самого фонтанного кодирования состоит в том, что из исходного набора данных порождается неограниченное количество блоков. Принимающая сторона, получив достаточное количество полезных блоков, может с высокой степенью вероятности восстановить полное сообщение. У современных алгоритмов крайне низкая избыточность передачи — порядка нескольких лишних блоков (по сравнению с линейным разбиением на блоки) дают вероятность получения данных >99.99%.
Пользуясь такими алгоритмами, передачу можно просто не прекращать никогда — у неё нет начала и конца.
Да. В теории такой код называется "идеальный код" (Клод Шеннон).
P.S. жалко, что ветка комментариев не та — RFC3453 упоминается в RFC 5740 (здесь), а RFC 5740 я упомянул в этой ветке комментариев.
P.S. жалко, что ветка комментариев не та — RFC3453 упоминается в RFC 5740 (здесь), а RFC 5740 я упомянул в этой ветке комментариев.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LLTR Часть 2: Алгоритм определения топологии сети по собранной статистике