Mesh

Добрый день,

Меня зовут Алексей Бабушкин. Я СЕО независимого дизайн хауса электроники Hi-tech nation. Мы занимаемся контрактной разработкой продуктов в области интернета вещей. В свободное от работы время пилим свои решения с использованием беспроводной передачи данных и тестируем продуктовые гипотезы. Так родилась концепция независимой инфраструктуры для IIoT систем на основе mesh сети, которой я хочу с вами поделиться.

Начнём с теории

Промышленный Интернет вещей(IIoT) это система объединенных компьютерных сетей и подключенных к ним производственных объектов со встроеннымидатчикамиипрограммным обеспечениемдля сбора и обмена данными, с возможностью удаленного контроля и управления вавтоматизированномрежиме, без участия человека. При этом основной ценностью от внедрения IIoT является достижение максимальной результативности и экономичности производства за счет оптимизации его стоимости.

Типовая архитектура таких систем состоит из следующих 3-х уровней:

- оконечные периферийные устройства (датчики, контроллеры, исполнительные устройства и пр.). Этот уровень отвечает за сбор информации с устройств и за приведение её к стандартному виду, фильтрацию и локальное хранение;

- сетевые шлюзы (роутеры, gateway станции и пр.). Они создают инфраструктуру для управления и обмена данными между устройствами посредством проводных или беспроводных протоколов (RS-485, Modbus, CAN, BLE, Wi-Fi, ZigBee, LoRa, и пр.). На этом уровне происходит предварительная обработка информации, выстраивается коммуникация с верхнем уровнем и предоставляется возможность настройки и управления через веб-приложения;

- серверные решения (как правило в виде облачных платформ). Они обеспечивают удаленный доступ к системе и отвечают за более глубокий анализ собранных данных с использованием методов машинного обучения и за хранение больших объемов информации.

Теперь немного глубже

На старте формирования нашей концепции мы решили проанализировать все три уровня и выделить их слабые стороны.

На первом уровне главной головной болью является вопрос нахождения баланса между вычислительными возможностями оконечных устройств, их роли в работе всей системы и энергопотреблением. Современные сложные IIoT системы требуют большей автономности работы (в отрыве от сервера), быстрой реакции на команды (в части исполнительных устройств), дополнительной обработки информации, принятия решений на местах и простоты установки и настройки (желательно по принципу plug and play). При этом никто не отменял запрос на более низкую цену из-за большого количества подключенных устройств.

Слабые стороны второго уровня связаны, в первую очередь, с набирающим обороты переходом на беспроводную передачу данных. Радиоэфир становится все более перегруженным, поскольку большинство нелицензированных беспроводных технологий основаны на частоте 2,4 ГГц. Вскоре это станет одним из самых ограниченных ресурсов. Также стоит отметить неблагоприятную среду, в условиях реально работающих промышленных объектов, в которой приходится функционировать IIoT (большое количество металлоконструкций, высокочастотные помехи от работы производственного оборудования, Wi-Fi сети и пр.). Все эти факторы в совокупности могут привести к снижению качества работы IIoT системы или даже к полной остановке её работы. Чтобы избежать проблем со связью в будущем, современные беспроводные решения должны уметь сосуществовать с другими беспроводными технологиями, поддерживать динамическую смену каналов и работать на других частотах, например, 433 или 868 МГц.

Что касается непосредственно сетевых шлюзов, то сегодня многие производители устанавливают в свое оборудование, например, в те же роутеры или gateway-станции, как можно более высокопроизводительное "железо". Делается это не для улучшения качество сигнала, а чтобы предоставить пользователю, дополнительный функционал управления, со сложными графическими интерфейсами, выводом статистики и т.д. В первую очередь они делают это для того, чтобы оправдать завышенную стоимость новинок. Во вторую с целью улучшения пользовательского опыта при взаимодействии с продуктом. Понятно, что подобные действия продиктованы бизнесом. Возникает вопрос: зачем такое удорожание конечному пользователю. Такой подход противоречит основному принципу концепции промышленного интернета вещей, который гласит: стоимость решения не должна превышать ценность, которую пользователь получает в результате внедрения. Соответственно в интересах пользователей себестоимость отдельных компонентов должна не увеличиваться, а наоборот снижаться, как и стоимость обслуживания.

