/sys/doc/ Documentation archive

Протокол IL

Дейв Пресотто
Фил Уинтерботтом

presotto,philw@plan9.bell-labs.com

АБСТРАКТНО

IL — это новый сетевой протокол, предназначенный для доставки сообщений удаленных процедурных вызовов. Легкий транспортный протокол, который переносит дейтаграммы, изолированные от IP. IL обеспечивает повторную передачу потерянных сообщений и доставку с соблюдением порядка, но в нем недоступны операции управления потоками (flow control) и слепые повторные передачи.

Введение

В Plan 9 используется протокол файловой системы под названием 9P [1], который принимает упорядоченную гарантированную доставку раздельных сообщений, содержащих запросы и ответы удаленных процедурных вызовов (RPC). Ни один из стандартных протоколов IP [2] не пригоден для передачи сообщений 9P через сети Ethernet или Internet. У TCP [3] слишком большие потери данных и он не сохраняет разделители сообщений. UDP [4], при низкой стоимости и сохранении разделителей сообщений, отличается ненадежной доставкой дейтаграмм. Во время реализации IP, TCP и UDP в нашей системе мы пробовали выбрать протокол, пригодный для переноса сообщений 9P. Необходимыми были такие свойства:

Так как протокол, удовлетворяющий таким требованиям, не был найден, то мы разработали новый.

IL — это легкий, изолированный от IP, протокол. Он основан на соединениях и обеспечивает надежную передачу упорядоченных сообщений. Поскольку протокол предназначен для передачи сообщений RPC между клиентом и сервером, то отпадает необходимость в средствах управления потоками. Нас вполне устраивает структура с присущими потоковыми ограничениями. Уменьшенное окно для нераспределенных сообщений предотвращает от буферизации слишком большого количества входящих сообщений; сообщения за пределами окна отвергаются и должны быть переданы повторно. Установка соединения использует дуплексное квитирование связи для генерации начальных последовательных номеров в каждом конце соединения; чтобы получатель мог изменять порядок сообщений, последующие сообщения данных увеличивают последовательные номера. В отличие от других протоколов, IL избегает слепые повторные передачи, таким образом не происходит продублирование сообщений. Это свойство повышает производительность протокола в перегруженных сетях, где слепые повторные передачи могут вызывать дальнейшие перегрузки. Подобно TCP, IL имеет адаптивные тайм-ауты, в результате чего протокол работает одинаково хорошо как в Internet, так и в Ethernet. Таймер задержек используется для вычисления времени подтверждения и повторной передачи сообщения, которые характеризуют скорость работы сети.

Соединения

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

ackok любой последовательный номер между id0 и следующим включающим
!x любое значение кроме x
- любое значение

 

Рис. 1 — Переходы состояний IL

IL имеет пять состояний переходов: Closed, Syncer, Syncee, Established и Closing. Соединение идентифицируется IP адресом и номером порта, которые используются на каждом конце. Адреса размещаются в заголовке протокола IP, в то время как порты являются частью 18-байтового заголовка IL. Локальные переменные определяют состояние соединения:

state одно из состояний
laddr 32-битный локальный IP адрес
lport 16-битный локальный IL порт
raddr 32-битный удаленный IP адрес
rport 16-битный удаленный IL порт
id0 32-битный начальный последовательный номер локальной стороны
rid0 32-битный начальный последовательный номер удаленной стороны
next последовательный номер следующего отправляемого сообщения с локальной стороны
rcvd последнее сообщение из последовательности, полученное из удаленной стороны
unacked последовательный номер первого неподтвержденного сообщения

Неиспользуемые соединения находятся в состоянии Closed с не назначенными адресами и портами. Существует два события, которые могут открыть соединение: (1) получение сообщения, в котором адреса и порты не соответствуют ни одному открытому соединению; (2) явное открытие соединения пользователем. В первом случае, исходные адрес и порт сообщения стают удаленными адресом и портом соединения, и адрес и порт назначения сообщения стают локальными адресом и портом. Соединение переходит в состояние Syncee и сообщение считается обработанным. Во втором случае, пользователь указывает оба локальных и удаленных адреса и порта. Соединение переходит в состояние Syncer и сообщение sync отправляется в удаленную сторону. Официальные значения для локального адреса ограничены реализацией IP.

Последовательные номера

IL переносит сообщения данных, каждое из которых соответствует единственной записи от операционной системы и идентифицируется 32-битным последовательным номером. Стартовый последовательный номер для каждого направления в соединении выбирается произвольным образом и передается в начальном sync сообщении. Номер увеличивается для каждого последующего сообщения данных. Передаваемое повторно сообщение содержит его подлинный последовательный номер.

Передача/Повторная передача

Каждое сообщение содержит два последовательных номера: идентификатор (ID) и подтверждение. Подтверждение является последним упорядоченным сообщением данных, полученным передатчиком. Для сообщений data и dataquery, ID считается их последовательный номером. Для управляющих сообщений sync, ack, query, state и close, ID больше чем последовательный номер самого верхнего отправленного сообщения данных.

