Рубрика «Сетевые технологии» - 139

С системой RDS (Radio Data System) сталкивался хоть раз каждый, кто видел в автомагнитоле название станции вроде «Дорожное радио». Помимо названия, могут отображаться дополнительные данные — название воспроизводимой песни, температура, частота вещания и т.д.
RDS, как это работает? Опускаемся на самый нижний уровень модели OSI - 1

Но как это работает? Т.к. моим хобби является радио и цифровая обработка сигналов, разобраться было интересно. Как оказалось, полной информации о RDS в рунете практически нет (да и в англоязычном тоже негусто), надеюсь, эта публикация восполнит этот пробел.

Продолжение под катом (осторожно много картинок).
Читать полностью »

Статья, которую вы сейчас читаете, является расширением статьи "Настройка свитчей уровня доступа в сети провайдера". Я обосную правильность подхода автора скринами и своими наблюдениями. Итак, фото испытуемого.

image

Все как в фильме ДМБ, сюжет про суслика: я тоже не вижу кабелей, а линки есть. Настройки у коммутатора сброшены к заводским командой #reset system.
Читать полностью »

Недавно обзавёлся задачей по балансировке трафика между несколькими usb-модемами. В итоге родилось решение коим и хочу поделиться с читателим.

На момент написания статьи это balancing_v0.5.2-alpha.

Изначально задача формулировалась примерно так:

Есть пучёк armhf девайсов c Ubuntu Trusty на борту.
У них есть несколько подключений к интернету. Обычно это основное проводное подключение (eth0) и несколько HiLink usb-модемов Huawei E303 (eth1-eth5). Через каждое из этих подключений нужно поднять openvpn-клиентов к единственному серверу и через них уже балансировать трафик.

Всё бы ничего, но у этих модемов нет возможности изменения подсети и шлюза (гвоздями прибиты 192.168.1.1/24), причём прошивок с реализацией этой возможности тоже не нашлось (в отличии, например от E3272 для которого есть прошивки с таким функционалом). Кроме того даже если бы и нашлись, то vpn-подключения всё равно были бы в одной подсети и с одинаковым шлюзом. Т.е. без продвинутой маршрутизации (policy routing) не обойтись.

Ах, да, ещё надо мониторить каждое подключение и отключать/включать, если порвалось/возобновилось. Т.е. маршрутизацией нужно управлять динамически.
Читать полностью »

Data Plane Development Kit (DPDK): приступая к работе - 1Для быстрой обработки пакетов требуется обнаруживать битовые шаблоны и быстро (со скоростью работы канала) принимать решения о нужных действиях на основе наличных битовых шаблонов. Эти битовые шаблоны могут принадлежать одному из нескольких заголовков, присутствующих в пакете, которые, в свою очередь, могут находиться на одном из нескольких уровней, например Ethernet, VLAN, IP, MPLS или TCP/UDP. Действия, определяемые по битовым шаблонам, могут различаться — от простого перенаправления пакетов в другой порт до сложных операций перезаписи, для которых требуется сопоставление заголовка пакета из одного набора протоколов с другими. К этому следует добавить функции управления трафика и политик трафика, брандмауэры, виртуальные частные сети и т. п., вследствие чего сложность операций, которые необходимо выполнять с каждым пакетом, многократно возрастает.

Чтобы добиться работы на ожидаемом уровне производительности при скорости канала 10 Гбит/с и размере пакета в 84 байта, процессор должен обрабатывать 14,88 миллиона пакетов в секунду. Оборудование общего назначения было недостаточно мощным для обработки пакетов с такой скоростью. Поэтому в большинстве рабочих сетевых систем обработкой пакетов в каналах данных занимаются контроллеры ASIC и сетевые процессоры NPU. К очевидным недостаткам такого подхода относятся: недостаточная гибкость, высокая стоимость, длительные циклы разработки, зависимость от определенного поставщика. Тем не менее, благодаря доступности более быстрых и дешевых ЦП и программных ускорителей, таких как Data Plane Development Kit (DPDK), можно переложить эту нагрузку на оборудование общего назначения.
Читать полностью »

Eсли вкратце, то технология позволяет виртуальным машинам получать прямой доступ до физических устройств pci на сервере с гипервизором. Однако, при использовании этой технологии перестают работать почти все полезные вещи, которые позволяет кластер vSphere: fault tolerance, high availability, снапшоты, vMotion и DRS с ним же.

