Колбасный принцип

Тем, кто любит колбасу и уважает закон, не стоит видеть, как делается то и другое.

Диалог пользователя и Windows: ...

Начальный план разработки Qt 6
Thu, 21 Jun 2018 22:26:33 +0300

Разработчики Netfilter официально объявили инструментарий iptables устаревшим
Thu, 21 Jun 2018 14:18:47 +0300

Blender тестирует децентрализованный PeerTube после блокировки видео на YouTube
Wed, 20 Jun 2018 20:35:28 +0300

Представлен проект Fedora CoreOS
Wed, 20 Jun 2018 19:05:49 +0300

В OpenBSD добавлен код программного отключения SMT (HyperThreading)
Wed, 20 Jun 2018 12:11:25 +0300

В рамках проекта Devilution предпринята попытка воссоздания кода игры Diablo
Tue, 19 Jun 2018 13:06:26 +0300

Проекту FreeBSD исполнилось 25 лет
Tue, 19 Jun 2018 12:18:37 +0300

Открыт код C++ компилятора Zapcc
Mon, 18 Jun 2018 11:26:24 +0300

Установочный скрипт проекта yandex-disk-indicator удалял раздел /usr
Sun, 17 Jun 2018 20:11:45 +0300

Mozilla рассматривает возможность создания системы голосовой навигации для браузера
Sun, 17 Jun 2018 13:27:14 +0300

Разбор ситуации с обвинением OpenBSD в нарушении эмбарго при исправлении уязвимости KRACK
Sat, 16 Jun 2018 08:46:44 +0300

Подготовленный в Microsoft deb-пакет с Open R принудительно заменяет /bin/sh на bash
Thu, 14 Jun 2018 20:15:07 +0300

В Chrome будет прекращена поддержка установки дополнений по запросу сторонних сайтов
Thu, 14 Jun 2018 12:04:29 +0300

Раскол среди создателей проекта CopperheadOS
Wed, 13 Jun 2018 10:34:17 +0300

Началась разработка GitPub, протокола для децентрализованных Git-сервисов
Tue, 12 Jun 2018 10:04:53 +0300

Протоколы Расширения Сети Безопасность Почта
RFC 768RFC 791RFC 792RFC 793RFC 903RFC 1157RFC 4302

В этом документе описывается метод, позволяющий станциям динамически определять свой адрес протокольного уровня (например, IP) по известному аппаратному адресу.

Документ содержит спецификацию стандарта, предложенного сообществу ARPA Internet и является приглашением к дискуссии в целях развития стандарта.

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

Разработанный Пламмером (Plummer) протокол ARP [1] предназначен для решения обратной задачи — определения аппаратного адреса хоста по его протокольному адресу. В данном документе описывается протокол обратного преобразования адресов RARP. Как м в случае ARP, предполагается широковещательная сетевая среда, подобная Ethernet.

Ниже приведены рекомендации по реализации протокола RARP.

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

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

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

  • Желательно использование фрагментов кода существующих программ в целях минимизации усилий по разработке и нижения расходов.

Предлагается выполнять преобразование RARP с помощью отдельного протокола канального уровня. Например, для сред Ethernet пакеты RARP будут иметь значение поля Ethertype (которое будет выделено для этого протокола), отличающееся от ARP. Это будет указывать, что преобразования ARP и RARP различаются фундаментально и поддерживаются хостами по-разному. Воздействие на существующие системы минимально — существующие серверы ARP не будут вводиться в заблуждение пакетами RARP. Этот делает RARP самостоятельным протоколом, который может применяться для отображения аппаратных адресов на адреса любых протоколов вышележащего уровня.

Это приближение обеспечивает простоту реализации клиентской части RARP, но разработка RARP-серверов потребует более значительный усилий. Однако, эти трудности не являются непреодолимыми, как показано в Приложении A, где даны наброски двух вариантов реализации протокола для 4.2BSD Unix.

RARP использует такой же формат пакетов, как протокол ARP, а именно:

ar$hrd  (пространство аппаратных адресов) - 16 битов
ar$pro  (пространство протокольных адресов) - 16 битов
ar$hln  (размер аппаратного адреса) - 8 битов
ar$pln  (размер протокольного адреса) - 8 битов
ar$op   (код операции) - 16 битов
ar$sha  (аппаратный адрес отправителя) - n байтов
ar$spa  (протокольный адрес отправителя) - m байтов
ar$tha  (аппаратный адрес получателя) - n байтов
ar$tpa  (протокольный адрес получателя) - m байтов

Поля ar$hrd, ar$pro, ar$hln и ar$pln имеют такой же смысл, как для протокола ARP (см. [1]).