Слабые стороны третьего уровня связаны в первую очередь с недостатками облачных решений. К таким можно отнести вопросы безопасности. Согласно исследованию Crowd Research, проведенному в 2019 году, около 90% специалистов по кибербезопасности обеспокоены безопасностью используемых облачных сервисов. В некоторых отраслях (например, оборонно-промышленный комплекс) службы безопасности на основе внутренних нормативных актов ограничивают передачу данных за периметр предприятия, что исключает возможность использования облачных решений в принципе. Ещё одним недостатком облачных сервисов считают большую степень зависимости от поставщиков услуг (так называемый vendor lock-in), которые помимо предоставления сервисов и инфраструктуры, потенциально получают неконтролируемое влияние на рынок и клиентов. Так же сюда можно отнести высокую стоимость предоставления подобного рода услуг.

В ходе нашего исследования мы предположили, а что если, из архитектуры можно исключить элементы второго и третьего уровня, а весь их функционал оставить на стороне первого уровня оконечных периферийных устройств.

Так исторически сложилось

Все периферийные устройства мы, как правило, разрабатываем на основе микроконтроллера ESP32 разработанного компанией Espressif Systems. На наш взгляд, сегодня это один из лучших вариантов с точки зрения цена/качество/производительность на рынке. За вполне приемлемую цену мы получаем два ядра, аппаратные блоки шифрования, интегрированныеWi-FiиBluetooth модули, практически все периферийные интерфейсы и встроенный сопроцессор, на котором, посредством программирования на Assembler, можно весьма эффективно решать различные фоновые задачи в режиме ультранизкого потребления. Пришлось, конечно, практически полностью переписать китайский SDK, но сейчас не об этом.

Mesh

Беспроводную передачу данных мы решили строить на основе разработанной нашими инженерами mesh-cети. Q-mesh это сетевой протокол, построенный поверх протоколов IEEE 802.11n, IEEE 802.11lr и Bluetooth, позволяющий объединять многочисленные устройства, распределенные по большой площади как внутри, так и снаружи помещения в единую беспроводную локальную сеть. Сеть работает на частотах 2.4 ГГц и 868 МГц или 433 МГц. Частота 2.4 ГГц используется как основная, а частота 868 МГц или 433 МГц как дополнительная, для повышения надёжности, а также для маршрутизации между удаленными сегментами сети.

Наше решение отличается от аналогичных беспроводных решений тем, что не требует применения выделенной gateway станции. Любое из оконечных устройств, имеющих гарантированное питание, может полноценно взять на себя её функции. Выбор такого устройства происходит автоматически. Как правило, им становится то, у которого лучше условия обмена информацией. Например, самый низкий уровень помех, наибольшее число доступных устройств и т.д. Если устройство, выступающее в роли ведущего, по каким-либо причинам выходит из строя, то в течение нескольких секунд будет назначено другое. Замена происходит незаметно для пользователя.

Как мы храним данные

Все устройства оснащены достаточным объемом памяти, в которой постоянно накапливаются данные о работе устройства и, в некоторых случаях о состоянии внешней среды. Анализ этих данных позволяет не только эффективно использовать оборудование, но, также, в некоторой мере, прогнозировать поведение устройств и сети в целом, что обеспечивает постепенную автоматическую оптимизацию системы.

Дополнительная экономия сетевого трафика и памяти в наших устройствах достигается за счет того, что исключается повторное хранение и передача одинаковых данных. Например, при накоплении данных о температуре опрос датчика происходит периодически, но в массив данных его показания, вместе с меткой времени, попадают только в случае их отличия от предыдущих. Таким образом, если за сутки температура объекта не изменялась, то и в памяти хранится всего один отсчет.

В процессе работы такой системы может генерироваться значительный объем данных. Для их хранения, обработки и маршрутизации в системе предусмотрены сервера, построенные на микро сервисной архитектуре, которая позволяет распределять нагрузки. Это делает систему более устойчивой и надежной. Сервера обеспечивают передачу данных между удаленными ячейками mesh-сети, синхронизируют данные между собой и обновляют данные у пользователей в реальном времени. Устройства и пользователи подключаются к системе через веб-сокеты, что обеспечивает быстрый отклик устройств на команды и быстрое предоставление свежих данных пользователям.

