Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
SETI_-_kopia.doc
Скачиваний:
97
Добавлен:
14.05.2015
Размер:
501.76 Кб
Скачать

22. Управление потоком в tcp.

На обоих хостах между которыми установлено TCP-соединение, имеются приемные буферы. Приложение считывает из них данные в произвольный момент времени. Если частота поступления данных в буфер превышает частоту их считывания приложением, то через некоторый интервал времени возникает угроза переполнения буфера. Для избежания этогоTCPпредоставляет приложениямслужбу контроля потока, призванную контролировать , чтобы частота передачи данных соответствовала частоте из считывания принимающим приложением. Скорость передачи может быть принудительно снижена - механизмконтроля перегрузок.TCPобеспечивает контроль приема с помощью переменной, называемойокном приема, поддерживается обеими сторонами, размер буфера хранится в переменнойRcvBuffer.

LastByteRead- номер последнего байта потока данных, считанного из буфера процессом В.

LastByteRcvd- номер последнего байта потока данных, полученного от передающей стороны и помещенного в буфер.

Чтобы входной буфер не мог переполниться, необходимо: LastByteRcvd-LastByteRead<=RcvBuffer.

Значение окна приема RcvWindowравно объему свободного места в буфере:

RcvWindoq=RcvBuffer- [LastByteRcvd-LastByteRead]

значение этой переменной динамически меняется.

Как реализовано: хост В сообщает А сколько свободного места имеется в его приемном буфере, помещая значение переменнойRcvWindowв поле окна приема каждого сегмента, отправляемого А. Начальные значенияRcvWindoq=RcvBuffer.

А поддерживает 2 переменные LastByteSentиLastByteAcked- номер последнего отправленного и последнего квитированного байтов.LastByteSent-LastByteAcked- размер неподтвержденных данных, переданных от А к В. при

LastByteSentиLastByteAcked<=RcvWindow

хост А может гарантировать, что приемный буфер хоста В не переполнится.

Проблема: предположим, что приемный буфер хоста В оказался заполненным, тогдаRcvWindow= 0, возможно, что в этот момент В не имеет данных для передачи, ТО А не получит сведений об освободившемся пространстве буфера и не сможет осуществлять дальнейшую передачу данных. Предусмотрена периодическая генерация хостом А сегментов, содержащих 1 байт, если окно приема В имеет нулевое значение, эти сегменты квитируются принимающей стороной и при освобождении места в буфере, ненулевое значениеRcvWindowбудет отправлено вместе с одной из квитанций.

23. Время выполнения запроса в статическом окне.

На практике размер окна перегрузки протокола TCPпостоянно меняется, для наглядности удобно представить окно перегрузки статическим. ПустьW- положительное целое число, равное размеру статического окна; это означает, что сервер не ожидая подтверждений, может передать не болееWсегментов. Далее сервер посылает каждый новый сегмент после получения одной из квитанций от клиента.

2 случая:

WS/R>RTT+S/R- сервер получает квитанцию для первого сегмента первого окна до завершения передачи его сегментов.

WS/R<RTT+S/R- сервер заканчивает передачу сегментов окна раньше, чем получает квитанцию для первого сегмента окна.

Инициирование TCP-соединения занимает все время оборота, на 2 обороте клиент отсылает серверу запрос на получение объекта, вложенный в последний сегмент тройного рукопожатия. Новые сегменты поступают к клиенту с периодичностьюS/Rи подтверждаются им. Если сервер получает 1 подтверждение до завершения передачи сегментов окна, он имеет возможность передавать сегменты следующего окна сразу по завершении передачи сегментов предыдущего окна. Все подтверждения поступают на сервер с периодичностьS/Rс, поэтому сервер передает новые сегменты без простоев в ожидании подтверждений. ТО, если передача объекта начата со скоростьюR, то такая скорость сохраняется на протяжении всего процесса передачи, а следовательно задержка:T= 2RTT+O/R

Теперь 2 случай: Как и раньше новые сегменты поступают к клиенту ч периодичностью S/Rс. Сервер вынужден провести некоторое время в ожидании. Подтверждения на сервер поступают с периодичностьюS/Rc, и при получении каждого подтверждения сервер отсылает клиенту очередной сегмент. ТО сервер нах в 2 состояниях: передачаWсегментов или простой. Простой:K=O/WS(если не целое, то округляем в большую сторону). В процессе передачи сервер входит в состояние простояK-1 раз, при этом время простоя:RTT- (W-1)S/R.

Задержка: 2RTT + O/R + (K-1)*[S/R+RTT-WS/R]

Объединим оба случая: 2RTT+O/R+ (K-1)*[S/R+RTT-WS/R]*

[x]*=max(x,0). Задержка складывается из 3 составляющих: 2RTT- установление соединения,O/R- время передачи объекта, (K-1)*[S/R+RTT-WS/R]* - время простоя сервера.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]