1 Анализ предметной области

Содержание

Введение
1 Анализ предметной области
1.1 Общие сведения
1.2 Таймер повторной передачи
1.3 Устойчивый таймер TCP
1.4 Таймер «оставайся в живых»
1.5 Таймер 2MSL
2 Разработка технологии проведения исследований
2.1 Общие сведения
2.2 Таймер повторной передачи
2.3 Устойчивый таймер TCP
2.4 Таймер «оставайся в живых»
2.5 Таймер 2MSL
3 Разработка средств решения поставленной задачи
4 Исследование модели и анализ результатов
4.1 Исследование таймера повторной передачи
4.2 Исследование устойчивого таймера TCP
4.3 Исследование таймера "оставайся в живых"
4.4 Исследование таймера 2MSL
Заключение
Список используемых источников

Введение.

Transmission Control Protocol (TCP) (протокол управления передачей) – один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP. Выполняет функции протокола транспортного уровня модели OSI.

TCP — это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета (см. также T/TCP). В отличие от UDP гарантирует целостность передаваемых данных и уведомление отправителя о результатах передачи.

Реализация TCP, как правило, встроена в ядро ОС, хотя есть и реализации TCP в контексте приложения.

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

TCP - это надежный транспортный уровень. Один из способов обеспечения надежности заключается в том, что удаленный участник обмена подтверждает полученные данные. Однако, сегменты данных, которые должны быть подтверждены, могут быть потеряны. TCP отрабатывает подобные ситуации установкой тайм-аута, при отправке данных; если данные не были подтверждены до момента истечения тайм-аута, TCP передает их повторно. Основными составляющими частями подобной технологии являются тайм-ауты и повторные передачи.

1 Анализ предметной области

1.1 Общие сведения

TCP управляет четырьмя таймерами для каждого соединения:

- Таймер повторной передачи (retransmission) используется в том случае, когда ожидается подтверждение от удаленного конца.

- Устойчивый (persist) таймер, в течение которого сохраняется информация о размере окна передачи, даже если удаленный конец закрыл свое приемное окно.

- Таймер времени жизни (keepalive) определяет, когда можно считать, что удаленный конец вышел из строя или перезагрузился.

- Таймер 2MSL определяет время, в течение которого соединение может быть в состоянии TIME_WAIT.

1.2 Таймер повторной передачи

Основой тайм-аутов и повторных передач TCP является расчет времени возврата (RTT - round-trip time), соответствующего данному соединению. Мы ожидаем, что оно может изменяться со временем, так как может измениться маршрут, или загрузка сети. TCP должен отследить эти изменения и соответственно модифицировать тайм-ауты.

Во-первых, TCP должен рассчитать RTT между отправкой байта с конкретным номером последовательности и получением подтверждения на этот номер последовательности. Обычно не существует полного соответствия между сегментами данных и подтверждениями (ACK). Мы используем величину M, чтобы обозначить рассчитанный RTT. Для определения RTT существует расширение к исходной спецификации TCP, которое называется хэшированная оценочная функция RTT (обозначается R)

(1.1)

где α - это коэффициент хэширования с рекомендуемым значением 0,9. Хэширование - способ организации структур данных (хэш-таблиц), обеспечивающий эффективный поиск и пополнение; положение элемента данных в хэш-таблице определяется значением функции расстановки, отображающей множество возможных ключей элементов данных и множество индексов таблицы и обеспечивающей равномерное заполнение. Хэшированный RTT обновлялся каждый раз, когда осуществлялось новое вычисление. Девяносто процентов данных для каждого нового расчета берется из предыдущего расчета, а десять из нового. Для подобной хэшированной оценочной функции, которая изменяется с изменением RTT, RFC 793 рекомендует, чтобы тайм-аут повторной передачи (RTO) устанавливался следующим образом

(1.2)

где β - это коэффициент изменения задержки с рекомендуемым значением равным 2. Джекобсон подробно обсуждает проблемы, связанные с подобным подходом, в основном заключающиеся в том, что он не может применяться при широком диапазоне изменения RTT, и является причиной нежелательных повторных передач. Как замечает Джекобсон, нежелательные повторные передачи увеличивают загрузку сети. В этом случае необходимо добавить возможность отслеживать расхождения в расчетах RTT в дополнение к хэшированной функции оценки RTT. Расчет RTO основанный на среднем и расхождении дает значительно лучшие результаты при широком диапазоне изменений времен возврата, чем просто расчет RTO как постоянного кратного среднего значения. Как описано у Джекобсона, среднее отклонение является хорошим приближением к стандартному отклонению, однако рассчитывается значительно легче. (Расчет стандартного отклонения требует вычисления квадратного корня.) Таким образом, следующие уравнения могут быть применены к каждому расчету RTT M.

(1.3)

(1.4)

(1.5)

(1.6)