Отправитель передает сообщения данных с типом data. Любые сообщения путешествуют в противоположном направлении по отношению к подтверждениям. Если возвращаемое сообщение имеет нестандартное подтверждение отправителю, то в течение 200 мили секунд будет отправлено сообщение ack.

В IP, сообщения могут приходить поврежденными или вообще быть потеряны в результате перегрузки или дефектов. Для преодоления этого, IL использует модифицированный протокол «go back n», который также пытается избегать усугубления сетевых перегрузок. Среднее время подтверждения определяется измерением задержки между передачей сообщения и получением его подтверждения. До того как первое подтверждение будет получено, среднее время подтверждения принимается за 100 мс. Если подтверждение не пришло за четыре периода подтверждения первого неподтвержденного сообщения (тайм-аут rexmit на Рис. 1), IL решает что сообщение или подтверждение потеряно. Затем отправитель пересылает лишь первое неподтвержденное сообщение с установленным типом dataquery. Когда получателю приходит dataquery, то он отвечает сообщением state, подтверждающим самое верхнее полученное упорядоченное сообщение данных. Это может быть повторно переданное сообщение или же, если получателем были сохранены неупорядоченные сообщения, какое-нибудь из выше перечисленных сообщений. Реализация получателя свободна для выбора сохранения неупорядоченных сообщений. Наша реализация сохраняет по 10 пакетов за раз. Когда отправитель получает сообщение state, то он немедленно пересылает следующее неподтвержденное сообщение с типом dataquery. Это продолжается до тех пор, пока все сообщения не будут подтверждены.

Если после первого dataquery ни одного подтверждения не было получено, то передатчик продолжает находится в тайм-ауте и пересылать сообщение dataquery. Интервалы между повторными передачами увеличиваются экспоненциально. После прохождения 300 периодов времени подтверждения (тайм-аут death на Рис. 1) отправитель прекращает отправку и решает, что соединение мертвое.

Повторная передача также происходит в состояниях Syncer, Syncee и Close. Интервалы повторной передачи такие же как для сообщений данных.

Сохранение работоспособности

Соединения с мертвыми системами должны обнаруживаться и отвергаться, если они поглощают ресурсы. Если выживающей системе не требуется отправление каких-либо данных и все отправленные ею данные подтвердились, то описанный выше протокол не будет обнаруживать эти соединения. Следовательно, в состоянии Established, если никакие другие сообщения не отправляются за 6-ти секундный период, отправляется query. Получатель всегда отвечает на сообщения query и state. Если за 30 секунд никакое сообщение не приходит, соединение отклоняется. Это не показано на Рис. 1.

Порядок байт

Все 32- и 16-битные количества передаются с первым старшим байтом, что обычно для IP.

Форматы

Ниже представлено описание заголовка IP+IL на языке C, предполагается, что опции IP не заданы:

Предполагается, что в сообщении данные следуют немедленно за заголовком. Ilspec — это расширение, зарезервированное для изменений в протоколе на будущее.

Контрольная сумма вычисляется вместе с ilsum и ilspec, установленными в нуль. Это стандартная контрольная сумма IP — 16-битное дополнение суммы дополнения всех 16-битных слов в заголовке и тексте. Если сообщение содержит странный номер заголовка и текстовые байты, контрольная сумма которых должна быть вычислена, последний байт заполняется справа нулями для формирования 16-битных слов для контрольной суммы. Контрольная сумма защищена от cksum до конца данных.

Возможные значения iltype:

Поле illen является размером заголовка IL в байтах (18 байт) плюс размер данных.

Номера

Номер протокола IP для IL равен 40.

Назначенные номера портов IL:

7 эхо всего ввода на вывод
9 исключение ввода
19 отправление стандартного образца на вывод
565 отправление IP адреса caller и callee на вывод
566 протокол аутентификации Plan 9
17005 сервис Plan 9 CPU, данные
17006 сервис Plan 9 CPU, примечания
17007 экспортированные файловые системы Plan 9
17008 файловый сервис Plan 9
17009 удаленное выполнение Plan 9
17030 сервер имен Alef

Литература

[1] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom, The Use of Name Spaces in Plan 9, Op. Sys. Rev., Vol. 27, No. 2, April 1993, pp. 72-76, reprinted in this volume.
[2] RFC791, Internet Protocol, DARPA Internet Program Protocol Specification, September 1981.
[3] RFC793, Transmission Control Protocol, DARPA Internet Program Protocol Specification, September 1981.
[4] J. Postel, RFC768, User Datagram Protocol, DARPA Internet Program Protocol Specification, August 1980.

Copyright © 2000 Lucent Technologies Inc. All rights reserved.
Copyright © 2003 Перевод Андрей С. Кухар.