Приложение D. Решения и ответы на упражнения
Рисунок D.1 Количество сетей в сети NSFNET.
Пунктирная линия примерно показывает максимальное количество сетей, которое будет достигнуто к 2000 году, если продолжится экспоненциальный рост количества сетей.
Output histogram: echo reply: 1757 destination unreachable: 700 time stamp reply: 1 Input histogram: echo reply: 211 destination unreachable: 3071 source quench: 249 routing redirect: 2789 echo: 1757 #10: 21 time exceeded: 56 time stamp: 1
21 входное сообщение с типом 10 - это требования к маршрутизатору, которые не поддерживаются SunOS 4.1.1.
При использовании SNMP (рисунок 25.26) некоторые системы, как, например, Solaris 2.2, генерируют вывод netstat -s, который использует имена переменных SNMP.
Необходимо достаточно внимательно просматривать исходящий TTL, так как иногда значение отличается от ожидаемого. Это может объясняться тем, что ICMP сообщение возвращается по другому пути, нежели ушла исходящая UDP датаграмма. В этом примере, однако, существуют именно "невидимые" маршрутизаторы, которые traceroute не нашла при использовании опции свободной маршрутизации от источника.
Клиент traceroute устанавливает номер порта источника UDP в логическое ИЛИ со своим идентификатором процесса и 32768. Так как возвращенное ICMP сообщение всегда содержит первые 8 байт IP датаграммы, на которую сгенерирована ошибка (рисунок 6.9), что включает целиком UDP заголовок, этот номер порта источника возвращается в ICMP ошибке.
Клиент traceroute не может поступить подобным образом, потому что все, что возвращается в ICMP ошибке, - это UDP заголовок (рисунок 6.9), а не UDP данные. Таким образом, traceroute должна помнить, когда она посылает запрос, дождаться отклика и рассчитать разницу во времени.
Это иллюстрирует еще одно различие между Ping и Traceroute: Ping отправляет один пакет в секунду, вне зависимости от того, получены ли какие-либо отклики, тогда как Traceroute отправляет запрос и затем ожидает, придет ли отклик или будет отработан тайм-аут перед отправкой следующего запроса.
BOOTP не имеет этих проблем с откликами, так как адрес отклика это обычный IP адрес, причем маршрутизатор всегда знает, как перенаправить информацию на этот адрес. Проблема заключается в том, что RARP использует адреса только канального уровня, а маршрутизаторы обычно не знают этих значений для хостов, находящихся в других, не подключенных непосредственно, сетях.
Оно может быть уменьшено до 10 пакетов на запрос, если ACK на запрос комбинируется с откликом (глава 19, раздел "Задержанные подтверждения").
Насытить спутниковый канал можно при использовании окна большего, чем 16000 байт.
Все ACK от клиента к серверу будут задержаны: сегменты 6, 11, 13, 15, 17 и 19. Разница во времени последних пяти от сегмента 6 составляет 400,0; 600,0; 800,0; 1000,0 и 2600 миллисекунд.
Ограничение TCP заключается в том, что пара сокетов, выделенная для соединения, должна быть уникальной. Так как Rlogin сервер всегда использует один и тот же заранее известный порт (513), несколько Rlogin клиентов на данном хосте могут использовать один и тот же зарезервированный порт, только если они подсоединены к различным серверам. Клиенты Rlogin, однако, не используют эту технику повторного использования зарезервированных портов. Если эта техника используется, теоретический лимит максимального количества соединений составляет 512 Rlogin клиентов, в одно и то же время подсоединенных к одному и тому же хосту сервера.
События, осуществляемые stubом клиента, следующие: момент времени 0: отправка запроса 1; момент времени 4: тайм-аут и повторная передача запроса 1; момент времени 5: получение отклика 1 от сервера, возвращение отклика приложению; момент времени 5: отправка запроса 2; момент времени 9: тайм-аут и повторная передача запроса 2; момент времени 10: получение отклика 1 от сервера, однако он игнорируется, так как мы ожидаем отклик 2; момент времени 11: получение отклика 2 от сервера, возвращение отклика приложению.
События на сервере следующие: момент времени 0: получение запроса 1, начало операции; момент времени 5: отправка отклика 1; момент времени 5: получение запроса 1 (от повторной передачи клиента в момент времени 4), начало операции; момент времени 10: отправка отклика 1; момент времени 10: получение запроса 2 (от передачи клиента в момент времени 5), начало операции; момент времени 11: отправка отклика 2; момент времени 11: получение запроса 2 (от повторной передачи клиента в момент времени 9), начало операции; момент времени 12: отправка отклика 2. Этот последний отклик сервера просто поставлен клиентским UDP в очередь для следующего приема, осуществляемого клиентом. Когда клиент считывает его, XID будет неверен, и клиент его проигнорирует.
Подобное, когда сервер выходит из строя и перезагружается, а приложение RPC сервера получает новый динамически назначаемый порт, может возникнуть с любым RPC приложением, которое не использует заранее известный порт.