где A - это хэшированный RTT (оценочная функция среднего), а D это хэшированное среднее отклонение. Err это разница между только что рассчитанным значением и текущим значением оценочной функции RTT. Оба A и D используются для расчета следующего тайм-аута повторной передачи (RTO). Увеличение среднего (g) установлено в значение 1/8 (0,125). Увеличение отклонения (h) установлено в 0,25. Максимальное увеличение отклонения делает рост RTO быстрее при изменении RTT. Джекобсон устанавливает 2D при расчете RTO, однако для следующих исследований Джекобсон изменяет это значение на 4D. Джекобсон показывает способ осуществить эти вычисления с использованием целочисленной арифметики, именно так это обычно делается в стандартных реализациях. (Одна из причин заключается в том, что g, h и множитель 4 - это степени двух, поэтому все операции могут быть осуществлены с помощью сдвига, без умножений и делений.) Сравнение исходного метода с методом Джекобсона показывает, что расчеты хэшированного среднего одинаковы (α равно единица минус увеличение (g)), однако используются различные увеличения. Также, расчет RTO по Джекобсону зависит от обоих значений - хэшированного RTT и хэшированного среднего отклонения, тогда как оригинальный метод использует умножение хэшированных RTT.

1.3 Устойчивый таймер TCP

TCP получатель осуществляет управление потоком данных, указывая количество данных, которые он хочет получить от отправителя: размер окна. Что происходит, когда размер окна становится равным 0? Обычно это останавливает отправителя, который прекращает передавать данные до тех пор, пока размер окна станет ненулевым. TCP должен предпринять какие-либо действия в том случае, если подтверждение, открывающее окно было потеряно. Подтверждения передаются ненадежно - другими словами, TCP не подтверждает сами подтверждения, он подтверждает только сегменты, содержащие данные. Если подтверждение потеряно, на каждом конце соединения будут ждать действий от удаленного конца: получатель ожидает получить данные (так как он отправил отправителю ненулевое окно), а отправитель надеется получить обновление окна, которое позволит ему продолжить передачу. Чтобы выйти из подобного тупика, отправитель использует устойчивый (persist) таймер, в соответствии с которым осуществляется периодический опрос получателя на предмет, не был ли увеличен размер окна. Сегменты, которые при этом посылает отправитель, называются пробами окна (window probes).

1.4 Таймер «оставайся в живых»

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

При этом подразумевается, что ни одно из приложений - клиент или сервер, не имеет таймеров на прикладном уровне, которые позволяют определить отсутствие активности по соединению, и прекратить работу приложения. Например протокол BGP посылает пробы приложениям на удаленном конце каждые 30 секунд. Это прикладной таймер, который действует независимо от TCP таймера "оставайся в живых".

Однако существуют моменты, когда сервер хочет узнать, что случилось с хостом клиента: или он вышел из строя и был выключен, или вышел из строя и перезагрузился. Таймер "оставайся в живых" (keepalive timer) это характеристика большинства реализаций, которая предоставляет эту возможность.

Таймеры "оставайся в живых" не являются частью TCP спецификации. Требования к хостам Host Requirements RFC приводят три причины, по которым их не следует использовать: (1) они могут привести к тому, что абсолютно нормальное соединение будет разорвано из-за непродолжительного сбоя, (2) они занимают определенную ширину полосы, и (3) они стоят денег, так как обмен пакетами между сетями имеет определенную цену. Тем не менее, большинство реализаций имеют таймер "оставайся в живых".

Необходимость иметь таймер "оставайся в живых" все еще обсуждается. Многие считают, что подобный опрос удаленного конца не свойственен TCP и должен по необходимости осуществляться приложением. Опция "оставайся в живых" может вызвать разрыв устойчивого соединения между двумя процессами из-за временной потери соединения между двумя конечными системами. Например, если проба "оставайся в живых" отправлена в тот момент, когда промежуточный маршрутизатор вышел из строя и перезагружается, TCP подумает, что вышел из строя хост клиента, что, естественно, не так.

Характеристика "оставайся в живых" предназначена для того, чтобы приложение сервера могло оценить поведение клиентов и имело возможность определить, что клиент вышел из строя. Большинство версий Telnet и Rlogin серверов по умолчанию включают опцию "оставайся в живых".

Можно привести пример, однозначно доказывающий необходимость характеристики "оставайся в живых". Пользователи персональных компьютеров часто заходят терминалами на хост с помощью Telnet. В конце рабочего дня они просто выключают питание компьютера, не закрыв соединения. При этом остается полуоткрытое соединение. Отправка данных по полуоткрытому соединению приводит к возврату сброса (reset), однако это происходит в том случае когда данные отправляются клиентом. Если клиент исчез, оставив полуоткрытое соединение на конце сервера, а сервер ожидает каких-либо данных от клиента, он будет ждать вечно. Характеристика "оставайся в живых" предназначена для того, чтобы помочь серверу определить наличие полуоткрытых соединений.

1.5 Таймер 2MSL

Состояние ВРЕМЯ_ОЖИДАНИЯ (TIME_WAIT) также иногда называется состоянием ожидания 2MSL. В каждой реализации выбирается значение для максимального времени жизни сегмента (MSL - maximum segment lifetime). Это максимальное время, в течение которого сегмент может существовать в сети, перед тем как он будет отброшен. Мы знаем, что это время ограничено, так как TCP сегменты передаются посредством IP датаграмм, а каждая IP датаграмма имеет поле TTL, которое ограничивает время ее жизни.

При использовании MSL действуют следующие правила: когда TCP осуществляет активное закрытие и посылает последний сегмент содержащий подтверждение (ACK), соединение должно остаться в состоянии TIME_WAIT на время равное двум MSL. Это позволяет TCP повторно послать последний ACK в том случае, если первый ACK потерян (в этом случае удаленная сторона отработает тайм-аут и повторно передаст свой конечный FIN).

