Комментарии 15
Ваша серия из 3 статей — сокровище для инженеров. Честно скажу — многие вещи я услышал вообще впервые в жизни и вообще как будто читаю про будущее. Отдельное спасибо — за вёрстку, это просто космос. Разослал бывшим и нынешним коллегам ссылку, будем кое-что тащить в практику.
+5
Рад, что статьи пригодятся.
Значит не зря в свое время пошел именно по этому пути:
В оставшееся время я хочу еще:
И поделится некоторыми другими вещами, например, из области "Анализ сигналов"+"Учебный процесс в 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).
Либо (см. пасхалки).
+1
В оставшееся время я хочу еще:Сделано.
- добавить DOI — для тех, кто захочет сослаться на статьи, используя DOI;
- загрузить на GitHub Pages «Часть 0» — для тех, кому понравилось оформление остальных частей на GitHub Pages.
+1
Скажите пожалуйста, а нельзя ли для этих целей (передача данных) использовать multicast? Кажется, что для минимизации трафика самое оно.
Извиняюсь, если в статьях был ответ на это предложение.
+2
Ответ кроется в названии[и первом абзаце] части 0: "LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?".
А неуправляемые комутаторы «превратят» multicast в broadcast.
К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
А неуправляемые комутаторы «превратят» multicast в broadcast.
К тому же RingSync использует TCP (в том числе и для контроля скорости отправки данных).
А если использовать multicast (в сети с управляемыми коммутаторами или маршрутизаторами), то придется «вручную» подстраиваться под скорость самого медленного пира.
P.S. а в остальном — да, если получится использовать в сети multicast, и он будет хорошо работать, то лучше использовать именно multicast.
+2
Спасибо за развернутый ответ
0
На самом деле 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
0
Вопрос передачи через multucast udp частично решен в uftp, кроме ручного указания скости.
А так все верно, нюансов масса. Но и простора для творчества.
Например, первичная передача через multicast, затем передача потерянных данных по принципу ringsync, или, например, частичная синхронизация в рамках одного свитча, затем запрос остальных частей в источнике.
+1
Хорошо начинать знакомство с передачей файлов через мультикаст по ссылке на этот RFC:
tools.ietf.org/html/rfc6968
tools.ietf.org/html/rfc6968
+1
И заодно (в дополнении к 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 — это все перестает иметь смысл :(
0
КМК, сеть на неуправляемых коммутаторах — это не индустриальное решение.
Решать индустриальные проблемы с помощью неиндустриальных решений никто никому запретить, конечно же, не может.
Спасибо за первую ссылку.
Решать индустриальные проблемы с помощью неиндустриальных решений никто никому запретить, конечно же, не может.
Спасибо за первую ссылку.
0
Приходилось использовать то, что было.
С другой стороны, если бы все не было так плохо, то бы и этого всего (исследований, серии статей, ...) тоже не было…
(все это напоминает фрагмент из первого "Железного человека" — заперли в «катакомбы», под рукой только металлолом, и нужно сделать...)
Спасибо за комментарии.
С другой стороны, если бы все не было так плохо, то бы и этого всего (исследований, серии статей, ...) тоже не было…
(все это напоминает фрагмент из первого "Железного человека" — заперли в «катакомбы», под рукой только металлолом, и нужно сделать...)
Намек на место, где это происходило
Порой решать индустриальные проблемы в некоторых государственных университетах весьма затруднительно.
Спасибо за комментарии.
0
Нашел свою старую заметку "интересных протоколов, в которых используется 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
+1
Как раз для рассылки файла мультикастом с защитой от потерь выгодно применить фонтанное кодирование. Существует ряд RFC (RFC3453, RFC5053), предлагающих стандарты для подобных применений фонтанных кодов.
Суть самого фонтанного кодирования состоит в том, что из исходного набора данных порождается неограниченное количество блоков. Принимающая сторона, получив достаточное количество полезных блоков, может с высокой степенью вероятности восстановить полное сообщение. У современных алгоритмов крайне низкая избыточность передачи — порядка нескольких лишних блоков (по сравнению с линейным разбиением на блоки) дают вероятность получения данных >99.99%.
Пользуясь такими алгоритмами, передачу можно просто не прекращать никогда — у неё нет начала и конца.
Суть самого фонтанного кодирования состоит в том, что из исходного набора данных порождается неограниченное количество блоков. Принимающая сторона, получив достаточное количество полезных блоков, может с высокой степенью вероятности восстановить полное сообщение. У современных алгоритмов крайне низкая избыточность передачи — порядка нескольких лишних блоков (по сравнению с линейным разбиением на блоки) дают вероятность получения данных >99.99%.
Пользуясь такими алгоритмами, передачу можно просто не прекращать никогда — у неё нет начала и конца.
+1
Да. В теории такой код называется "идеальный код" (Клод Шеннон).
P.S. жалко, что ветка комментариев не та — RFC3453 упоминается в RFC 5740 (здесь), а RFC 5740 я упомянул в этой ветке комментариев.
P.S. жалко, что ветка комментариев не та — RFC3453 упоминается в RFC 5740 (здесь), а RFC 5740 я упомянул в этой ветке комментариев.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LLTR Часть 2: Алгоритм определения топологии сети по собранной статистике