RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых
4.2.2.3 Размер окна: RFC 793, параграф 3.1

Размер окна должен трактоваться как беззнаковое целое — если большое окно будет представляться как окно с отрицательным размером, TCP просто не будет работать. Рекомендуется использовать 32-битовые поля для размера окна передачи и приема в записи с параметрами соединения.

  • Обсуждение:
  • Известно, что поле размера окна в заголовке TCP слишком мало для высоких скоростей и путей с большой задержкой. Для расширения окна TCP определены экспериментальные опции (см. например, [RFC1072]). С учетом такого расширения при реализации TCP следует рассчитывать на 32-битовые значения размера окна.
4.2.2.4 Указатель срочности: RFC 793, параграф 3.1

Второе предложение этого параграфа содержит ошибку — urgent pointer указывает на порядковый номер последнего (а не следующего за ним) октета в последовательности срочных (urgent) данных. Описание на стр. 56 (последнее предложение) корректно.

Протокол TCP должен поддерживать последовательности срочных данных любой длины.

Протокол TCP должен информировать прикладной уровень в асинхронном режиме всякий раз, если указатель Urgent получен при отсутствии ожидающих обработки срочных данных или Urgent упреждает срочные данные в потоке. Для приложений должен обеспечиваться способ определения количества остающихся срочных данных, которые будут прочитаны из соединения, или, по крайней мере, возможность узнать о наличии таких данных.

  • Обсуждение:
  • Хотя механизм Urgent может использоваться для любых приложений, обычно он применяется для передачи «прерываний» типа команд Telnet (см. параграф Using Telnet Synch Sequence в [RFC1123]).

    Асинхронное уведомление за пределами основного канала (out-of-band) будет позволять приложениям перейти в режим urgent при чтении данных из соединения TCP. Это позволяет контролировать команды, передаваемые приложению, нормальный буфер которого заполнен необработанными данными.

  • Реализация
  • Базовый механизм ERROR-REPORT(), описанный в параграфе 4.2.4.1 может использоваться для информирования приложений о приходе важных данных.
4.2.2.5 Опции TCP: RFC 793, параграф 3.1

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.