Закон Грехэма

Пустяковые вопросы решаются быстро; важные никогда не решаются.

- Поручик, вы трус и подлец. Я вызываю вас на дуэль! ...

Технический комитет OASIS утвердил спецификацию OpenDocument 1.3
Wed, 22 Jan 2020 10:03:53 +0300

Дистрибутив Kubuntu начал распространение ноутбука Kubuntu Focus
Wed, 22 Jan 2020 08:38:45 +0300

Для Btrfs представлена асинхронная реализация DISCARD
Wed, 22 Jan 2020 04:48:18 +0300

Сanonical предложил Anbox Cloud, облачную платформу для запуска Android-приложений
Tue, 21 Jan 2020 14:37:47 +0300

Red Hat развивает JIT-компилятор MIR
Tue, 21 Jan 2020 08:48:56 +0300

Rust-фреймворк actix-web возрождён и будет передан сообществу
Mon, 20 Jan 2020 21:36:52 +0300

В Минэкономики РФ предложили создать архив кода, дублирующий GitHub
Mon, 20 Jan 2020 19:05:46 +0300

Копилефт лицензии постепенно вытесняются пермиссивными
Sat, 18 Jan 2020 22:55:51 +0300

Разработчик Rust-фреймворка actix-web удалил репозиторий из-за травли
Sat, 18 Jan 2020 20:17:10 +0300

Linux-смартфон PinePhone доступен для заказа
Fri, 17 Jan 2020 09:55:06 +0300

Google опубликовал план прекращения поддержки Chrome Apps, NaCl, PNaCl и PPAPI
Fri, 17 Jan 2020 09:15:19 +0300

IBM, Microsoft и Mozilla поддержали Google в судебном разбирательстве с Oracle
Thu, 16 Jan 2020 21:42:07 +0300

В Xfce осуществлён перевод диалогов на декорирование окон на стороне клиента
Thu, 16 Jan 2020 12:19:52 +0300

На фоне реструктуризации из Mozilla уволено 70 сотрудников
Thu, 16 Jan 2020 07:00:21 +0300

Google намерен до 2022 года прекратить поддержку сторонних Cookie в Chrome
Wed, 15 Jan 2020 11:38:02 +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

НОВОСТИ: Сanonical предложил Anbox Cloud, облачную платформу для запуска ... Tue, 21 Jan 2020 14:37:47 +0300

Компания Сanonical представила новый облачный сервис Anbox Cloud, позволяющий на любых системах запускать приложения и играть в игры, созданные для платформы Android. Приложения запускаются на внешних серверах с использованием открытого окружения Anbox, c потоковой трансляцией вывода на систему клиента и передачей событий от устройств ввода c минимальными задержками.

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