RFC 3081 Mapping the BEEP Core onto TCP

Опубликовано 24.03.2001 автором Nikolai Malykh 
Network Working Group                                            M. Rose
Request for Comments: 3081                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001

Отображение ядра BEEP на TCP

Mapping the BEEP Core onto TCP

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа “Internet Official Protocol Standards” (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2001). All Rights Reserved.

Аннотация

В этом документе описано, как сессия BEEP1 отображается в одно соединение TCP (Transmission Control Protocol).

1. Введение

Этот документ описывает, как сессия BEEP [1] отображается в одно соединение TCP [2]. Требования к отображениям заданы в параграфе 2.5 документа [1].

2. Управление сессиями

Отображение поддержки сессий BEEP на услуги TCP достаточно прямолинейно.

Сессия BEEP организуется, когда создано соединение TCP между двумя партнерами BEEP:

  • узел BEEP, задавший пассивный вызов TCP OPEN, называется «слушателем»;

  • узел BEEP, задавший активный вызов TCP OPEN, называется «инициатором».

Одновременный вызов TCP OPEN2 приведет к тому, что оба партнера BEEP будут считать себя инициаторами и не смогут организовать ни одного канала. Поэтому основанные на протоколе BEEP службы должны быть устроены так, что одновременных вызовов TCP OPEN не возникает.

Если оба партнера согласны освободить (завершить) сеанс BEEP (см. параграф 2.4 в [1]), узел передавший отклик ok, незамедлительно вызывает TCP CLOSE. При получении отклика другой партнер также незамедлительно вызывает TCP CLOSE.

Сессия BEEP прерывается при вызове любым из партнеров TCP ABORT и последующем разрыве соединения TCP.

3. Обмен сообщениями

Отображение обменов BEEP на услуги TCP менее прямолинейно.

Гарантированная отправка и получение обеспечиваются вызовами SEND и RECEIVE протокола TCP, это обеспечивает также упорядоченную доставку сообщений в одном канале.

TCP обеспечивает управление потоком данных в соединении, но при использовании в одной сессии BEEP множества каналов протокол BEEP должен обеспечить механизм для предотвращения «заторов» в соединении. Для этого BEEP использует механизм, принятый в TCP, — управление потоком данных на основе окон, когда каждый канал использует скользящее окно, показывающее число октетов данных, которые можно передать до следующего разрешения.

3.1 Управление потоком данных

Напомним из параграфа 2.2.1.2 документа [1], что каждый октет данных, переданный в каждом направлении канала имеет порядковый номер. Нумерация октетов данных в кадрах выполняется последовательно от начала поля данных (payload).

Пространство порядковых номеров конечно, хотя и весьма велико, – от 0 до 4294967295 (232 – 1). Конечность пространства номеров приводит к использованию арифметики с модулем 232 и при достижении максимального значения 232 – 1 отсчет номеров продолжается с 0. Арифметика порядковых номеров описана в разделах 2 – 5 документа [3].

3.1.1 Создание канала

При создании канала первый октет данных в первом кадре получает номер 0, а начальный размер окна устанавливается равным 4096 октетам. После создания канала узлы BEEP могут менять размер окна путем передачи кадров SEQ (3.1.3 Обработка кадров SEQ).

Если узел BEEP запросили создать канала, но он не может выделить для этого канала хотя бы 4096 октетов, узел должен отвергнуть создание канала, как указано в параграфе 2.3.1.2 документа [1]. Аналогично, если в процессе организации сессии BEEP «слушатель» BEEP не может выделить хотя бы 4096 октетов для канала 0, он должен возвратить негативный отклик, как указано в параграфе 2.4 документа [1], вместо передачи сообщения greeting.

3.1.2 Передача сообщений

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

  • если окно позволяет передать хотя бы один октет данных (payload), узел BEEP может сегментировать сообщение и начать передачу более мелкого кадра (в соответствии с размером окна);

  • узел BEEP может задержать отправку сообщения, пока окно не станет больше;

  • узел BEEP может сообщить приложению о невозможности отправки сообщения, что позволит тому повторить попытку позднее (например, после получения сигнала об увеличении доступного окна).

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