Более того, когда виртуальная машина использует устройство напрямую, минуя гипервизор, то это устройство перестаёт быть доступно самому гипервизору. Например, если прокидывать сетевушку внутрь виртуалки через DirectPath I/O, то, да, ресурсы гипервизора на обработку трафика от виртуальной машины больше не используются — это хорошо. Плохо то, что прокинутую сетевушку сможет использовать только одна виртуалка. Технология, получается, весьма спорная, если не сказать больше — бесполезная. Но не всё так однозначно. Читать полностью »

Мультиплеер в быстрых играх (Часть IV: Хэдшот! Путешествуем во времени) - 1

  1. Части I, II (синглплеер с авторитарным сервером)
  2. Часть III (Появление врага)
  3. Часть IV (Хэдшот!)

Как повесить идеальный хэдшот если у тебя пинг 2 секунды? Вы узнаете в этой статье.

Текущий алгоритм работы мультиплеера

  • Сервер получает команды с клиентов и времена их отправления
  • Сервер обновляет состояние мира
  • Сервер с некоторой частотой отправляет свое состояние всем клиентам
  • Клиент отправляет команды и локально воспроизводит их результат
  • Клиент получает обновленные состояния мира и:
    • Применяет состояние от сервера
    • Заново применяет все свои команды, которые сервер не успел применить.
    • Интерполирует предыдущие состояния других игроков
  • С точки зрения игрока, есть два серьезных последствия:
    • Игрок видит себя в настоящем
    • Игрок видит других в прошлом.

Обычно это отлично работает, но это становится большой проблемой для событий, которым нужна высокая пространственно-временная точность. Например если хочется разнести врагу бошку!
Читать полностью »

Предисловие

Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.

Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.
Читать полностью »

Мультиплеер в быстрых играх (Часть III: появление врага) - 1

  1. Части I, II (синглплеер с авторитарным сервером)
  2. Часть III (Появление врага)
  3. Часть IV (Хэдшот!)

Введение

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

В этой статье мы рассмотрим последствия одновременного подключения нескольких игроков к одному серверу.Читать полностью »

Front-door VRF. Ещё один практический пример - 1

Привет habr! Про настройку VPN совместно с VRF на оборудовании Cisco существует много статей в Интернете. Здесь есть неплохая шпаргалка по настройке IPsec VPN в виде крипто-карт и VTI-туннелей совместно с VRF. В этой статье хабра приведён пример DMVPN с VRF. VRF даёт большую гибкость при настройке оборудования и вариантов её использования большое количество. Главное не забывать, что у нас есть такой инструмент. В моей заметке я решил рассмотреть ещё одну интересную задачу из нашей практики, для решения которой также пригодилось использование Front-door VRF для построения IPsec туннелей. Речь пойдёт про построение параллельных VPN-туннелей через разных Интернет-провайдеров и распределение трафика по этим туннелям.Читать полностью »

Это история одного проекта по видеостримингу.

image

Интересный клиент

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

Через пару минут я увидел Ольгу, сопровождающую джентельмена азиатской наружности. На вид ему было около пятидесяти. На слегка морщинистой голове восседала серая шляпа с короткими полями. Они явно шли ко мне. Поравнявшись с кофейным автоматом, который уже журчал в стаканчик моим капучино, джентельмен произнес на ломаном русском: Здраствуйте, я относительный проекта WebRTC. Моя зовут Суконако, и протянул руку. Что привело сюда этого японца, подумал я, ответив на рукопожатие, и пригласил гостя в свой кабинет. Дальше нам пришлось перейти на английский язык, который нам обоим был более понятен.

Собираем требования

Я: Итак, чем могу быть полезен?

С: Мы работаем с 2000 года в стриминге и Flex для большого количества пользователей. Мы используем Adobe Flash Media Server (FMS) и сейчас хотели бы использовать WebRTC.

Я: Можно подробнее о том, чего вы хотели бы достичь использованием WebRTC-сервера?

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

Я: Без проблем, мы можем сделать решение на базе одного из WebRTC-серверов.

С: Adobe FMS нас полностью устраивает. Мы хотели бы расширить круг наших пользователей на WebRTC, не убирая FMS. Он работает хорошо.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js