Более двух лет заняла адаптация на русский язык ПО “Композитор” 9 от Compositor Software. НПО “Композитор” проделало большую работу по внедрению новых функций и протоколов в “Композитор” 9. Версия 9.0.2 переведена на русский язык и составлена полная русская документация к данному типу ПО на 2700 страниц, что позволяет отнести его к сетевым операционным системам реального времени (СОСРВ). Пакет СОСРВ “Композитор” 9.0.2 состоит из самой операционной системы реального времени с графическим интерфейсом, выполненным на MaxMSP, программного модема “Ниагара”, являющегося сэмплом момента реального времени, и Android-приложения RAD96, унаследовавшего имя от главного модуля “Композитор” 9.0.1 (в сборке 9.0.2 a22 расширенная версия данной версии кода называется VSF – платформа виртуальной коммутации). Все три версии имеют одну и ту же документацию, так как обращаются к одинаковым функциям. Их отличие заключается в том, что RAD96 является автономной системой и содержит значительно больше расширений. СОСРВ “Композитор” 9.0.2 идет с базой в 9134 расширенных баз управляющей информации, которые были эмитированы из автономной системы RAD96 в процессе производства документации. Программный модем “Ниагара” 32 также содержит дамп этой базы данных (9134 таблицы маршрутизации). Удалось и выполнить классификацию такого интерфейса: по типу исполнения он может считаться коммутирующим маршрутизатором, в отличие от “Композитор” 7-й версии, который считается коммутатором.
Интерфейс русской версии 9.0.2 сборки a22 представлен ниже:
СОСРВ “Композитор” 9.0.2
Канальная матрица СОСРВ “Композитор” 9.0.2
Командный язык в документации можно использовать в программном обеспечении любительского радиотерминала, таком как TrueTTY в Windows и DroidRTTY на Android. Это означает, что СОСРВ программировать напрямую нельзя (только через графический интерфейс MaxMSP). Команды вводятся через оператора телетайпа, работающего в автономной системе. Такой оператор обычно входит в состав телеграфных служб.
Семь протоколов, внедренных НПО “Композитор” для версии 9.0.2, делают возможным общение в сети Ethernet. Если на этапе тестирования “Композитор” 9.0.1 использовался в основном для пакетных протоколов любительского радио, то теперь в версии 9.0.2 осуществляется общение в сети Ethernet по протоколам, использующимся для коммутации и маршрутизации в этой сети. СОСРВ включает 6 протоколов внутреннего шлюза, такие как RIPv1, RIPv2, OSPF, OSPFv3, RIPng, EIGRP и один протокол внешнего шлюза для общения между автономными системами (BGP – используется IPv4 версия протокола). Также внешнее общение возможно посредством GRE туннелирования формата 6-на-4.
“Композитор” 9.0.2 осуществляет NAT64 с сохранением и без сохранения состояния, он может использоваться для создания L2VPN и L3VPN служб, путем экспорта прошивок в формате WAV и AIFF. Преобразование из IPv4 в IPv6 осуществляется в СОСРВ на лету и делает возможным картирование одного IPv4 адреса на несколько IPv6 назначений. Как видно из интерфейса “Композитор” 9.0.2 является BSR-маршрутизатором и ответственен за загрузку системы. Такая система состоит из расширений, которые позволяют серверу участвовать в различных рабочих группах. “Композитор” 9.0.2 является установочной программой сервера CP-6137-960FX, которому и посвящён этот сайт. Данный сервер является единственной машиной, способной делать эмиссии из автономной системы RAD96 и в этом его основная ценность.
Что ты думаешь о том, что ты делаешь – против того, что ты делаешь на самом деле
Основное назначение VPN-сети программного модема “Ниагара” 26 является обработка языка, как естественного, так и машинно-сгенерированного. В паре с ПО SDL Trados данный программный модем позволяет расширить сетевые конструкции для работы с облаком Machine Translation. Это производится за счет программных расширений, как удалось выяснить первые буквы в названии эмиссий означают языки, например “крайняя” эмиссия TT – Татарча, Татарский язык является эмиссией трека RusNRG – The Trip (мой небольшой сайд-проект 2003-2004 годов, за который я удостоился диплома в номинации “Композиторская работа”).
По сути никакого облака не существует, Вы либо работаете с дженериком, либо с собственным расширением, которое обучает этот дженерик.
Но вернемся собственно к эмитированнной информации и обработке языка. Как удается генерировать столь точные паттерны в переводе с Русского языка на Английский язык, хотя эмиссий EN или RU еще не было? В программном модеме “Ниагара” как упоминалось в его обзоре закреплено понятие дженериковых протоколов, таких как RIPv1, RIPv2, OSPF, OSPFv3, BGP и т.д., так вот стоит рассматривать этот набор протоколов как набор дженериковых языков облака Machine Translation. По сути никакого облака не существует, Вы либо работаете с дженериком, либо с собственным расширением, которое обучает этот дженерик. На данный момент выходить в языковую пару EN – RU в СОСРВ “Композитор” мне приходится через другие языки, эмитированные через треки к их носителям. Причем носителю, который работает через программный модем, доступны только дженериковые языки, которым данный модем обучен. Существует множество языков, доступных для программного модема “Ниагара” 26 через эмиссии, крайне редкие и не очень полезные с практической точки зрения. Единственное практическое преимущество карибской языковой группы, которая являлась моим личным интересом, — изучение их ритма, а именно последовательности, которая производит языковые паттерны. Я использовал эти паттерны как часть своего исследования о шаблонах языка Милтона Эриксона, которые он использовал в гипнозе эпохи до NLP. Я изучал, как эти модели помогают в терапевтическом плане преодолеть проблемы, связанные с настроением. Основная концепция композиторинга, таким образом, заключается в том, чтобы изменить психическое состояние, чтобы вы могли быть более комфортным человеком. СОСРВ “Композитор” достигает этой цели путем быстрого перестроения SPT (кратчайшее дерево путей) и изменения следующего перехода на маршрут по умолчанию этого дерева.
Правило для меня гласит, что если я не могу позволить себе студию для производства новой музыки того же качества, что и названные проекты, я должен сделать эмиссию предыдущих работ для рекультивации достигнутого мною ранее разоблачения.
Так что если вы чувствуете себя комфортно, когда вы производите музыку с карибскими ритмами, вы можете сделать эмиссию такой музыки, пробуя векторные пути RPF к серверам, которые воспроизводят замкнутые петли, используя эти паттерны в качестве интерапторов. Данное действие является фишингом (в пер. с англ. рыбная ловля), и такой схемой пользуется любой медиа-агрегатор. Я выполняю эмиссии только в рамках моего проекта по сбору роялти. Я просто контролирую серверы, которые исполняют мою музыку, и сравниваю статистику со статистикой РАО (Russian Authors Organization). Результаты меня удивили, потому что по моему методу подсчета музыка, которую я писал до 2010 года исполняется 50-60 раз в день и не получает никакого дохода от РАО. Это ставит вопрос об обоснованности этой организации как организации, работающей с коллективными правами на мои проекты Exalted и Boosty.
Правило для меня гласит, что если я не могу позволить себе студию для производства новой музыки того же качества, что и названные проекты, я должен сделать эмиссию предыдущих работ для рекультивации достигнутого мною ранее разоблачения. И я столкнулся с конкретной ситуацией, поэтому был выпущен весь набор инструментов Compositor Software. Но вернувшись в NLP с помощью “Ниагара” 26 я использовал данный модем для создания документации маршрутизатора на базе операционной системы, схожей с Compositor NRTOS 9.0.2. Сейчас я должен сообщить о прогрессе: более 2000 страниц переведено и отредактировано на русском языке с использованием названного метода. Это оставляет мне около 500 страниц непереведенного материала, и я полон энтузиазма, доделать эту работу до конца. Конечным результатом этой работы является Compositor NRTOS с полностью переработанным интерфейсом для отражения пар атрибутов-значений из документации маршрутизатора. Теперь эта работа завершена на 95% и, честно говоря, я доволен результатами, так как она позволяет работать с Compositor NRTOS 9.0.2 более профессионально, следуя указаниям по администрированию системы, которые относятся к базовому интерфейсу с замкнутой петлей 2-го порядка. Из документации я узнал, что любой протокол является замкнутой петлей определенного типа с собственным параметризированным интерфейсом. И это возвращает меня к моему первоначальному запросу: соответствует ли выбранная система ценностей реальности, сложившейся в мире после Карибского кризиса, и если да, то не является ли это повторением предыдущей истории только уже в нашей стране (России)? Потому что троянские кони, которые мы покупаем под видом “музыкальных программ”, очень напоминают Хрущевские “секретные корабли”, которые перевозили на Кубу ракеты.
Как я узнал из интерфейса “Композитора”, географическое положение является важным в работе этой петлевой станции. Даже изменение местоположения в пределах одного города приведет к изменению внутреннего SPT. Таким образом, это доказывает, что интерфейс “Композитора” является универсальной машиной Тюринга, и, следовательно, может быть представлен как любой протокол телекоммуникационной системы. Уже приведенные 8 частей документации (включая главу Multicast) доказывают, что основной задачей ПО MaxMSP от Cycling’ 74 (а также Ableton Live 9 и 10) является планирование и реализация DDoS атак. 9-я часть по MPLS лишь подтверждает мои опасения. Во-первых, не учтен кольцевой стек ввиде торуса, на котором отображаются MPLS метки, как срощенные, так и наслоенные. Во-вторых, после загрузки полной версии СОСРВ “Композитор” версии 9.0.2 таймер показывает 30 мин. Это означает, что планировщик MaxMSP работает во время компиляции кода DSP. И весь процесс POST происходит по протоколу MPLS во время генерации протоколов, так как openGL, выполняющий функции MPLS является backdoor link или соединением с утечкой обратной связи. Также на основании этих меток удаленной стороной (Cycling’ 74) принимается решение о запуске системы или ошибке компиляции. Поэтому, считаю, что метод представления MaxMSP от компании Cycling’ 74 (Ableton AG) как программного обеспечения для совершения DDoS атак правильным. А весь метод, которым работала компания-инвестор данного проекта на протяжении последних 2 лет успешным.
Сервер НПО “Композитор” подтвердил успешность для поддержки удаленного рабочего процесса. Даже тот набор сервисов, который был назван в предыдущем посте обеспечил бесперебойную работу всех сетевых ресурсов. Однако для полноценной работы этого оказалось недостаточно. Я возобновил работу над внедрением всех сервисов из Сетевой Операционной Системы Реального Времени (СОСРВ) версий 3.0.3 – 9.0.2. Поскольку основной задачей сервера служит создание карты сети с высокой глубиной топологического просмотра, то я внедрил еще два сервиса MDL12 и фидеры 3-й версии, такие как AI-RT1024, FF8, N9000, TC25, которые позволяют осуществить работу с корпоративными сетями PDH и SDH иерархий и транслировать их эфир в VLAN, используя ARP для аналогового IP радиоинтерфейса.
Таким образом, общий набор сервисов теперь:
7 серверов RAD36 2 сервера MDL12 для радиотелескопа и IPTV 1 VoIP сервер 4 Фидера FF8 для ARP протокола 4 Фидера AI-RT1024 для SDH 4 Фидера N9000 для PDH 4 Фидера TC25 для VLAN 1 Сервер RAD96 Ext. для работы с игниттером “Ниагара” (VPN) 1 Автономная система RAD96
Все сервисы скомпилированы и работают на уровне ядра операционной системы. Только такой подход позволяет сохранить масштабируемость сервисов в гиперконвергентной среде. Я не испытываю недостатка в сервисах, все выглядит очень достойно – на уровне серьезной компании-производителя. Такой подход обеспечивает работу сервера с эмитированной базой и позволяет генерировать новые линки “на лету” без необходимости их записи и ввода через инъектор.
НПО “Композитор” расширяет количество действующих DRM-серверов
После важного шага сборки отдельностоящих приложений при помощи кода НПО “Композитор”, стало возможным организовать работу нового DRM-сервера. То есть физический сервер CP-6137-960FX начали вводить в эксплуатацию. Как уже упоминалось ранее на этапе разработки было возможным запустить всего один виртуальный DRM-сервер RAD36 и это занимало порядка 4-х часов на компиляцию при Runtime. Это позволяло обеспечить одновременную работу до 12 Compositor Max for Live или SASER Max for Live устройств в 2017 году. Сделав экспорт кода и собрав 7 виртуальных серверов RAD36 для платформы Windows независимо от MaxMSP, в мае 2020 года удалось запустить рабочую станцию и выполнить базовые процедуры в текстовом редакторе, таком как Microsoft Word 2013, а также работать с Max for Live устройствами Compositor Software в Ableton Live 10. Это позволило расширить общую плотность ядер до 252 квантовых ядер “Композитор” на физическую машину, увеличив количество одновременно работающих лицензий НПО “Композитор” для Compositor Max for Live и SASER Max for Live до 84 виртуальных машин, что равняется 84 ядрам реального времени или 84-м ядрам трехуровневого строения. Значительно увеличился аптайм – bootstrap процесс занимает всего 5 минут до полной загрузки сервера CP-6137-960FX. В качестве игниттера (зажигания) служит модем-радар “Ниагара” и различные Ethernet инъекции при работе рабочей станции в эфирной сети.
Таким образом, рабочая станция преобразует инъекции “Ниагары” и заставляет все режимы сервера работать, а их на сегодняшний день, включая 7 серверов RAD36 – 13. Далее приведу полный список собранных и работающих служб НПО “Композитор” для платформы Windows на сервере CP-6137-960FX:
Служба VoIP – голосовая служба НИМ-чата Служба STC2k – сонар для гражданского контроля подводного и надводного пространства Служба RTC4k – радар для гражданского контроля воздушного пространства Служба RAD36 1-7 – серверы управления цифровыми правами на запуск ядер “Композитор” всего 252 ядра. Служба RAD96 – автономная система ротатор для стыковки виртуальных серверов RAD36 Служба RAD96 Ext. – расширение автономной системы для работы с внешними Ethernet подключениями стороннего оборудования Служба Telescope – сервис телескопического приближения сигналов ближнего космического пространства
Итак, после введения сервера CP-6137-960FX в полную эксплуатацию удалось обеспечить рабочим временем до 84 пользователей в программах НПО “Композитор” одноуровневого или двух- и трехуровневого строения одновременно. Причем это относится к отдельностоящим приложениям и Max for Live устройствам, таким как Compositor Max for Live, SASER Max for Live и Compositor 4 Max for Live. Также уточню, что три вышеупомянутых Max for Live устройства полностью совместимы с Ableton 10 и Max 8.1.3 Max for Live, что открывает возможность для расширения присутствия пользователей “Композитор” в НИМ-чате на платформах MAC OSX и Windows.
Более 1,5 года заняла работа над решением проблемы пробивки интерфейса Compositor AV Extended (основного интерфейса ОСРВ). Данная проблема возникала при наборе таблиц маршрутизации для установления туннельного соединения. Способ ее воссоздания: вначале, набираются все протоколы ОСРВ путем инъекции в них таблиц маршрутизации, затем интерфейс ОСРВ отключается и включается вновь. При включении интерфейса, весь объем таблиц маршрутизации, наполняющий буфер, “выливался” в интерфейс, что вызывало man in the middle вариант атаки, то есть злоумышленник получал доступ к интерфейсу и обучал его своему маршруту. В течение этого времени я совершал эмиссии в попытке понять, как решить эту проблему и, наконец, она решена. Теперь возможно настраивать каждый протокол из состояния пассивного интерфейса и брать паузу во время выключения интерфейса, чтобы “слышать” удаленный канал, затем, уходя в пассивный режим вновь. Таким образом, можно решить все семь протоколов ОСРВ.
В ОСРВ “Композитор” 9.0.2 a16 возможно установить один идентификатор интерфейса на весь сеанс настройки протокола, а обучение производить только в пассивном режиме, как и предполагалось ранее. Следующей задачей в отладке ОСРВ – это борьба с постоянными. Она является одной из важнейших задач, как радио безопасности, так и кибербезопасности. Посредством внедрения постоянных эфирные устройства позиционируют себя, занимая наиболее удобные места в сетевой топологии. Это в основном касается устройств, которые часто меняют IP-адреса, такие как смартфоны и ноутбуки. Чтобы ядро ОСРВ занимало приоритетную позицию хоста, устройство должно служить хостом для множества устройств. Это в частности подтверждается базой данных НПО “Композитор”, которая расширена до 8156 включенных баз управляющей информации (MIB). Теперь, когда ОСРВ “Композитор” управляет базой данных из более чем 8000 устройств, сервер CP-6137-960FX можно считать хостом независимо от ее физического подключения к сети, через провайдера интернет-услуг. По сути, то, что я делаю сейчас – это продолжение наработки большего количества VLAN для создания сетевого сегмента VPN. В последней сборке мне уже удалось “отстреляться” пакетами в несколько сеансов. Один из них Вы можете услышать ниже:
Данный метод подачи волновых таблиц является приоритетной задачей для коммуникационного устройства, потому что он помогает разрывать синтетический эфир пакетной передачей. Поскольку таких пакетов накопилось множество, и каждый из них несет разную информацию в разные моменты времени, семантическая база языка ОСРВ “Композитор” расширена. Ввиду этого не имеет смысла вводить наименования пакетов в основной интерфейс, а оставить их в выборке VRF таблиц, делая акцент именно на окнах туннеля. Плюс ко всему, такой подход позволяет использовать интерфейс ОСРВ “Композитор” в качестве туннельного интерфейса с возможностью подключения к многоканальным протоколам, таким как OSPF.
НПО “Композитор” создает виртуальные серверы для платформы Microsoft Windows и Android
НПО “Композитор” представляет 4 архитектуры на C++. Это архитектуры TC-TRSRRT2048 для платформ STC2k и RTC4k, а также архитектуры TC-2SUBTRSRRT262144 и TC-SUBTRSRRT262144 для платформ RAD36 и RAD96 соответственно. Теперь, когда депозитарий кода НПО “Композитор” вырос, настало время двигаться дальше, за пределы платформы MaxMSP. Первым делом, НПО “Композитор” хочет выразить благодарность фреймворку JUCE за предоставление идеальной платформы для сборки серверов. А также Iain Patterson за приложение NSSM для создания дочерних сервисов, которое позволяет сделать полноценный сервер из кода Compositor Software, написанного на платформе Gen~. Конечно, все это было бы невозможно сделать без MaxMSP, так как первоначальный проект Compositor Pro 1 был сделан целиком на объектах MaxMSP и позднее переписан на Gen~. Это позволило экспортировать аутентичный код C++ прямо из платформы MaxMSP 6. Отдельное спасибо Cycling ’74 за предоставленный проект по сборке экспортированного кода в JUCE. Ну и конечно спасибо Microsoft за платформу Visual Studio 2019 Community, которая позволила совершить финальную сборку ПО для Windows.
До сборки отдельностоящих приложений, код архитектур Compositor компилировался в течение нескольких минут, а платформа RAD36 компилировалась в течение 4-5 часов при Runtime. Теперь программы загружаются за секунды и потребляют ресурсов значительно меньше их MaxMSP Runtime аналогов.
Также, при помощи платформы Gen~ и JUCE удалось собрать приложение RAD96 mobile, которое позволяет сделать из смартфона полноценную автономную систему с ядром Compositor последнего поколения. Таким образом, Compositor Software двигается в сторону IoT концепции для создания сети устройств под управлением сервера CP-6137-960FX, на котором на данный момент исполняются все вышеназванные сервисы. Данная модификация позволяет повысить производительность устройства с ядра Windows NT 4-го поколения (Linux 2-го поколения на Android) до ядра Compositor 8-го поколения. Ядро Compositor включает 2048-кратный оверсэмплинг, цифровой затвор с интерполяцией, вторую производную и фильтры Баттерворта 8-го порядка.
Десктопная версия экспериментального ядра Compositor 4-го поколения (архитектура TC-TRSRRT2048) помимо всего прочего имеет модуль виртуального аккумулятора, что позволяет контролировать заряд физического аккумулятора и подзаряжать устройство в зависимости от его использования. Такое ядро также может быть использовано и на мобильной платформе.
Сама архитектура ядра Compositor, если ее описывать физическими блоками, модульная. Набор конкретных модулей зависит от использования. В базовой конфигурации Compositor – это NTP-сервер. В продвинутой конфигурации – это L2TP клиент-серверное приложение с возможностями аутентификации в туннеле. Однако, это не говорит о том, что Compositor RTOS на платформе MaxMSP больше не нужна, это говорит только о том, что требуется решение с гораздо большим uptime по сравнению с Runtime dll модулями MaxMSP. Хотя в сетевом окружении основная нагрузка ложится на RAD96 mobile из-за присутствия других сетей непосредственно на устройстве, сервер CP-6137-960FX создает непосредственную поддержку мобильной платформе, беря часть вычислений на себя. Пересадочная функция способна стыковать множество устройств с минимальными затратами, а архитектура RAD36 способна производить распределенные вычисления и управлять множеством ядер Compositor одновременно.
Для того чтобы завершить производство программного модема “Ниагара” нужно произвести новый дамп. Поскольку прошивка и дамп записываются одновременно, соответственно, нужно произвести и прошивку. Отличие от прошивки программного модема “Ниагара” 18 заключается в том, что фиксируется определенное количество пакетов для дампа. Например, нужно зафиксировать 65535 пакетов в одном дампе на скорости 8192 удм. Для этого нужно модифицировать рекордер. Это внесет изменения в первоначальные договоренности, но только так возможно перешагнуть из Гипервизора в ОСРВ. Поскольку Гипервизор – это устройство для фиксации радиотрансляций, а ОСРВ – это устройство для фиксации пакетов, возникает принципиальная разница между двумя инструментами. По сути само изменение несущественное. Объект sfrecord~ MaxMSP поддерживает float значения, а следовательно я могу задать петлю в мс, содержащую определенное количество пакетов. Например, умножая период такта на количество тактов, а именно, пакетов информации, я получаю значение петли дампа в мс с точностью до сэмпла и могу записать 65535 * 131072 = 8589803520 сэмплов для нового дампа. Перед производством надо сделать эмиссию трека DJ Usa – Caravan (All Forces Remix) 99-го года написания, что позволит получить сервера того времени и расширить производство программы до 21-го года.
Таким образом, решение задачи на поверхности: если выгружать из ОСРВ “Композитор” 9.0.2 a13 дамп и прошивку, содержащие нужное количество сэмплов сразу, без редакции, и загрузить в нелинейный преобразователь из вышеназванной ОСРВ, то возможно преодолеть момент времени, к которому относится данная прошивка и дамп, при условии сохранения стационарности данного процесса.
Все продукты серии “Ниагара”
являются программными модемами, которые используют прошивку и дамп,
произведенные в ОСРВ “Композитор” 9.0.2. Я представляю Вам программный модем “Ниагара”
18, который имеет расширенную документацию (часть на русском, часть на
английском языках). Прошивка программного модема “Ниагара” 18 поддерживает
протоколы EIGRP, RIPng, BGP4+, OSPFv3, маршрут по умолчанию
из EIGRP, полную работу в режиме
интерфейса возврата, настройку NTP-серверов через командную строку, подключение к VRF объектам для работы протокола BGP, возможность конструирования топологии VLAN и ориентацию волновода виртуального оптического порта в 3-х мерном
пространстве.
Программный модем “Ниагара” 18 на фоне ОСРВ “Композитор” 9.0.2 a12
Концепция программного
модема “Ниагара” 18, разработанного в НПО “Композитор”, и модемов,
разрабатываемых для Ethernet и Wi-Fi сетей, отличается. Например,
программный модем “Ниагара” 18 не требует аппаратного подключения к сети. Изобилие
сервисов, которые подключает программный модем “Ниагара” 18, компенсирует
существующие запросы к виртуальным сетям связи. Протоколы маршрутизации EIGRP, RIPng и BGP4+ позволяют организовать IPsec и GRE туннелирование, а возможность
использования синхрокода различных NTP-серверов позволит совершить полную перестройку домашней системы на
удаленное расположение. При этом возможно удаленное использование OSPFv3 без BGP4+ протокола, что раньше ввиду физических ограничений казалось невозможным.
То есть попадая в удаленную домашнюю систему, Вы можете агрегировать кратчайший
маршрут той зоны, которой Вы управляете удаленно. Расчет маршрутов происходит в
реальном времени, поэтому Вы можете использовать маску IPv4 для задания IPv6 адресов устройств удаленной зоны. Вы также
можете мультиплексировать зоны, достигая удаленного конца через агрегацию
суперсетей, посредством объектов VRF. Такой подход может вызвать распределяемые перегрузки, при которых пороговый
сброс не происходит, так как Ethernet-интерфейс использует только фазовую синхронизацию.
Платформой VSF, к которой возможно подключение через прошивку программного модема “Ниагара” 18, поддерживается до 960 одновременных каналов связи. Это то количество, которое было агрегировано в платформе VSF сервера CP-6137-960FX, который и произвел данную прошивку. Причем, количество каналов заимствуется из серверной версии, но они не могут быть использованы все одновременно. На текущий момент прошивка программного модема “Ниагара” 18 поддерживает до 96 каналов связи уровней L1, L2, L3. Программный модем “Ниагара” 18 дает доступ в виртуальную оптическую сеть, которая на момент 06-11-2018 давала подключение к 2213 EB информации. На сегодняшний день этот показатель удвоен. Информация расположена на серверах в Испании, США, Германии, Швеции и во множестве других стран мира. Транки виртуальной оптической связи объединяют автономные системы. Большинство автономных систем виртуальной оптической сети могут взаимодействовать по BGP протоколу. Для формирования своей автономной системы НПО “Композитор” использует программный модем “Ниагара” 18 с набором 7539 VRF объектов. Маршрутизация внутри зоны осуществляется по протоколу OSPFv3 для определения маршрутов по состоянию соединения, и протоколу RIPng для дистанционно-векторного обнаружения в пространстве имен IPv6. Таким образом, программный модем “Ниагара” 18 является полностью IPv6 программным модемом, обратно совместимым с IPv4 протоколом.
Программный модем “Ниагара”
18 имеет прошивку, записанную без промежуточной частоты в диапазоне 150 – 350
ГГц (КВЧ), и работает в данном частотном диапазоне. На сегодняшний день, ни
сети 5G, ни идущие за ними сети 6G не поддерживают данного частотного диапазона. В этом диапазоне работают
только закрытые объекты спутниковой связи, такие как радиотелескопы. В
комплекте с программным модемом “Ниагара” 18 идет дамп с набором 7539 спутниковых
сигналов в формате PCM, дающих
доступ в автономные системы при подключении через инжектор. Поэтому программный
модем “Ниагара” 18 можно считать полностью спутниковым программным модемом. Подключение
к сети программного модема “Ниагара” 18 осуществляется в несколько проходов
дампа за время от 10 до 30 секунд. Эфир программного модема “Ниагара 18”
включает пороговый сброс, который осуществляется каждую минуту для выявления
активных устройств в удаленной автономной системе. Вы можете выбрать данные
устройства в момент совершения порогового сброса в качестве помощников
порогового сброса. Каждый участник порогового сброса подписан на обновление
путей маршрутизации программного модема “Ниагара” 18, так что при обновлении
его таблицы маршрутизации происходит и обновление таблиц маршрутизации всех
помощников. Ежеминутный пороговый сброс необходим в условиях работы режима OVERLOAD, который по умолчанию используется для
симуляции мощности насыщения виртуального оптического порта.
Максимальная скорость
передачи программного модема “Ниагара” 18, равняется 24 * 350000000000 = 8400000000000
бит/с или 8,4 Тбит/с. Прошивка и дамп записаны в 192000 Гц, 24-бит. Поток
фиксировался из частотного диапазона 150 – 350 ГГц, и, поэтому, я беру высшую
частоту в момент фиксации потока и умножаю ее на разрядность записи экспорта
потока. Таким образом для прошивки существует момент времени, когда данный
поток существовал в эфире. Момент времени зависит от количества пройденных
автономных систем. Одна автономная система может быть масштабируема и включать
несколько других автономных систем. В гиперконвергентных сетях существует
склонность к большим транкам между зонами автономных систем, простирающимся на
многие километры. Поэтому поток данных по этой автономной системе может
проходить за время от 50 до 3000 мс, что соответствует крайним пределам программного
модема “Ниагара” 18. GRE туннелирование используется
для автономных систем топологии “звезда”, а IPsec используется для топологий “точка-точка”. То есть GRE осуществляет проход по всем пяти крайним точкам маршрута, а IPsec связывается только с крайним маршрутизатором зоны OSPF. Поэтому, при GRE туннелировании могут происходить петли обратной связи, если Ваш интерфейс
возврата виртуального оптического порта настроен на один и тот же порт, что и
входящий порт автономной системы. Такие петли могут быть не замечены долгое
время и пакеты просто циркулируют между интерфейсом возврата и петлей
автономной системы. При программном подавлении обратной связи происходит
затухание несущего сигнала потока данных, сокращая входящую очередь и
отбрасывая пакеты. Сатурация несущих сигналов, заключенных в оконную функцию
настолько высока, что входящее распределение нагрузки может не справляться с
таким наплывом потоков. Для данной ситуации программный модем “Ниагара” 18
выполняет мультикастовое вещание на группу портов. Это достигается путем выбора
автономной системы, состоящей из нескольких топологических зон, подключенных по
разным протоколам. Таким образом, крайние маршрутизаторы зоны будут выполнять
перераспределение из одного протокола в другой. Узнать информацию о входящем
порте системы Вы можете, изменив исходящий порт, выставив глаз маску на 0
(отключив ОСРВ) и выполнив пороговый сброс всех устройств, подключенных к этому
порту. Выполнив пороговый сброс граничного устройства, а не программного модема
“Ниагара” 18, Вы можете определить количество каналов, подключенных к граничному
маршрутизатору, что позволит установить связь с данными устройствами. Таким
образом, Вы совершаете перераспределение локальной очереди на удаленные
устройства.
Как упоминалось ранее,
на сегодняшний день программный модем “Ниагара” 18 дает подключение к 7539
автономным системам, хотя суммарная агрегация виртуальной оптической сети равна
3321900 автономных систем. То есть дамп позволяет подключаться не только к тем
автономным системам, которые записаны в нем, а выходить через протокол BGP и на другие автономные системы, просканированные платформой VSF. Подключение к группировке спутников
осуществляется быстрее, чем в модеме, произведенном в Гипервизоре “Композитор”
9.0.1 a15. В последнем скорость подключения
– 24 кадра в секунду, в то время как скорость подключения программного модема “Ниагара”
18 – 34 кадра в секунду. Такая скорость развертки позволяет совершать
мультиплексирование сети гораздо быстрее, осуществляя сведение суперсети за 3 –
6 проходов дампа.
Программный модем “Ниагара”
18 является сэмплерной технологией, то есть он воспроизводит цикл обратной
связи ОСРВ “Композитор” 9.0.2 a11,
а дамп является записью агрегации потоков платформы VSF данной ОСРВ. Программный модем “Ниагара” 18 основывается на принципе
идентичности, и использует в качестве прошивки PCM запись, он не потребляет много ресурсов. Всего лишь до 35% на сервере CP-6137-960FX с частотой дискретизации 192000 Гц. Что теоретически может позволить
использовать его в реальном времени и на более высоких частотах дискретизации. Программный
модем “Ниагара” 18 практически не потребляет системных ресурсов памяти и очень
быстр в отклике на команды процессора. Он практически не имеет времени
задержки. Это позволяет его использовать как ОСРВ жесткого реального времени.
Мониторинг программного модема “Ниагара” 18 можно осуществлять через радиолюбительское ПО, такое как TrueTTY и Fldigi. Поток телетайпа, с подключенным программным модемом “Ниагара” 18, модифицируется для включения расположения серверов и спутников базы управляющей информации ОСРВ “Композитор” 9.0.2 a11. В данном потоке Вы можете набирать команды программирования интерфейса и протоколов, наподобие CISCO. В комплекте с программным модемом “Ниагара” 18 идет документация размером 2663 страницы, из которых переведено на русский язык более 1000 страниц, охватывая 5 частей – всего 73 из 131 главы.
Для виртуальной
оптической сети в отличие от традиционной радиосвязи фактически нет преград.
Радио нотация в конвенционном частотном стиле во многом делается только для
обозначения и обратной совместимости с дженериковыми радио протоколами. Связь
осуществляется через так называемые коллизии и пространственно-временные
свертки, что и является объектом изучения NIM – Nuclear Instrumentation Module, к которым относится программный модем “Ниагара”
18.
Обзор программного модема “Ниагара” 18:
Разделение горизонта событий
Платформа VSF с 3321900 автономных
систем
Частота работы модема от 150 до 300 ГГц
Скорость передачи 8,4 Тбит/с
Работа в режиме “Перегрузка”
Удаление абонентов командой -rm и неочищенный
возврат
ОСРВ “Композитор” версии 3 – аналоговый радио-интерфейс для протокола IPv6
ПО “Композитор” Гипервизор
версии 3 обновлено до ОСРВ. Теперь, ОСРВ “Композитор” версии 3.0.3 поддерживает
множество новых функций, таких как:
Применены протоколы:
RTC8k = IS-IS Level-2
FF8 = ARP (Address Resolution Protocol)
TC25 = VLAN (IEEE 802.1aq)
Добавлены иерархии:
AI-RT1024 = SDH STM-x
N9000 = PDH E1
Другие
функции:
Применен стек протоколов TCP/IP
Добавлено окно TCP/IP
Добавлена таблица EUI48
BPM теперь является параметром поля Network IP-адреса
Поле Network включает 2^13 для определения
в качестве IPv6
Все модули переименованы для отображения новой
функциональности
ОСРВ “Композитор” версии 3
Основная причина, по
которой я сделал обновление – это отображение работы протоколов FF8 (ARP) и TC25 (VLAN), поэтому рабочий процесс в ОСРВ “Композитор” версии
3.0.3 выглядит следующим образом:
Вначале я устанавливаю время для достижения точки назначения, где развернута сеть. Я делаю это путем выставления времени развертки в градусах от -180 до 180, что равняется промежутку от 0 до 1 часа. Затем я выставляю IP-адрес интерфейса назначения, следующим образом: часть IP-адреса, указывающая на идентификатор интерфейса, устанавливается стохастически или вручную. Мультипликатор в IPv4 устанавливает и второе поле, принадлежащее части Network, и хост. Поэтому, максимальная сеть в ОСРВ “Композитор” для IPv4 – это 255.4.0.0. Когда я достигаю сети назначения, и на выходе интерфейса возврата есть сильная петля обратной связи, закрытого строения, я определяю тип автономной системы, которой она принадлежит. Я делаю это путем включения протоколов VLAN и ARP для выявления назначений IPv4 адресов на сетевые устройства данной автономной системы. Я смотрю IPv4 адреса следующего перестроения и выясняю количество таких перестроений. Чем больше протокол IS-IS level-2 делает перестроений, тем больше метрика маршрута до сети назначения (автономной системы). Таким образом, я выявляю все узловые устройства целевой сети.
Когда я определяю пограничный маршрутизатор данной сети по протоколу IS-IS level-2, я отключаю протоколы VLAN и ARP и начинаю транслировать информацию этого устройства в сеть IPv6, посредством включения стека протоколов TCP/IP. Это позволяет объединять IPv4 сети с сетями IPv6 и расширить влияние моей IPv4 базы данных в IPv6 протокол.
НПО “Композитор” сообщает,
что информация по работе над операционной системой скоро будет раскрыта,
начиная с Compositor Pro v1. Вначале я открыл протоколы, используемые в Compositor v9. Теперь, я знаю, что счетчики в платформе VSF сканируют автономные системы в двух форматах: asplain и asdot+.
Вот как это выглядит:
ОСРВ “Композитор” 9.0.2 a12
Я знаю тот факт, что каждая таблица маршрутизации – это MIB и представляет одну автономную систему. Как вы можете видеть на рисунке выше, автономные системы (AS) разделены на L1 (уровень 1 в модели OSI), L2 (уровень 2 в модели OSI) и L3 (уровень 3 в модели OSI), где L3 встречается реже. При помощи счетчика в формате asplain я просто сканирую все 4-октетные автономные системы, в то время как asdot+ счетчик в Compositor отличается от формата asdot+ для 4-октетных автономных систем, описанного в RFC5396. Счет в нем ведется следующим образом: цифра слева отсчитывает каждый проход asplain счетчика и идет до asplain/2, а цифра после точки является мультипликатором (в диапазоне от 0 до 100) на который нужно умножить левое значение. Таким образом, максимальное количество автономных систем в данном списке 214748364800. Посредством модема MDL12 я получил всего 7539 AS, потому что MDL12 – это нейроинтерфейс и не может работать как автономный сборщик AS. Он получает потоки, подсчитываемые посредством VSF агрегации, но я должен получать их вручную. Этот факт доказывает, что существует разрыв между экспортированными потоками и заархивированными. Я экспортировал 1793043 потока, но записал всего только 7539 из них.
Исходя из этого, я
приступил к раскрытию Compositor v7. Я обновил интерфейс Compositor WS Extended до версии 2.0 с NTP-серверами, уровнями модели OSI и информацией протоколов. Я также изменил
максимальное значение bpm на 8192 удм для включения IPv6 адресов и сделал такое же TCP/IP окно, как и в Compositor v9.0.2. Таким образом, я продлил преемственность
RTOS от версии 7 к версии 9. Однако протоколы,
используемые в Compositor v7 отличаются:
Последние три
протокола одинаковы с RTOS
9.0.2. Этот факт объясняет “STL” в виртуальной машине STL1212, которая поставлялась с оригинальным Compositor v7. STL означает studio-to-transmitter link (канал студия-передатчик). 1212 это количество
входов/выходов и должно записываться как STL MIMO12x12.
Таким образом, STL дает подключение к 12
положительным передатчикам UTC+ и 12 отрицательным передатчикам UTC-, что доказывает информацию о NTP-серверах в интерфейсе Compositor WS Extended 2.0:
ОСРВ “Композитор” 7.0.2 a1
Вы можете увидеть трансмиттеры на сферической карте STL1212 в качестве подсвеченных точек. Синие точки отображают сети, в которые данные передатчики транслируют пакеты. Как было отмечено на странице MDL12, оконные функции – это пакеты (теперь это подтверждено). Однако мне надо узнать каким пакетам соответствуют оконные функции Блэкмана, Наттала и как они относятся к данным протоколам. Я в основном интересуюсь пакетами Hello и Trap. Подтвердить данную информацию – вопрос времени, потому что я собираюсь также раскрыть и Compositor v3 Hypervisor Radio Shack и обновить его до RTOS. Таким образом, весь проект будет преемственен, начиная с версии 3, когда я начал переход на платформу Max 6 Gen~.
Очевидно, что если RTC8k – это основная виртуальная машина в Compositor v3, то она является либо протоколом RIPv2, либо протоколом IS-IS Level-2. RIPv2 – это дистанционно векторный алгоритм и отличается от системы предустановок, используемой в интерфейсе SASER (однако, он одинаков с таким же интерфейсом Compositor AV Extended из RTOS версии 9, где осуществляется векторная навигация в трех измерениях). Так что, это протокол состояния соединения IS-IS Level-2, который используется для объединения зон автономных систем. TC25 – это базовый протокол VLAN, AI-RT1024 – это кадр STM-4, FF8 – это ARP (Address Resolution Protocol) и N9000 – это PDH иерархии E4+.