Автономное питание

Все вычисления осуществляются внутри системы распределенным способом, в зависимости от источника питания. Что имеется в виду? Если одному из устройств с автономным питанием необходимо произвести сложные и энергозатратные вычисления, то система перенаправит эту задачу ближайшему устройству, имеющему постоянное сетевое питание. Такой подход обеспечивает приемлемый срок автономной работы для устройств с автономным питанием и ускоряет процесс принятия решения.

Элементы такой системы с автономным питанием рассчитаны на длительную работу без обслуживания. С целью экономии энергии эти устройства большую часть времени проводят в спящем режиме и, соответственно, не имеют постоянной доступности. Для эффективной работы с такими устройствами предусмотрена их виртуализация. Реализуется она следующим образом: на одном из ближайших, в смысле топологии и доступности, устройств, имеющем постоянное питание, создается виртуальная копия реального устройства и вся работа других устройств системы ведется уже с ним. Реальное же устройство по собственной инициативе общается со своим двойником и синхронизирует его состояние с реальным. Таким образом, например, пользователю нет необходимости ждать, когда проснется удаленный датчик, работающий по технологии NB-IoT, чтобы передать ему новые настройки. Он просто настраивает его цифрового двойника, и все настройки будут загружены по назначению во время очередного сеанса связи.

Передача данных

В отличие от традиционных сетей, например, Wi-Fi, Q-mesh поддерживает динамический выбор канала, основываясь на информации о загрузке каналов, интенсивности и спектре помех. Это способствует более устойчивой работе системы в условиях загруженного радиоэфира.

Нагрузка на различные участки системы может значительно меняться с течением времени. Это может вызывать заметные задержки в работе устройств. Для исключения, или, по крайней мере, для уменьшения вероятности таких перегрузок предлагается анализировать статистику по распределению трафика и реализовать предиктивную маршрутизацию. Таким образом, маршруты будут строиться с учетом ожидаемой нагрузки.

Скорость передачи данных в диапазоне 2.4 ГГц составляет от 0.25 до 112 Мбит/сек, а время задержки передачи от точки к точке от 5 до 50 миллисекунд. Скорость передачи данных в диапазоне 868 МГц составляет 1 Мбит/сек. Передача данных в диапазоне 433 МГц происходит на скорости 0.25 Мбит/сек.

Безопасность сети обеспечивается применением современных алгоритмов шифрования (AES с длиной ключа 192 или 256 бит) с использованием аппаратной поддержки. Трафик туннелируется между сервером и устройством или между парой устройств и шифруется отдельным ключом.Ключ генерируется из шума радиоэфира.

Управление и настройка

Вся система после включения настраивается автоматически, а в процессе работы перестраивается и подстраивается под внешнюю обстановку: расположение соседних устройств, уровень сигнала, загрузка радиоэфира. Процесс первоначальной настройки занимает от 3 до 60 секунд в зависимости от размера сети и заданной конфигурации. При выходе одного или нескольких устройств из строя перестроение системы происходит за время до 10 секунд.

Управление и настройка такой системы происходит через веб-интерфейс, который может раздавать любое из устройств системы выполняющего роль сетевого шлюза (gateway станции). Учитывая ограниченные вычислительные возможности периферийных устройств, поддержку веб-интерфейса они отдают в виде скрипта на сторону браузера смартфона, ПК или планшета, которые, располагают куда большей производительностью. Так как это происходит только в момент, когда пользователь взаимодействует с системой, то нагрузки на принимающую сторону не значительны. В свою очередь, для того, чтобы устройство проснулось и передало необходимые данные дальше, ему также не нужны большие вычислительные ресурсы. Поэтому мы можем использовать более дешевые и менее производительные микроконтроллеры, создавая для пользователя дополнительную ценность. В дополнение к этому, решения для браузеров легко интегрировать, так как они работают практически с любой ОС: Linux, Mac, Android и т.п. Таким образом, на том же ESP32 с 256 Кбайт оперативной памяти, мы можем запускать веб-приложения практически, любой сложности и с любой графикой, производить сложные вычисления на стороне веб-приложения с приемлемой скоростью отображения. Это возможно потому, что основная обработка происходит на стороне значительно более производительного оборудования и, поэтому, запас вычислительных ресурсов у нас практически безграничный.

