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) соединения и протоколирование причины.