Другое назначение ожидания 2MSL заключается в том, что пока TCP соединение находится в ожидании 2MSL, пара сокетов, выделенная для этого соединения (IP адрес клиента, номер порта клиента, IP адрес сервера и номер порта сервера), не может быть повторно использована. Это соединение может быть использовано повторно только когда истечет время ожидания 2MSL.

К сожалению, большинство реализаций (Berkeley одна из них) подчиняются более жестким требованиям. По умолчанию локальный номер порта не может быть повторно использован, до тех пор пока этот номер порта является локальным номером порта пары сокетов, который находится в состоянии ожидания 2MSL.

Некоторые реализации и API предоставляют средства, которые позволяют обойти эти ограничения. С использованием API сокет может быть указана опция сокета SO_REUSEADDR. Она позволяет вызывающему назначить себе номер локального порта, который находится в состоянии 2MSL, однако правила TCP не позволяют этому номеру порта быть использованным в соединении, которое находится в состоянии ожидания 2MSL.

Каждый задержанный сегмент, прибывающий по соединению, которое находится в состоянии ожидания 2MSL, отбрасывается. Так как соединение определяется парой сокет в состоянии 2MSL, это соединение не может быть повторно использовано до того момента, пока мы не сможем установить новое соединение. Это делается для того, чтобы опоздавшие пакеты не были восприняты как часть нового соединения. (Соединение определяется парой сокет. Новое соединение называется восстановлением или оживлением данного соединения.)

Обычно клиент осуществляет активное закрытие и входит в режим TIME_WAIT. Сервер обычно осуществляет пассивное закрытие и не проходит через режим TIME_WAIT. Можно сделать вывод, что если мы выключим клиента и немедленно его перестартуем, этот новый клиент не сможет использовать тот же самый локальный номер порта. В этом нет никакой проблемы, так как клиенты обычно используют динамически назначаемые порты и не заботятся, какой динамически назначаемый порт используется в настоящее время. Однако, с точки зрения сервера все иначе, так как сервера используют заранее известные порты. Если мы выключим сервер, который имеет установленное соединение, и постараемся немедленно перестартовать его, сервер не может использовать свой заранее известный номер порта в качестве конечной точки соединения, так как этот номер порта является частью соединения, находящегося в состоянии ожидания 2MSL. Поэтому может потребоваться от 1 до 4 минут, перед тем как сервер будет перестартован.

2 Разработка технологии проведения исследований

2.1 Общие сведения

При исследовании всех четырёх таймеров TCP протокола, клиент будет запускаться на операционной системе Linux Mint 12, сервер запускается на операционной системе UBUNTU 10.04, которая установлена на Oracle VirtualBox. VirtualBox, в свою очередь, установлен на Linux Mint 12.

Для просмотра передаваемых пакетов по TCP протоколу, используется утилита tcpdump.

В качестве клиента и сервера, при исследовании таймеров, таких, как устойчивый таймер, таймер "оставайся в живых", таймер 2MSL, будет выступать программа sock, которая, с помощью передаваемых ей аргументов, может работать в режиме, как сервера, так и клиента.

2.2 Таймер повторной передачи

Для проведения исследования таймера повторной передачи, используется следующий алгоритм:

1 – сервер регистрируется в сети. Выполняется командой java TCPServer

2 – подключается клиент к серверу. Выполнятся команда java Client host, где host – ip-адрес сервера

3 – клиент обменивается с сервером сообщениями для того, чтобы убедится, что соединение работает. Для этого вводятся любые символы со стороны клиента в программе Client, и со стороны сервера в программе TCPServer поочерёдно.

4 – сервер отключается от сети: отсоединяется сетевой кабель от сервера, чтобы сервер не послал пакеты о завершении своей работы, а клиент продолжал думать, что сервер все ещё работает. Для этого отключаем активное сетевое подключение в VirtualBox.

5 – клиент отсылает сообщение на сервер. Отправляется любые символы в программе Client.

6 – производится наблюдение за повторными передачами пакета. Используется утилита tcpdump. Ожидается, что повторных передач пакета будет более одной, и время между повторными передачами будет увеличиваться. Значение таймера повторной передачи определяется, как промежуток времени между повторными передачами пакета.

2.3Устойчивый таймер TCP

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

1 – запускается принимающий процесс, который ожидает прихода запроса на соединение от клиента, принимает запрос на соединение, а затем надолго засыпает перед тем, как начать чтение из сети. Выполняется команда sock -is -Pn port, где n – количество ожидаемых сервером миллисекунд, port – номер порта.

2 – запускается клиент, который будет передавать данные принимающему процессу. Выполняем команду sock -i -n100 -w4096 host port, где host – ip-адрес сервера, port – порт сервера.

3 – производится наблюдение за передачей пакетов. Ожидается, что после ухода принимающего процесса в состояние ожидания, клиент будет производить пробы окна по истечению 500мс на устойчивом таймере, после получения сообщения от сервера с параметром размера окно win=0, до того момента, пока не получит сообщения с параметром размера окна win > 0. Так же ожидается, что после каждой отправки пробы окна, значение таймера будет увеличиватся.

4 – значение устойчивого таймера определяется как промежуток времени между пробами окна.

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

2.4 Таймер «оставайся в живых»

Обозначается конец, на котором включается опция "оставайся в живых" – сервером, а другой конец – клиентом. Хост клиента включен и доступен для сервера. TCP клиент откликается нормально, и сервер знает, что удаленный конец все еще включен. TCP сервер перезапустит таймер "оставайся в живых" еще на 2 часа. Если до истечения следующих 2 часов по соединению будет осуществлен какой-либо обмен, таймер снова сбросится и установится в 2 часа. Алгоритм проведения исследования будет следующим:

1 – включается сервер с опцией "оставайся в живых". Выполняется команда sock -K -s -v port. Параметр –К включает опцию "оставайся в живых".

2 – запускается клиент. Выполняется команда sock -v host port

3 – производится обмен сообщениями между сервером и клиентом, чтобы убедится, что соединение работает, и сбросить таймер "оставайся в живых".

4 – в течении более четырёх часов не отсылаются сообщения между клиентом и сервером

5 – производится наблюдение за пакетами подтверждения соединения по истечению каждых 2-х часов.

6 – отключается кабель от сервера. Для этого отключаем активное сетевое подключение в VirtualBox. Ожидается, что при следующей отсылке пакета "оставайся в живых", не получив пакет подтверждения, сервер должен определить, что соединение разорвано.

2.5 Таймер 2MSL

В отличии от клиентов, которые обычно используют динамически назначаемые порты, сервера используют заранее известные порты. Если мы выключим сервер, который имеет установленное соединение, и постараемся немедленно перестартовать его, сервер не может использовать свой заранее известный номер порта в качестве конечной точки соединения, так как этот номер порта является частью соединения, находящегося в состоянии ожидания 2MSL. Поэтому может потребоваться от 1 до 4 минут, перед тем как сервер будет перестартован.

Для исследования таймера 2MSL воспользуемся следующим алгоритмом:

1 – запускается сервер. Выполняется команда sock -v -s port

2 – запускается клиент, который подключается к серверу. Выполняется команда sock -v host port.

3 – на сервере вводится символ выключения, чтобы корректно выключить сервер.

4 – запускается таймер, и регистрируется время попытки перезапуска сервера на том порту, на котором сервер работал до выключения

5 – MSL будет равно половине отрезка времени от выключения сервера до его повторного запуска.

6 – повторно запускается клиент командой sock -v host port.

7 – вводится символ выключения на клиенте, чтобы отключить клиент.

8 – запускается таймер, и регистрируем время попытки перезапуска клиент на том порту, на котором клиент работал до выключения. Выполняются команды sock -bClientPort -v hostServer portServer, где ClientPort – порт, на котором был запущен клиент до его отключения.

9 – определяется MSL, аналогично пункту 5. Ожидается, что MSL на сервере будет равно MSL на клиенте, при условии одинаковых платформ операционных систем клиента и сервера.

3 Разработка средств решения поставленной задачи

Для исследования таймера повторной передачи, были написаны клиент и сервер на языке программирования Java, которые смогут обмениваться текстовыми сообщениями по TCP протоколу. Программный код клиента представлен в листинге 1, программный код сервера представлен в листинге 2.

Листинг 1 – программный код клиента Client.java

import java.io.*;

import java.net.*;