Резюме

В сочетании с преимуществами децентрализации, разработанной нами mesh-сети, такой подход позволяет нам разворачивать локально закрытую и самодостаточную инфраструктуру для реализации концепции промышленного интернета вещей, используя только оконечные устройства. Такая инфраструктура может обходиться без участия внешнего сервера, предоставляя при этом все необходимые сервисы. Что в свою очередь позволяет выстроить независимую от инфраструктурных операторов систему, подконтрольную только конечному пользователю, сокращает издержки на обслуживание и повышает безопасность и сохранность данных.

Не смотря на то, что мы частично уже использовали подобный подход при реализации реальных проектов, к данной концепции мы все еще относимся как к гипотезе. Поэтому не стесняйтесь в комментариях, бросайте в нас камни, стучитесь в друзья и задавайте вопросы.

MeshLab является довольно популярной программой для манипуляции и визуализации трехмерных моделей, предоставляющий широкий набор инструментов. Он среди прочего предоставляет возможности по восстановлению и устранению проблем и ошибок в 3D моделях. О некоторых таких возможностях я бы хотел рассказать в статье. Кого заинтересовало, прошу под кат.

Довольно популярной проблемой при работе с 3D моделями является возникновение отверстий (holes, gaps). Такие проблемы возникают из-за несовершенной процедуры реконструкции сцены или недостаточной точности и качества 3D камер типа Microsoft Kinect.

Мы можем восстановить поврежденные поверхности моделей и закрыть дыры в программе Meshlab. Meshlab включает специальный фильтр для задачи закрытия отверстий в 3D моделях.

В начале откроем Meshlab и импортируем модель: File > Import Mesh.

Здесь показан пример модели с отверстием

Применим фильтр. Откроем в верхнем меню Filters > Remeshing, Simplification > Close Holes

Откроется диалог настройки параметров

Введем значение для параметра Max size to be closed и нажмем Apply. В моем случае хороший результат дало значение 210.

Результат применения фильтра

Выглядит неплохо, не правда ли?

Как мы видим не нужно писать специальный скрипт для закрытия отверстий. Все работает "из коробки".

Решение проблемы с дубликат вершины в модели

После применения фильтра Close Holes при экспорте модели в obj файл могут возникнуть вершины-дубликаты, т.е. вершины с одинаковыми координатами. Это может привести к некорректной обработке модели при использовании библиотек типа OpenMesh.

Давайте создадим obj файл со следующим содержимым:

v 0 0 0
v 1 0 0
v 0 1 0
v 1 1 0
f 0 1 2
f 1 2 3

Создадим скрипт test_duplicates.py с использованием библиотеки OpenMesh (туториалы по ней можно посмотреть здесь)

import openmesh as om import numpy as npmesh_3 = om.read_trimesh('duplicate_vert_test.obj')print('Test duplicate vertices')for i, vh in enumerate(mesh_3.vertices()):    print('Vertices adjacent to vertex ', i)    for vh_n in mesh_3.vv(vh):        print(vh_n.idx())

Запустим его

Vertices adjacent to vertex  021Vertices adjacent to vertex  102Vertices adjacent to vertex  210Vertices adjacent to vertex  3Vertices adjacent to vertex  4

Добавим дубликат вершины

v 0 0 0
v 1 0 0
v 0 1 0
v 1 1 0
v 1 0 0
f 0 1 2
f 4 2 3

Здесь мы добавили еще одну вершину с координатами 1 0 0.

Запустим скрипт еще раз

Vertices adjacent to vertex  0Vertices adjacent to vertex  132Vertices adjacent to vertex  213Vertices adjacent to vertex  321Vertices adjacent to vertex  4

Сейчас мы видим, что для вершины 0 нет соседних вершин, зато для вершины 3 появились две соседние вершины 2 и 1. Кажется, что вершина 4 перетянула к себе всех соседей вершины 0, с которой имеет одинаковые координаты.

Попробуем удалить дубликаты вершин на модели из примера выше. Импортируем модель

Здесь мы видим множество цветных граней.

Применим специальный фильтр для удаления дубликатов вершин

Filters -> Cleaning and Repairing -> Remove duplicate Vertices

Результат применения фильтра

Если мы применим фильтр на нашей первоначальной простой модели после экспорта модели мы получим obj файл следующего содержания