Предположим, что в качестве аппаратного используется 48-битовый адрес Ethernet, а в качестве протокольного — 32-битовый адрес IP. Нам требуется определить адрес IP, соответствующий известному адресу Ethernet. В этом случае для каждого пакета RARP выполняются равенства ar$hrd = 1 (Ethernet), ar$pro = 2048 (Ethertype для пакетов IP), ar$hln = 6, ar$pln = 4.

Протокол использует два кода операций: 3 (request reverse — запрос обратного преобразования) и 4 (reply reverse — отклик на запрос обратного преобразования). Коды операций 1 и 2 имеют такой же смысл, как указано в [1] — пакеты с такими кодами могут передаваться с использованием обычных программ ARP. Пакеты с любыми другими кодами операций являются ошибочными. Как и ARP, данный протокол не использует пакетов not found (не найдено) или error (ошибка), поскольку серверы RARP не обязаны отвечать на полученные запросы. Отправитель запроса RARP должен задавать для себя время ожидания (timeout) отклика на переданный запрос.

Поля ar$sha, ar$spa, $ar$tha и ar$tpa в пакетах RARP интерпретируются следующим образом:

Для пакетов с кодом операции 3 (request reverse):

ar$sha — аппаратный адрес отправителя пакета.
ar$spa — не определено.
ar$tha — аппаратный адрес получателя.
ar$tpa — не определено.

Для пакетов с кодом операции 4 (reply reverse):

ar$sha — аппаратный адрес отвечающего хоста.
ar$spa — протокольный адрес отвечающего хоста.
ar$tha — аппаратный адрес получателя.
ar$tpa — протокольный адрес получатель (то, что было запрошено).

  • [1] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT-LCS, November 1982.

Ниже приведены два наброска различных вариантов реализации сервера RARP для 4.2BSD.

  • Обеспечивается доступ к пакетам канального уровня за пределами ядра. Сервер RARP полностью реализуется за пределами ядра и взаимодействует с ядром только для приема или передачи пакетов RARP. Ядро изменяется так, чтобы обеспечивался требуемый доступ к пакетам RARP; в настоящее время ядро 4.2 обеспечивает доступ только для пакетов IP. Одним из существующих механизмов, которые обеспечивают возможность доступа к пакетам является псевдо-драйвер пакетного фильтра CMU. Этот драйвер успешно используется в CMU и Стэнфорде (Stanford) для реализации подобных серверов в пользовательском пространстве.

  • Создается кэш записей базы данных внутри ядра. Полная база данных сервера RARP поддерживается пользовательским процессом за пределами ядра. Сам сервер RARP реализуется в ядре и использует в откликах содержимое кэша записей. Кэш может быть таким же, какой используется для пересылки ARP. Кэш заполняется записями из базы данных с использованием двух новых операций ioctl (они подобны SIOCIFADDR в том, что реально не связываются с конкретным сокетом). Одна из операций обеспечивает нахождение в «спящем» режиме при отсутствии транзакций, а при появлении запросов передает их пользовательскому процессу, а вторая заносит запись этой транзакции в таблицу ядра. Таким образом, если ядро не может найти запись в кэше, оно помещает запрос в (глобальную) очередь и вызывает функцию wakeup(). Реализация первой операции ioctl включает вызов sleep(), считывание из очереди первого объекта т возврата его пользовательскому процессу. Поскольку ядро не может находится в состоянии ожидания на уровне прерывания, пока пользовательский процесс ответит, оно может отказаться от обработки запроса (в предположении, что клиент повторит запрос) или, если вторая операция ioctl передаст копию запроса обратно в ядро, сформировать и передать отклик на этот запрос.

Николай Малых, moc.milib@hkylamn

НОВОСТИ: Выпуск звукового сервера PulseAudio 12.0 Thu, 21 Jun 2018 12:59:20 +0300

Состоялся релиз звукового сервера PulseAudio 12.0, который выступает в роли посредника между приложениями и различными низкоуровневыми звуковыми подсистемами, абстрагируя работу с оборудованием. PulseAudio позволяет управлять громкостью и смешиванием звука на уровне отдельных приложений, организовывать поступление, смешивание и вывод звука при наличии нескольких входных и выходных каналов или звуковых карт, позволяет на лету менять формат звукового потока и использовать плагины, дает возможность прозрачно перенаправлять звуковой поток на другую машину. Код PulseAudio распространяется в рамках лицензии LGPL 2.1+. Поддерживается работа в Linux, Solaris, FreeBSD, OpenBSD, DragonFlyBSD, NetBSD, macOS и Windows.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome