У сервера TCP всегда есть простой доступ ко всем четырем фрагментам информации для присоединенного сокета, и эти четыре значения остаются постоянными в течение всего времени жизни соединения. Однако в случае соединения UDP IP-адрес получателя можно получить только с помощью установки параметра сокета
IP_RECVDSTADDR
для IPv4 или
IPV6_PKTINFO
для IPv6 и последующего вызова функции
recvmsg
вместо функции
recvfrom
. Поскольку протокол UDP не ориентирован на установление соединения, IP-адрес получателя может меняться для каждой дейтаграммы, отправляемой серверу. Сервер UDP может также получать дейтаграммы, предназначенные для одного из широковещательных адресов узла или для адреса многоадресной передачи, что мы обсуждаем в главах 20 и 21. Мы покажем, как определить адрес получателя дейтаграммы UDP, в разделе 20.2, после того как опишем функцию
recvmsg
.
8.11. Функция connect для UDP
В конце разделе 8.9 мы упомянули, что асинхронные ошибки не возвращаются на сокете UDP, если сокет не был присоединен. На самом деле мы можем вызвать функцию
connect
для сокета UDP (см. раздел 4.3). Но это не приведет ни к чему похожему на соединение TCP: здесь не существует трехэтапного рукопожатия. Ядро просто проверяет, нет ли сведений о заведомой недоступности адресата, после чего записывает IP-адрес и номер порта собеседника, которые содержатся в структуре адреса сокета, передаваемой функции connect, и немедленно возвращает управление вызывающему процессу.
ПРИМЕЧАНИЕ
Перегрузка функции connect этой новой возможностью для сокетов UDP может внести путаницу. Если используется соглашение о том, что sockname — это адрес локального протокола, a peername — адрес удаленного протокола, то лучше бы эта функция называлась setpeername. Аналогично, функции bind больше подошло бы название setsockname.
С учетом этого необходимо понимать разницу между двумя видами сокетов UDP.
■ Неприсоединенный (unconnected) сокет UDP — это сокет UDP, создаваемый по умолчанию.
■ Присоединенный {connected) сокет UDP — результат вызова функции connect для сокета UDP.
Присоединенному сокету UDP свойственны три отличия от неприсоединенного сокета, который создается по умолчанию.
1. Мы больше не можем задавать IP-адрес получателя и порт для операции вывода. То есть мы используем вместо функции
sendto
функцию
write
или
send
. Все, что записывается в присоединенный сокет UDP, автоматически отправляется на адрес (например, IP-адрес и порт), заданный функцией
connect
.
ПРИМЕЧАНИЕ
Аналогично TCP, мы можем вызвать функцию sendto для присоединенного сокета UDP, но не можем задать адрес получателя. Пятый аргумент функции sendto (указатель на структуру адреса сокета) должен быть пустым указателем, а шестой аргумент (размер структуры адреса сокета) должен быть нулевым. В стандарте POSIX определено, что когда пятый аргумент является пустым указателем, шестой аргумент игнорируется.
2. Вместо функции
recvfrom
мы используем функцию
read
или
recv
. Единственные дейтаграммы, возвращаемые ядром для операции ввода через присоединенный сокет UDP, — это дейтаграммы, приходящие с адреса, заданного в функции
connect
. Дейтаграммы, предназначенные для адреса локального протокола присоединенного сокета UDP (например, IP-адрес и порт), но приходящие с адреса протокола, отличного от того, к которому сокет был присоединен с помощью функции
connect
, не передаются присоединенному сокету. Это ограничивает присоединенный сокет UDP, позволяя ему обмениваться дейтаграммами с одним и только одним собеседником.
ПРИМЕЧАНИЕ
Точнее, обмен дейтаграммами происходит только с одним IP-адресом, а не с одним собеседником, поскольку это может быть IP-адрес многоадресной передачи, представляющий, таким образом, группу собеседников.
3. Асинхронные ошибки возвращаются процессу только при операциях с присоединенным сокетом UDP. В результате, как мы уже говорили, неприсоединенный сокет UDP не получает никаких асинхронных ошибок.
В табл. 8.2 сводятся воедино свойства, перечисленные в первом пункте, применительно к 4.4BSD.
Таблица 8.2. Сокеты TCP и UDP: может ли быть задан адрес протокола получателя
| Тип сокета | write или send | sendto, без указания получателя | sendto, с указанием получателя |
| Сокет TCP | Да | Да | EISCONN |
| Сокет UDP, присоединенный | Да | Да | EISCONN |
| Сокет UDP, неприсоединенный | EDESTADDRREQ | EDESTADDRREQ | Да |
ПРИМЕЧАНИЕ
POSIX определяет, что операция вывода, не задающая адрес получателя на неприсоединенном сокете UDP, должна возвращать ошибку ENOTCONN, а не EDESTADDRREQ.
Solaris 2.5 допускает функцию sendto, которая задает адрес получателя для присоединенного сокета UDP. POSIX определяет, что в такой ситуации должна возвращаться ошибка EISCONN.
На рис. 8.7 обобщается информация о присоединенном сокете UDP.
Рис. 8.7. Присоединенный сокет UDP
Приложение вызывает функцию
connect
, задавая IP-адрес и номер порта собеседника. Затем оно использует функции
read
и
write
для обмена данными с собеседником.
Дейтаграммы, приходящие с любого другого IP-адреса или порта (который мы обозначаем как «???» на рис. 8.7), не передаются на присоединенный сокет, поскольку либо IP-адрес, либо UDP-порт отправителя не совпадают с адресом протокола, с которым сокет соединяется с помощью функции
connect
. Эти дейтаграммы могут быть доставлены на какой-то другой сокет UDP на узле. Если нет другого совпадающего сокета для приходящей дейтаграммы, UDP проигнорирует ее и сгенерирует ICMP-сообщение о недоступности порта.
Обобщая вышесказанное, мы можем утверждать, что клиент или сервер UDP может вызвать функцию
connect
, только если этот процесс использует сокет UDP для связи лишь с одним собеседником. Обычно именно клиент UDP вызывает функцию
connect
, но существуют приложения, в которых сервер UDP связывается с одним клиентом на длительное время (например, TFTP), и в этом случае и клиент, и сервер вызывают функцию
connect
.
Еще один пример долгосрочного взаимодействия — это DNS (рис. 8.8).