vn 0.000000 -nan(ind) 0.000000
v 0.000000 0.000000 0.000000
vn 0.000000 0.000000 -0.785398
v 1.000000 0.000000 0.000000
vn 0.000000 0.000000 -0.785398
v 0.000000 1.000000 0.000000
vn 0.000000 0.000000 -1.570796
v 1.000000 1.000000 0.000000
# 4 vertices, 0 vertices normals
f 4//4 2//2 3//3
# 1 faces, 0 coords texture

На этом все. Удачи в использовании MeshLab для манипуляции с 3D моделями и до новых встреч.

Новое решение от Microsoft создает настоящее ощущение присутствия, стирая границы, и открывает новые возможности для совместной работы и использования в бизнесе.

В рамках глобальной конференции Ignite 2021 былапредставленановая платформа смешанной реальности Miсrosoft Mesh. Алекс Кипман эксперт Microsoft в области технологий смешанной реальности и искусственного интеллекта, ведущий разработчик HoloLens презентовал ее во время иммерсивного выступления и рассказал про сценарии ее использования в совместной работе.

Microsoft Mesh позволяет создать у пользователей полное ощущение присутствия. Например, у людей создается впечатление, что они в одной комнате, даже когда они находятся на разных континентах. Пользователи могут взаимодействовать с 3D-контентом или друг с другом через приложения с поддержкой Mesh на любой платформе или устройстве. С помощью Mesh можно организовать так называемую холопортацию, передавая фотореалистичное изображение в смешанной реальности, а также создавать виртуальные аватары, с помощью которых можно выражать эмоции.

Базовым сценарием использования Mesh может быть совместное виртуальное присутствие в переговорной комнате, к примеру, в Teams. Но это только начало как и все продукты Microsoft, сама платформа станет основой для формирования экосистемы приложений, которые будут использовать данную технологию. Благодаря Microsoft Mesh туристические компании смогут передавать опыт виртуального путешествия, архитектурные бюро проектировать здания, создавая их виртуальную модель, а в производственном цехе удаленный эксперт сможет работать виртуально рядом со своим коллегой. Или же, как продемонстрировал в рамках конференции создавший голографическую лабораторию партнер MicrosoftOcean Xвместе с режиссером Джеймсом Кэмероном, платформа даст возможность ученым сотрудничать из любой точки мира, совместно делая новые открытия. Также свой сценарий использования Mesh продемонстрировала компанияNiantic(создатель Pokmon GO), представив демо Pokmon GO с использованием HoloLens 2.

Платформа Mesh будет доступна на различных устройствах, в том числе HoloLens 2, а также на большинстве гарнитур виртуальной реальности, планшетах, смартфонах и ПК. Предварительный просмотр приложения Microsoft Mesh для HoloLens 2 будет доступен с сегодняшнего дня, наряду с предварительной версиейAltspaceVR, в которую включена поддержка Mesh. В будущем Microsoft намерена интегрировать Mesh, созданную на основе облака Microsoft Azure, с Teams и Dynamics 365 и предлагает партнерам активно участвовать в развитии данной платформы, чтобы совместными усилиями создавать новые решения на базе технологий смешанной реальности для огромного количества сценариев использования.

Более подробная информация о Microsoft Mesh доступна вблоге.

Есть очень удобная и мощная библиотека, которая значительно упрощает работу с полигональными 3D моделями или мешами под названием OpenMesh. Она предоставляет широкий набор операций для работы с 3D моделями и имеет версию в Python. В этой статье я покажу как работать с 3D моделями используя обертку OpenMesh для Python. Кому интересно, прошу под кат.

Начало работы с OpenMesh

Изначально OpenMesh написан на C++, но имеет обертку на языке Python, которую можно использовать для быстрой и легкой разработки. Давайте посмотрим какие операции предоставляет эта обертка.

Для начала установим пакет с помощью pip:

pip install openmesh

Создадим новый Python скрипт и импортируем модуль openmesh

import openmesh as omimport numpy as np

Создадим объект, представляющий 3D меш

mesh = om.TriMesh()

Добавим несколько вершин

