Рубрика «networking» - 5

От переводчика: У меня возникла необходимость разобраться с работой UDP-сокетов в неблокирующем режиме в java и создать свой собственный класс для работы с сетевыми соединениями на их основе. К сожалению, толковой русскоязычной документации на эту тему я не нашёл. Зато наткнулся на несколько попыток на хабре осветить тему создания надёжного соединения поверх UDP. В том числе и перевод нескольких статей Гленна Фидлера, сделанный пользователем bvasilyev. И хотя статьи рассматривают создание подобного подключения для применения его в играх (не совсем то, что мне необходимо), а также языком реализации является не java, а c++, они стали для меня отправной точкой. К сожалению bvasilyev около года назад прервал перевод данного цикла, а самое интересное осталось на языке оригинала. Поэтому я решил перевести четвёртую статью цикла и переписать реализацию виртуального соединения из третей статьи цикла на java (чуть позже выложу). Ну а для того, чтоб данной статьёй мог воспользоваться кто-либо, кроме меня, выкладываю её здесь. Профессиональным переводом, к сожалению, никогда не занимался, всегда изучал англоязычную документацию. Но в данном случае, из-за многочисленного употребления некоторых слов в совершенно различных значениях, а также в роли наименования всевозможных определений, неоднократно — в пределах одного предложения, счёл более целесообразным осуществить перевод, а после уже работать с текстом на привычном для себя языке. Поправки и аргументированные предложения приветствуются.

Первая статья
Вторая статья
Третья статья

(напомню: переведены bvasilyev)


Надежность, упорядочивание и избежание перегрузок поверх UDP

Вступление

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей четвёртой статье из цикла “Сетевое программирование для разработчиков игр”.

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

Теперь мы будем добавлять надёжность, упорядоченность и предотвращение перегрузок к нашему виртуальному UDP соединению.

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

Проблемы с TCP

Те из вас, кто знаком с TCP, знают, что он уже имеет свою внутреннюю концепцию соединений, с надёжной и упорядоченной системой передачи пакетов и предотвращением перегрузок, так зачем же мы пишем свою собственную мини версию TCP на основе UDP?
Читать полностью »

image

В этой статье Лаура Шварц, бывший инсайдер Белого дома, расскажет о том, как найти, о чем поболтать, с лучшими людьми на вечеринке.Читать полностью »

От переводчика: Это перевод второй статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/


Прием и передача пакетов данных

Введение

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.

Сетевое программирование для разработчиков игр. Часть 2: прием и передача пакетов данных

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

А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.

BSD сокеты

В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).

Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.

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

Мы представляем первое из серии интервью с техническими руководителями проектаOpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis. Интервью публикуется с купюрами в связи с ограничением длины статьи.

Наше первое интервью мы взяли у Марка Макклейна, только что избранного технического руководителя проекта OpenStack Networking (ранее известного как “Quantum”).Читать полностью »

Автор: Piotr Siwczak

За последнее время сети в OpenStack прошли эволюцию от простой, едва ли пригодной к использованию модели к более совершенной с возможностью полной изоляции владельцев. Поддержка различных требований пользователей в OpenStack реализована с помощью т.н. “сетевых менеджеров”. Сетевой менеджер определяет сетевую топологию конкретного деплоймента OpenStack. Начиная с версии Essex, пользователь может выбрать один из трех вариантов сетевых менеджеров: FlatManager, FlatDHCPManager, VlanManager. В этой части статьи мы рассмотрим первые два, для последнего будет отведена вторая часть.

У менеджеров FlatManager и FlatDHCPManager есть много общего. Оба они основываются на концепции сетевых мостов (bridged networking) с использованием одного моста. В качестве примера рассмотрим сеть, состоящую из нескольких узлов.Читать полностью »

При построении сетей есть две конкурирующие топологии: это звезда (разных вариантов) и кольцо (разных вариантов). У звезды одно преимущество – низкая переподписка. Недостатки звезды — сложная структура, а соответственно сложность эксплуатации и высокая стоимость. Звезда — это решение для собранных в одно место пользователей на доступе: классическая сеть здания управления в предприятии, но не всегда и даже в этом случае. Ведь опорная сеть здания с соблюдением норм пожарной безопасности всегда будет прокладываться через два кабельных стояка в разных частях здания и это снова – кольцо, а не звезда: одно кольцо/жгут оптики через эти два стояка и два центра ядра сети здания/ЦОД.

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

Кольцо и звезда: кто кого?

Рис. 1. Модуль АСУТП завода.

Читать полностью »

Редко, но метко в моей практике возникает задача, когда нужно быстро поднять сервер с «белым ip» для демонстрации результатов работы или просто для целей тестирования нового функционала перед выкатыванием его в продакшен. Каждый раз арендовать VDS для этого накладно, а связываться с облаками для подобных целей мне не хочется.

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

Доброго времени суток. Решил поделиться с вами своим пониманием этого вопроса, и механизма его решения, используемого в устройствах WAN оптимизации Silver Peak.

Итак, практическое большинство современных сетей, использует в своей основе пакетную передачу и протокол IP. Информация передается через сеть кусочками информации, и обычно размер этих кусочков варьируется от 1 байта до 1500 байт (Я имею ввиду полезную нагрузку). По пути через WAN сеть, такие пакеты могут пройти через великое множество маршрутизаторов и шлюзов. Некоторые из этих перевалочных пунктов вы можете увидеть при помощи утилиты Traceroute. Но это далеко не все реальные транзитные узлы, например вы не увидите здесь те узлы, через которые трафик прошел туннелированным (MPLS VPN, GRE и т.д.). При этом, с ненулевой долей вероятности, какой-нибудь из транзитных узлов будет в данный момент сильно загружен, и уничтожит ваш пакет, чтобы не допускать перегрузки сети. И чем больше таких транзитных узлов, тем больше вероятность потери пакета в сети.
Читать полностью »

image
Ниже — перевод статьи о проблеме работы с udp в сетевых приложениях. Переводчик позволил себе сменить примеры: в исходном тексте другие сетевые адреса и код на ruby. В переводе использован простенький скрипт на перле. Суть проблемы и решение от этого не меняются.
Кроме того, местами добавлены мои комментарии (в скобках, выделены курсивом).
КДПВ взята из текста замечательной книги «learnyousomeerlang.com»

Тяжкая работа лёгких протоколов

Читать полностью »

Пролог

Недавно я столкнулся с необходимостью эффективной работы с сокетами в Windows приложении. Задача типичная для нагруженного сервера. Нетипичным тут будет казаться только язык реализации — Delphi.
Я хочу описать способ массовой асинхронной работы с большим количеством сокетов с использованием I/O Completion Ports. Читать полностью »


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