3.1.3 Обработка кадров SEQ

Поскольку приложение принимает на себя ответственность за входящие кадры данных, его партнеру BEEP следует передавать кадры SEQ для анонсирования нового окна.

ABNF [4] для кадров SEQ имеет вид:

      seq        = "SEQ" SP channel SP ackno SP window CR LF
      ackno      = seqno
      window     = size
      ; channel, seqno и size определены в параграфе 2.2.1 документа [1].

Кадр SEQ имеет три параметра:

  • номер канала;

  • номер подтверждения, указывающий следующий порядковый номер, который отправитель предполагает получить в этом канале;

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

Для разделения компонент служит одиночный символ пробела (десятичный код 32). Кадр SEQ завершается парой символов CRLF.

Если при получении кадра SEQ номер канала, номер подтверждения или размер окна не удается определить или заданное значение неприемлемо, сессия BEEP прерывается без генерации отклика. Рекомендуется записать это событие в системный журнал для диагностики.

3.1.4 Использование управления потоком данных

Ключом к успеху управления потоком данных в BEEP является баланс между производительностью и беспристрастностью:

  • большие сообщения следует сегментировать в кадры, не превышающие 2/3 от согласованного максимального размера сегмента TCP;

  • кадры разных каналов, готовые к передаче, следует выбирать «по кругу»;

  • каждый раз при получении кадра следует отправлять кадр SEQ, если размер окна составляет не менее половины доступного для канала буферного пространства;

  • если транспортный протокол представляет узлу BEEP множество кадров одновременно, можно передать один общий кадра SEQ.

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

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

Кроме того, реализациям, по возможности, следует поддерживать API транспортного уровня для передачи сведений о перегрузках. Это позволит реализации определить доступную полосу и будет информировать об изменении пропускной способности пути. Отметим, что при наличии в сессии BEEP множества каналов, одновременно передающих большие сообщения, реализации без доступа к данным о загрузке могут сталкиваться с проблемами распределения ресурсов в периоды перегрузки сети.

Реализациям следует также соблюдать рекомендации соответствующих разделов RFC1122 [5], относящиеся к управлению потоками данных (и принимать во внимание, что повтор передачи не применим для этого документа, хотя он и взаимодействует с управлением потоками данных TCP). Например, в параграфе 4.2.2.16 документа RFC1122 [5] сказано: «Получателям TCP не рекомендуется отсекать часть окна (т. е., перемещать правый край окна влево),» – а затем рассматривается влияние этого правила на неподтвержденные данные. В контексте отображения BEEP на одно соединение TCP следует реализовать лишь относящиеся к управлению потоком данных части.

4. Вопросы безопасности

Вопросы безопасности рассмотрены в разделе 9 документа [1].

Литература

[1] Rose, M., “The Blocks Extensible Exchange Protocol Core”, RFC 3080, March 2001.

[2] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.

[3] Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, August 1996.

[4] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997.

[5] Braden, R., “Requirements for Internet Hosts — Communication Layers”, STD 3, RFC 1122, October 1989.

Адрес автора

Marshall T. Rose

Invisible Worlds, Inc.

1179 North McDowell Boulevard

Petaluma, CA 94954-6559

US

Phone: +1 707 789 3700

EMail: mrose@invisible.net

URI: http://invisible.net/



Перевод на русский язык


Николай Малых


nmalykh@gmail.com 


Приложение A. Благодарности


Автор благодарен участникам работы Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver и Joe Touch. В частности, Dave Crocker внес полезные предложения о природе управления потоком данных для отображения.


Полное заявление авторских прав


Copyright (C) The Internet Society (2001). Все права защищены.


Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.


Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.


Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.


Подтверждение


Финансирование функций RFC Editor обеспечено Internet Society.






1Blocks Extensible Exchange Protocol — расширяемый протокол обмена блоками.






2С учетом предыдущего абзаца корректней было бы написать «Одновременный активный вызов TCP OPEN …». Прим. перев.



 											


		
						

							Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.