# add a a couple of vertices to the meshvh0 = mesh.add_vertex([0, 1, 0])vh1 = mesh.add_vertex([1, 0, 0])vh2 = mesh.add_vertex([2, 1, 0])vh3 = mesh.add_vertex([0,-1, 0])vh4 = mesh.add_vertex([2,-1, 0])

и несколько полигонов

fh0 = mesh.add_face(vh0, vh1, vh2)fh1 = mesh.add_face(vh1, vh3, vh4)fh2 = mesh.add_face(vh0, vh3, vh1)

В OpenMesh вершина представлена объектом VertexHandle. Объекты VertexHandle передаются во многие методы библиотеки OpenMesh в качестве параметра.

Есть также альтернативный способ через питоновский список вершин

vh_list = [vh2, vh1, vh4]fh3 = mesh.add_face(vh_list)

Стоит отметить, что OpenMesh также вводит специальный тип элемента в модели под названием Half-edge. Я не буду его рассматривать в данной статье. Подробнее о нем можно почитать здесь.

Манипуляция с отображением текстуры и координатами вершин

Я не буду раскрывать тему отображения текстуры (texture mapping) полигонов. Читатель может прочитать детальное объяснение этой темы здесь.

Получим координаты текстуры (UV texture coordinates) вершины:

tc = mesh.texcoord2D(vh)

tc представляет собой tuple. Значения координат u и v можно получить по индексу 0 и 1 соответственно.

Изменим координаты текстуры

uv_coords = [0.5, 0.2]mesh.set_texcoord2D(vh, uv_coords)

Здесь vh - объект типа VertexHandle.

Получим точку с координатами вершины

point = mesh.point(vh)

point представляет собой tuple. Координаты точки можно получить по индексу 0 и 1

x, y = tc[0], tc[1]

Можно получить все точки вершин модели

point_array = mesh.points()

и использовать их для сдвига модели вдоль оси (например X)

point_array += np.array([1, 0, 0])

Важные замечания по работе с OpenMesh

Не советую использовать enumerate() при итерировании вершин в цикле. Вы можете получить неожиданное поведение, например одинаковые координаты текстуры UV для разных вершин.

При сохранение меша в файл OpenMesh по умолчанию не сохраняет координаты текстур для вершин (vt строки) в файле obj. Чтобы решить эту проблему нужно передать параметр vertex_tex_coord в метод write_mesh (источник):

om.write_mesh(test_out.obj, mesh, vertex_tex_coord=True)

Также OpenMesh не сохраняет файл материалов mtl в файле obj. Для сохранения информации о материале используйте параметр face_color при чтении файла obj

mesh = openmesh.read_trimesh('test.obj', vertex_tex_coord=True, face_color=True)

и записи в файл

openmesh.write_mesh('test_out.obj', mesh, vertex_tex_coord=True, face_color=True)

То же касается и нормалей. Чтение модели obj с нормалями

mesh = openmesh.read_trimesh('test.obj', vertex_normal=True)

и записи в файл

openmesh.write_mesh('test_out.obj', mesh, vertex_normal=True)

Здесь важно использовать одинаковые параметры и при чтении и при записи. Например, если мы хотим получить и сохранить информации о материале нужно использовать параметр face_color в обоих методах read_trimesh и write_mesh.

При работе с OpenMesh я сделал интересное наблюдение: порядок индексов координат текстур вершин (индексы строк vt) меняется. Например для такой строки в исходном файле obj

f 1/1 2/2 3/3

Соответствующая строка в выходном файле obj может выглядеть примерно так

f 1/3 2/1 3/2

Итерации и циклы

Итерации над вершинами в меше

for vh in mesh.vertices():    print(vh.idx())

Цикл for возвращает объекты vh типа VertexHandle. idx() возвращает индекс вершины.

Итерации над полигонами и гранями

# iterate over all edgesfor eh in mesh.edges():    print eh.idx()# iterate over all facesfor fh in mesh.faces():    print fh.idx()

Аналогично итератору над вершинами цикл for возвращает объекты fh типа FaceHandle.

Итерация над всеми half-edge в меше

for heh in mesh.halfedges():    print heh.idx()

Над вершинами соседними с заданной

for vh_n in mesh.vv(vh):    print(vh_n.idx())

Над гранями выходящими из заданной вершины

for eh in mesh.ve(vh1):    print eh.idx()

Над полигонами, смежными с заданной вершиной

