5.7. В предположении, что узел сервера поддерживает модель системы с гибкой привязкой(см. раздел 8.8), все будет работать. Узел сервера примет IP-дейтаграмму (которая в данном случае содержит TCP-сегмент), прибывшую на самый левый канал, даже если IP-адрес получателя является адресом самого правого канала. Это можно проверить, если запустить наш сервер на узле
linux
(см. рис. 1.7), а затем запустить клиент на узле
solaris
, но на стороне клиента задать другой IP-адрес сервера (206.168.112.96). После установления соединения, запустив на стороне сервера программу
netstat
, мы увидим, что локальный IP-адрес является IP-адресом получателя из клиентского сегмента SYN, а не IP-адресом канала, на который прибыл сегмент SYN (как отмечалось в разделе 4.4).
5.8. Наш клиент был запущен в системе Intel с прямым порядком байтов, где 32-разрядное целое со значением 1 хранится так, как показано на рис. Д.1.
Рис. Д.1. Представление 32-разрядного целого числа 1 в формате прямого порядка байтов
Четыре байта посылаются на сокет в следующем порядке: A, A + 1, A + 2 и A + 3, и там хранятся в формате обратного порядка байтов, как показано на рис. Д.2.
Рис. Д.2. Представление 32-разрядного целого числа с рис. Д.1 в формате обратного порядка байтов
Значение
0x01000000
интерпретируется
как 16 777 216. Аналогично, целое число 2, отправленное клиентом, интерпретируется сервером как
0x02000000
, или 33 554 432. Сумма этих двух целых чисел равна 50 331 648, или
0x03000000
. Когда это значение, записанное в обратном порядке байтов, отправляется клиенту, оно интерпретируется клиентом как целое число 3.
Но 32-разрядное целое число -22 представляется в системе с прямым порядком байтов так, как показано на рис. Д.3 (мы предполагаем, что используется поразрядное дополнение до двух для отрицательных чисел).
Рис. Д.3. Представление 32-разрядного целого числа -22 в формате прямого порядка байтов
В системе с обратным порядком байтов это значение интерпретируется как
0xeaffffff
, или -352 521 537. Аналогично, представление числа -77 в прямом порядке байтов выглядит как
0xffffffb3
, но в системах с обратным порядком оно представляется как
0xb3ffffff
, или -1 275 068 417. Сложение, выполняемое сервером, приводит к результату
0x9efffffe
, или -1 627 389 954. Полученное значение в обратном порядке байтов посылается через сокет клиенту, где в прямом порядке байтов оно интерпретируется как
0xfeffff9e
, или -16 777 314 — это то значение, которое выводится в нашем примере.
5.9. Метод правильный (преобразование двоичных значений в сетевой порядок байтов), но нельзя использовать функции
htonl
и
ntohl
. Хотя символ
l
в названиях данных функций обозначает «long», эти функции работают с 32-разрядными целыми (раздел 3.4). В 64-разрядных системах
long
занимает 64 бита, и эти две функции работают некорректно. Для решения этой проблемы следует определить две новые функции
hton64
и
ntoh64
, но они не будут работать в системах, представляющих значения типа
long
32 битами.
5.10. В первом сценарии сервер будет навсегда блокирован при вызове функции
readn
в листинге 5.14, поскольку клиент посылает два 32-разрядных значения, а сервер ждет два 64-разрядных значения. В случае, если клиент и сервер поменяются узлами, клиент будет посылать два 64-разрядных значения, а сервер считает только первые 64 бита, интерпретируя их как два 32-разрядных значения. Второе 64-разрядное значение останется в приемном буфере сокета сервера. Сервер отправит обратно 32-разрядное значение, и клиент навсегда заблокируется в вызове функции
readn
в листинге 5.13, поскольку будет ждать для считывания 64-разрядное значение.
5.11. Функция IP-маршрутизации просматривает IP-адрес получателя (IP-адрес сервера) и пытается по таблице маршрутизации определить исходящий интерфейс и следующий маршрутизатор (см. главу 9 [111]). В качестве адреса отправителя используется первичный IP-адрес исходящего интерфейса, если сокет еще не связан с локальным IP-адресом.
Глава 6
6.1. Массив целых чисел содержится внутри структуры, а язык С позволяет использовать со структурами оператор присваивания.