/**

* TCP message client

* @author Anton Lyashenko

public class Client {

public static void main(String[] args) {

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));

PrintStream out = System.out;

try {

Socket c = new Socket(args[0], 8888);

printSocketInfo(c);

BufferedWriter w = new BufferedWriter(new OutputStreamWriter(c.getOutputStream()));

BufferedReader r = new BufferedReader(new InputStreamReader(c.getInputStream()));

String m = null;

while ((m = r.readLine())!= null) {

out.println(m);

m = "Client: " + in.readLine();

w.write(m, 0, m.length());

w.newLine();

w.flush();

}

w.close();

r.close();

c.close();

} catch (IOException e) {

System.err.println(e.toString());

}

private static void printSocketInfo(Socket s) {

System.out.println("Remote address = " + s.getInetAddress().toString());

System.out.println("Remote port = " + s.getPort());

System.out.println("Local socket address = " + s.getLocalSocketAddress().toString());

System.out.println("Local address = " + s.getLocalAddress().toString());

System.out.println("Local port = " + s.getLocalPort());

}

Листинг 2 – программный код сервера Server.java

import java.util.Random;

import java.io.*;

import java.net.*;

/**

* TCP message server

* @author Anton Lyashenko

public class Server extends Thread {

public void run() {

Random randomGenerator = new Random();

int randomInt = randomGenerator.nextInt(6);

System.out.println(randomInt);

}

public static void main(String[] args) {

try {

ServerSocket s = new ServerSocket(8888);

printServerSocketInfo(s);

Socket c = s.accept();

printSocketInfo(c);

BufferedWriter w = new BufferedWriter(new OutputStreamWriter(c.getOutputStream()));

BufferedReader r = new BufferedReader(new InputStreamReader(c.getInputStream()));

String m = "Welcome to Reverse Echo Server." + " Please type in some words.";

w.write(m, 0, m.length());

w.newLine();

w.flush();

Server mythr = new Server();

mythr.start();

while ((m = r.readLine())!= null) {

System.out.println("Client: " + m);

BufferedReader mybr = new BufferedReader(new InputStreamReader(System.in));

String mystr = "Server: " + mybr.readLine();

w.write(mystr, 0, mystr.length());

w.newLine();

w.flush();

}

w.close();

r.close();

c.close();

s.close();

} catch (IOException e) {

System.err.println(e.toString());

}

private static void printSocketInfo(Socket s) {

System.out.println("Remote address = " + s.getInetAddress().toString());

System.out.println("Remote port = " + s.getPort());

System.out.println("Local socket address = " + s.getLocalSocketAddress().toString());

System.out.println("Local address = " + s.getLocalAddress().toString());

System.out.println("Local port = " + s.getLocalPort());

}

private static void printServerSocketInfo(ServerSocket s) {

System.out.println("Server socker address = " + s.getInetAddress().toString());

System.out.println("Server socker port = " + s.getLocalPort());

}

4 Исследование модели и анализ результатов

4.1 Исследование таймера повторной передачи

Выполненные действия, в соответствии с поставленным алгоритмом (п. 2.1), и результаты исследования, включая подробные комментарии, приведены в листинге 3.

Листинг 3 – исследование таймера повторных передач.

//запускаем сервер

anton@ubuntu:~/Chat$ java TCPServer

Server socker address = 0.0.0.0/0.0.0.0

Server socker port = 8888

//клиент подключился к серверу

Remote address = /192.168.1.3

Remote port = 39876

Local socket address = /192.168.1.2:8888

Local address = /192.168.1.2

Local port = 8888

//убеждаемся в работе соединения, получая сообщения от клиента и посылая ему //ответы

Client: message1

message2

Client: message3

message4

//после отправки сообщения message4 отключаем сетевой кабель

//запуск клиента

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ java Client 192.168.1.2

Remote address = /192.168.1.2

Remote port = 8888

Local socket address = /192.168.1.3:39876

Local address = /192.168.1.3

Local port = 39876

Welcome to Reverse Echo Server. Please type in some words.

//убеждаемся в работе соединения, передавая сообщения на сервер и получая

//ответы

message1

Server: message2

message3

Server: message4

//посылаем сообщение на сервер после того, как отключили сетевой кабель от //сервера

message5

//запускаем утилиту tcpdump

anton@anton-HP-Pavilion-dv6-Notebook-PC ~ $ sudo tcpdump tcp -i wlan0 -vv

tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes

//анализируем вывод утилиты tcpdump

//устанавливается соединение клиента с сервером

00:23:43.783562 IP (tos 0x0, ttl 64, id 1747, offset 0, flags [DF], proto TCP (6), length 60)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [S], cksum 0x8384 (incorrect -> 0x5ef9), seq 3574321117, win 14600, options [mss 1460,sackOK,TS val 3655950 ecr 0,nop,wscale 4], length 0

00:23:43.784292 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [S.], cksum 0x2bd0 (correct), seq 2658115748, ack 3574321118, win 5792, options [mss 1460,sackOK,TS val 595553 ecr 3655950,nop,wscale 6], length 0

//обмен сообщениями

00:23:43.784339 IP (tos 0x0, ttl 64, id 1748, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [.], cksum 0x837c (incorrect -> 0x6daa), seq 1, ack 1, win 913, options [nop,nop,TS val 3655950 ecr 595553], length 0

00:23:43.789563 IP (tos 0x0, ttl 64, id 46788, offset 0, flags [DF], proto TCP (6), length 111)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [P.], cksum 0xcb4f (correct), seq 1:60, ack 1, win 91, options [nop,nop,TS val 595554 ecr 3655950], length 59

00:23:43.789660 IP (tos 0x0, ttl 64, id 1749, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [.], cksum 0x837c (incorrect -> 0x6d6d), seq 1, ack 60, win 913, options [nop,nop,TS val 3655951 ecr 595554], length 0

00:24:08.385325 IP (tos 0x0, ttl 64, id 1750, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0x4a77 (correct), seq 1:18, ack 60, win 913, options [nop,nop,TS val 3662100 ecr 595554], length 17

00:24:08.386107 IP (tos 0x0, ttl 64, id 46789, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [.], cksum 0x4087 (correct), seq 60, ack 18, win 91, options [nop,nop,TS val 601704 ecr 3662100], length 0

00:24:24.284387 IP (tos 0x0, ttl 64, id 46790, offset 0, flags [DF], proto TCP (6), length 69)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [P.], cksum 0x1606 (correct), seq 60:77, ack 18, win 91, options [nop,nop,TS val 605679 ecr 3662100], length 17

00:24:24.284441 IP (tos 0x0, ttl 64, id 1751, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [.], cksum 0x837c (incorrect -> 0x1e32), seq 18, ack 77, win 913, options [nop,nop,TS val 3666075 ecr 605679], length 0

00:24:32.582451 IP (tos 0x0, ttl 64, id 1752, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0x0b25 (correct), seq 18:35, ack 77, win 913, options [nop,nop,TS val 3668149 ecr 605679], length 17

00:24:32.583167 IP (tos 0x0, ttl 64, id 46791, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [.], cksum 0x1123 (correct), seq 77, ack 35, win 91, options [nop,nop,TS val 607753 ecr 3668149], length 0

00:24:39.644538 IP (tos 0x0, ttl 64, id 46792, offset 0, flags [DF], proto TCP (6), length 69)

ubuntu.local.8888 > anton-HP-Pavilion-dv6-Notebook-PC.local.39876: Flags [P.], cksum 0xef40 (correct), seq 77:94, ack 35, win 91, options [nop,nop,TS val 609519 ecr 3668149], length 17

00:24:39.644588 IP (tos 0x0, ttl 64, id 1753, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [.], cksum 0x837c (incorrect -> 0x0010), seq 35, ack 94, win 913, options [nop,nop,TS val 3669915 ecr 609519], length 0

//после передачи пакета в 00:24:39.644588 от сервера отключаем сетевой кабель

//клиент пытается передать сообщение message5 серверу, т.к. не знает о том, что //сервер недоступен, посылая пакеты повторной передачи

00:25:07.046486 IP (tos 0x0, ttl 64, id 1754, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xda58 (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3676765 ecr 609519], length 17

00:25:07.250894 IP (tos 0x0, ttl 64, id 1755, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xda24 (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3676817 ecr 609519], length 17

00:25:07.666886 IP (tos 0x0, ttl 64, id 1756, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xd9bc (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3676921 ecr 609519], length 17

00:25:08.498892 IP (tos 0x0, ttl 64, id 1757, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xd8ec (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3677129 ecr 609519], length 17

00:25:10.166898 IP (tos 0x0, ttl 64, id 1758, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xd74b (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3677546 ecr 609519], length 17

00:25:13.502895 IP (tos 0x0, ttl 64, id 1759, offset 0, flags [DF], proto TCP (6), length 69)

anton-HP-Pavilion-dv6-Notebook-PC.local.39876 > ubuntu.local.8888: Flags [P.], cksum 0xd409 (correct), seq 35:52, ack 94, win 913, options [nop,nop,TS val 3678380 ecr 609519], length 17

Проанализируем повторную передачу пакета. В данном эксперименте ожидание пакетов повторной передачи заняло 10 минут, однако после отправки пакета в момент времени 00:25:13.502895 больше пакетов отослано не было. Всего клиентом на повторную передачу пакета было сделано 6 попыток. Расчеты значения таймера повторной передачи приведены в таблице 1.

Таблица 1 – значения таймера повторной передачи

№ попытки
Время передачи	00:25:07.046486	00:25:07.250894	00:25:07.666886	00:25:08.498892	00:25:10.166898	00:25:13.502895
Значение таймера (RTO), с	0.204408	0.415992	0.832006	1.668006	3.335997	Не определено

Заключение: значение RTO после каждой попытки повторной передачи увеличивалось приблизительно в 2 раза, что соответствует рекомендуемому значению коэффициента β в формуле (1.2). Результаты эксперимента соответствуют поставленным ожиданиям.

4.2 Исследование устойчивого таймера TCP

Выполненные действия, в соответствии с поставленным алгоритмом (п. 2.2), и результаты исследования, включая подробные комментарии, приведены в листинге 4.

Листинг 4 – исследование устойчивого таймера

//Запускаем сервер. Параметр –P устанавливает ожидание в 40000мс = 40с

anton@ubuntu:~$ sock -is -P40000 1111

//Запускаем клиент. Параметр –n устанавливает количество передаваемых //сообщений равным 100, по –w4096 байт

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ sock -i -n100 -w4096 192.168.1.2 1111

//Запускаем утилиту tcpdump

anton@anton-HP-Pavilion-dv6-Notebook-PC ~ $ sudo tcpdump tcp -i wlan0 -vv

tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes

// Анализируем передачу пакетов

//установка соединения

01:50:11.328309 IP (tos 0x0, ttl 64, id 26858, offset 0, flags [DF], proto TCP (6), length 60)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [S], cksum 0x8384 (incorrect -> 0xe7b1), seq 842922990, win 14600, options [mss 1460,sackOK,TS val 4952836 ecr 0,nop,wscale 4], length 0

01:50:11.328960 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [S.], cksum 0x7e49 (correct), seq 2397248668, ack 842922991, win 5792, options [mss 1460,sackOK,TS val 1892385 ecr 4952836,nop,wscale 6], length 0

01:50:11.329002 IP (tos 0x0, ttl 64, id 26859, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xc023), seq 1, ack 1, win 913, options [nop,nop,TS val 4952836 ecr 1892385], length 0

//посылается первый пакет

01:50:11.329532 IP (tos 0x0, ttl 64, id 26863, offset 0, flags [DF], proto TCP (6), length 1500)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0xebe0 (correct), seq 4097:5545, ack 1, win 913, options [nop,nop,TS val 4952836 ecr 1892385], length 1448

//Сервер присылает подтверждение и сообщает клиенту, что размер его окна

//win = 0

01:50:11.663562 IP (tos 0x0, ttl 64, id 64719, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xb453 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1892469 ecr 4952920], length 0

//Далее, в течении 40 секунд сервер находится в режиме ожидания

//Клиент в это время посылает пробы окна серверу

01:50:11.878868 IP (tos 0x0, ttl 64, id 26910, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xb08d), seq 69304, ack 1, win 913, options [nop,nop,TS val 4952974 ecr 1892469], length 0

01:50:11.879894 IP (tos 0x0, ttl 64, id 64720, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xb41d (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1892523 ecr 4952920], length 0

01:50:12.310871 IP (tos 0x0, ttl 64, id 26911, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xafeb), seq 69304, ack 1, win 913, options [nop,nop,TS val 4953082 ecr 1892523], length 0

01:50:12.311411 IP (tos 0x0, ttl 64, id 64721, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xb3b2 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1892630 ecr 4952920], length 0

01:50:13.174888 IP (tos 0x0, ttl 64, id 26912, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xaea8), seq 69304, ack 1, win 913, options [nop,nop,TS val 4953298 ecr 1892630], length 0

01:50:13.175479 IP (tos 0x0, ttl 64, id 64722, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xb2d9 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1892847 ecr 4952920], length 0

01:50:14.906882 IP (tos 0x0, ttl 64, id 26913, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xac1e), seq 69304, ack 1, win 913, options [nop,nop,TS val 4953731 ecr 1892847], length 0

01:50:14.907657 IP (tos 0x0, ttl 64, id 64723, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xb128 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1893280 ecr 4952920], length 0

01:50:18.366898 IP (tos 0x0, ttl 64, id 26914, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0xa70c), seq 69304, ack 1, win 913, options [nop,nop,TS val 4954596 ecr 1893280], length 0

01:50:18.367452 IP (tos 0x0, ttl 64, id 64724, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xadc7 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1894145 ecr 4952920], length 0

01:50:25.294877 IP (tos 0x0, ttl 64, id 26915, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0x9ce7), seq 69304, ack 1, win 913, options [nop,nop,TS val 4956328 ecr 1894145], length 0

01:50:25.295442 IP (tos 0x0, ttl 64, id 64725, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0xa703 (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1895877 ecr 4952920], length 0

01:50:39.150913 IP (tos 0x0, ttl 64, id 26916, offset 0, flags [DF], proto TCP (6), length 52)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0x837c (incorrect -> 0x889b), seq 69304, ack 1, win 913, options [nop,nop,TS val 4959792 ecr 1895877], length 0

01:50:39.151507 IP (tos 0x0, ttl 64, id 64726, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0x997b (correct), seq 1, ack 69305, win 0, options [nop,nop,TS val 1899341 ecr 4952920], length 0

//прошло 40 секунд и сервер открывает окно win = 34

01:50:51.373706 IP (tos 0x0, ttl 64, id 64727, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0x8d6a (correct), seq 1, ack 69305, win 34, options [nop,nop,TS val 1902396 ecr 4952920], length 0

//Далее идёт отправка данных на сервер (показаны только первые 3 пакета)

01:50:51.373756 IP (tos 0x0, ttl 64, id 26917, offset 0, flags [DF], proto TCP (6), length 1372)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [P.], cksum 0xffaa (correct), seq 69305:70625, ack 1, win 913, options [nop,nop,TS val 4962847 ecr 1902396], length 1320

01:50:51.373928 IP (tos 0x0, ttl 64, id 64728, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0x8d41 (correct), seq 1, ack 69305, win 75, options [nop,nop,TS val 1902396 ecr 4952920], length 0

01:50:51.373943 IP (tos 0x0, ttl 64, id 26918, offset 0, flags [DF], proto TCP (6), length 1500)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0xb4e4 (correct), seq 70625:72073, ack 1, win 913, options [nop,nop,TS val 4962847 ecr 1902396], length 1448

01:50:51.374065 IP (tos 0x0, ttl 64, id 26919, offset 0, flags [DF], proto TCP (6), length 1500)

anton-HP-Pavilion-dv6-Notebook-PC.local.56864 > ubuntu.local.1111: Flags [.], cksum 0xd503 (correct), seq 72073:73521, ack 1, win 913, options [nop,nop,TS val 4962847 ecr 1902396], length 1448

01:50:51.374198 IP (tos 0x0, ttl 64, id 64729, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.56864: Flags [.], cksum 0x8cef (correct), seq 1, ack 69305, win 157, options [nop,nop,TS val 1902396 ecr 4952920], length 0

Заключение: в таблице 2 показаны расчеты значения устойчивого таймера в моменты отправки проб окна сервера.

Таблица 2 – значения устойчивого таймера

№ пробы
Время отправки пробы окна	01:50:11.878868	01:50:12.310871	01:50:13.174888	01:50:14.906882	01:50:18.366898	01:50:25.294877
Значение таймера, с	0.432003	0.864017	1.731994	3.460016	6.927979	13.856036

Как видно из таблицы 2, устойчивый таймер, после каждой пробы окна, увеличивается почти в 2 раза, неравенство коэффициента увеличена двум объясняется тем, что время тратится на доставку пакета. Результаты эксперимента удовлетворяют ожидаемым результатам.

4.3 Исследование таймера "оставайся в живых"

Выполненные действия, в соответствии с поставленным алгоритмом (п. 2.3), и результаты исследования, включая подробные комментарии, приведе-ны в листинге 5.

Листинг 5 – Исследование таймера "оставайся в живых"

//запускаем сервер. Параметр –К включает опцию "оставайся в живых"

anton@ubuntu:~$ sock -K -s -v 1111

//Клиент подключился

connection on 192.168.1.2.1111 from 192.168.1.3.57341

TCP_MAXSEG = 1448

now 02:56:00

hello client

lets start

//Больше сообщений не отсылаем

//в 08:02:16 отключили сетевой кабель от сервера

//спустя около 3 часов вернулись к машине и увидели

//ошибку которая показывает, что клиент не подтвердил запрос "оставайся в //живых"

read error: Connection timed out

//Включаем клиент

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ sock -v 192.168.1.2 1111

//подключились к серверу

connected on 192.168.1.3.57341 to 192.168.1.2.1111

TCP_MAXSEG = 1448

//обмениваемся сообщениями

now 02:56:00

hello client

lets start

//т.к. опция –К не была включена, то клиент не будет проверять состояние //сервера

//Включаем tcpdump
//Обмен сообщениями

02:56:31.883954 IP (tos 0x0, ttl 64, id 41779, offset 0, flags [DF], proto TCP (6), length 65)

anton-HP-Pavilion-dv6-Notebook-PC.local.57341 > ubuntu.local.1111: Flags [P.], cksum 0x778d (correct), seq 3042185411:3042185424, ack 162283466, win 913, options [nop,nop,TS val 5947975 ecr 2883874], length 13

02:56:31.884581 IP (tos 0x0, ttl 64, id 16104, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.57341: Flags [.], cksum 0x2cd9 (correct), seq 1, ack 13, win 91, options [nop,nop,TS val 2887542 ecr 5947975], length 0

02:58:45.958056 IP (tos 0x0, ttl 64, id 41781, offset 0, flags [DF], proto TCP (6), length 63)

anton-HP-Pavilion-dv6-Notebook-PC.local.57341 > ubuntu.local.1111: Flags [P.], cksum 0xacfd (correct), seq 13:24, ack 14, win 913, options [nop,nop,TS val 5981493 ecr 2889451], length 11

//обратить внимание на время отправки последнего сообщения

02:58:45.958931 IP (tos 0x0, ttl 64, id 16106, offset 0, flags [DF], proto TCP (6), length 52)

ubuntu.local.1111 > anton-HP-Pavilion-dv6-Notebook-PC.local.57341: Flags [.], cksum 0x26e2 (correct), seq 14, ack 24, win 91, options [nop,nop,TS val 2921062 ecr 5981493], length 0

//через 2 часа запрос "оставайся в живых"

04:58:50.824099 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has anton-HP-Pavilion-dv6-Notebook-PC.local tell ubuntu.local, length 28

04:58:50.824127 ARP, Ethernet (len 6), IPv4 (len 4), Reply anton-HP-Pavilion-dv6-Notebook-PC.local is-at cc:52:af:60:f8:65 (oui Unknown), length 28

//прошло ещё 2 часа. запрос "оставайся в живых"

06:58:50.688502 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has anton-HP-Pavilion-dv6-Notebook-PC.local tell ubuntu.local, length 28

06:58:50.688525 ARP, Ethernet (len 6), IPv4 (len 4), Reply anton-HP-Pavilion-dv6-Notebook-PC.local is-at cc:52:af:60:f8:65 (oui Unknown), length 28

//Больше запросов "оставайся в живых" не наблюдалось, т.к. tcpdump был //запущен на стороне клиента

Заключение: Результат эксперимента удовлетворяет ожидаемому результату.

4.4 Исследование таймера 2MSL

Выполненные действия, в соответствии с поставленным алгоритмом (п. 2.4), и результаты исследования, включая подробные комментарии, приведе-ны в листинге 6.

Листинг 6 – исследование таймера 2MSL

//Запускаем сервер

anton@ubuntu:~$ sock -v -s 1111

//клиент подключился

connection on 192.168.1.2.1111 from 192.168.1.3.57311

TCP_MAXSEG = 1448

//Отключаем сервер командой Ctrl+C

^C time 00:00:00:00
//делаем попытки запустить сервер на том же порту, на котором он работал до //отлючения

anton@ubuntu:~$ sock -v -s 1111 time 00:00:04:55

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:10:32

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:14:41

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:19:85

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:26:14

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:31:98

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:38:02

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:44:75

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:47:45

can't bind local address: Address already in use

anton@ubuntu:~$ sock -v -s 1111 time 00:00:52:51

can't bind local address: Address already in use

//сервер запустился

anton@ubuntu:~$ sock -v -s 1111 time 00:01:01:31

connection on 192.168.1.2.1111 from 192.168.1.3.57313

TCP_MAXSEG = 1448

//запускаем клиент

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ sock -v 192.168.1.2 1111

//клиент подключился к серверу

connected on 192.168.1.3.57311 to 192.168.1.2.1111

TCP_MAXSEG = 1448

//соединение прервано из-за выключения сервера

connection closed by peer

//запускаем сервер заново

anton@ubuntu:~$ sock -v -s 1111

//клиент подключился

connection on 192.168.1.2.1111 from 192.168.1.3.57311

TCP_MAXSEG = 1448

//клиент отключился

connection closed by peer

//Запускаем клиент

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ sock -b57313 -v 192.168.1.2 1111

//клиент подключился к серверу. Порт клиента 57313

connected on 192.168.1.3.57313 to 192.168.1.2.1111

TCP_MAXSEG = 1448

//отключаем клиент

^C time 00:00:00:00

//запускаем клиент заново на 57313 порту

anton@anton-HP-Pavilion-dv6-Notebook-PC ~/TCPIP_Chat $ sock -b57313 -v 192.168.1.2 1111 time 00:00:08:05