for fh in mesh.vf(vh1):    print fh.idx()

Все то же самое можно проделать и с полигоном

# iterate over the face's verticesfor vh in mesh.fv(fh0):    print vh.idx()   # iterate over the face's halfedgesfor heh in mesh.fh(fh0):    print heh.idx()# iterate over the face's edgesfor eh in mesh.fe(fh0):    print eh.idx()    # iterate over all edge-neighboring facesfor fh in mesh.ff(fh0):    print fh.idx()

Это все. Не так сложно, не правда ли. Удачи вам в работе с 3D мешами с использованием OpenMesh и до новых встреч.

I2P (Invisible Internet Protocol) свободный инструмент организации анонимных коммуникаций через интернет. Является одноранговой сетью, в которой каждый пользователь по умолчанию является потенциальным звеном в анонимной цепочке других участников сети. Трафик I2P зашифрован и не поддается анализу. Понятие сторожевого узла в I2P, которое присутствует в сети Tor, нет: не существует никакого постоянного узла, через который осуществляется выход в сеть. Взаимодействие пользователя с I2P на стороне домашнего провайдера идентифицируется, как хаотичное подключение к случайным хостам. Количество подключений клиента с белым IP в среднем варьируется у отметки в четыре тысячи. Помимо полезной нагрузки, сюда входят обмен служебной информацией с другими роутерами сети и транзитный трафик.

Предпосылки

Существенное слабое место сети I2P заключается в необходимости обращения к одному из стартовых узлов через обычный интернет при первом запуске. Пакет с начальным рисунком сети в виде нескольких случайных роутеров и узел, который его отдает, называются ресидом. Стартовые узлы держат энтузиасты, их список имеется в общем доступе и нередко претерпевает изменения в силу обычных человеческих обстоятельств. Бутылочное горлышко заключается в возможности на стороне провайдера идентифицировать большинство обращений к ресиду через мониторинг DNS-запросов, а также в блокировке доменов стартовых узлов, что затруднит первый запуск для неопытного пользователя, т.к. потребует использование прокси или VPN.

В отличие от обычного интернета, пользователи I2P без выделенного адреса имеют худшее качество использования скрытой сети, чем абоненты с белым IP. Это связано с постоянной необходимостью прямого сообщения с другими роутерами сети. Каждый роутер публикует свой адрес, который включает в себя ключи шифрования, IP-адрес и порт для приема сообщений. Очевидно, что достучаться до узла сети за NAT-сервером задача не из простых.

Однако работа роутеров без выделенного адреса возможна: клиенту сети за NAT-ом приходится постоянно поддерживать активное UDP-соединение, резервируя на выходном сервере провайдера порт, обращения на который будут переданы клиенту. Этот сценарий весьма сложен, особенно, когда речь заходит про инициализацию соединения извне. Механика работы клиента за NAT-ом произведение инженерной мысли, которое заслуживает отдельной статьи.

Кратко об Yggdrasil

Yggdrasil один из немногих работоспособных протоколов меш-сетей. Основная концепция заключатся в автоматической маршрутизации во внутренней IPv6 подсети (200::/7) и абсолютной масштабируемости. Yggdrasil является полностью одноранговой сетью: не существует каких-либо мастер-узлов, которым делегируется какая-то глобальная ответственность. Является идеологическим продолжателем проекта CJDNS (Hyperborea).

Абстрактная идея меш-сети во главу угла ставит производительность, приватность и простоту использования: шифрование трафика и низкий порог вхождения новых пользователей. Yggdrasil не является инструментом анонимности, т.к. ближайшие к пользователю узлы видят его реальные сетевые интерфейсы в локальной сети, либо IP-адрес при подключении к публичному пиру через интернет. Меш-сети находят применение в организации псевдолокальных сетей, объединяя удаленные компьютеры в одну IPv6-сеть (по аналогии с Hamachi для игры в Minecraft и прочие мультиплеерные игры). Также служит для организации прочих внутрисетевых ресурсов вроде сайтов и VoIP-телефонии.

Первые попытки интеграции

I2P-роутер публикует свои адреса, в том числе IPv6, если он включен в конфиге и имеется фактически. Так как Yggdrasil предоставляет пользователю не локальный прокси, а полноценный сетевой интерфейс (туннель WireGuard), до недавних пор I2P-роутер публиковал адрес IPv6 из подсети Yggdrasil. Так как пользователей с включенным протоколом IPv6 в конфигурации I2P-роутера и установленным Yggdrasil было больше, чем один и даже два, периодически можно было видеть, что клиент I2P (роутер) сообщается с другими Yggdrasil-адресами.

Однако на лицо следующие недостатки:

1. обращение к ресиду в конечном счете должно осуществляться через обычный интернет;

2. опубликованный роутером адрес IPv6-Yggdrasil для подавляющего большинства пользователей I2P является неизвестным и недоступным;

3. успешный запуск I2P-роутера на Yggdrasil-Only устройстве маловероятен в силу возможного отсутствия в ресиде или локальной базе роутера узлов с адресом IPv6-Yggdrasil.

Начало полной совместимости

С версии 2.36.0 i2pd имеет несколько новых конфигурационных параметров, главный из которых meshnets.yggdrasil=true Этот параметр не зависит от конфигурации IPv4 и IPv6. В частности, реальные сетевые интерфейсы могут быть отключены. В таком случае I2P-роутер будет работать в режиме Yggdrasil-Only.

Также организован специальный ресид, доступный из Yggdrasil и отдающий пользователю пакет в первую очередь состоящий из известных роутеров с адресом IPv6-Yggdrasil. При каждом запуске I2P-роутера, работающего в режиме Yggdrasil-Only, проводится проверка наличия в локальной базе доступных узлов на транспортном уровне, т.е. наличие других узлов с IPv6-Yggdrasil. Если по каким-то причинам совместимых роутеров в локальной базе не оказалось, происходит повторное обращение к Yggdrasil-ресиду.

При современном использовании Yggdrasil по большей части через оверлейные подключения к публичным пирам через интернет, работа I2P-роутера в Yggdrasil сравнима со связкой Tor-over-VPN: подобный подход полностью скрывает факт использования скрытой сети от домашнего провайдера. В случае с I2P имеется еще одно специфичное преимущество: пользователю не нужно иметь выделенный IP от провайдера для беспроблемных внешних обращений, т.к. IPv6-Yggdrasil является глобально доступным в рамках сегмента сети Yggdrasil (физически соединенной группы участников, в том числе через публичные пиры в интернете).

Целостность сети

Описанное решение не является фактором фрагментации I2P. Построение туннелей скрытой сети весьма емкий и даже ювелирный процесс, в рамках которого в том числе происходит согласование транспортных возможностей узлов. Формируя чеснок - зашифрованное сообщение группе узлов, которые должны образовать туннель, - роутер проверяет их адреса на совместимость. Например, узел с единственным адресом IPv4 не получит инструкцию, согласно которой ему необходимо установить контакт с адресом IPv6, т.к. это заведомо невозможно.

Чтобы Yggdrasil-Only роутеру построить туннель до узла с адресом из обычного интернета, как минимум будет подобран транзитный роутер, имеющий два интерфейса: IPv6-Yggdrasil и, например, обычный IPv4. В свою очередь, другие Yggdrasil-Only роутеры также могут выступать транзитными звеньями туннеля, но только для сообщения с узлами совместимыми по транспорту, т.е. также имеющими сетевой интерфейс Yggdrasil. Чем больше в сети I2P количество роутеров с одновременно включенными IPv4, IPv6 и Yggdrasil интерфейсами, тем связнее сеть.

Перспектива

Пример с Yggdrasil является частным шагом в будущее, а не самоцелью. Описанный опыт успешной интеграции скрытой сети в меш-сеть является важным концептуальным шагом, который при надобности позволит интегрировать сеть I2P в другие меш-сети. Перспектива открывается при рассмотрении самоорганизованных сегментов меш-сети, например, в многоквартирных домах без централизованного провайдера. В локальной сети клиент Yggdrasil автоматически находит другие узлы и сообщается с ними, сам выступая при надобности транзитным. При подключении хотя бы одного узла в таком сегменте к другому сегменту сети (например, к глобальному через интернет), сети автоматически объединяются. Такой подход к организации сети стал еще реальнее, т.к. теперь имеет место быть и вторая сторона привычного интернета скрытая.

Для более детального ознакомления с I2P и Yggdrasil рекомендую видео: