Уильям Стивенс - UNIX: разработка сетевых приложений
Листинг 10.7. Сервер, закрывающий ассоциацию после отправки ответа
//sctp/sctpserv03.c
25 for (;;) {
26 len = sizeof(struct sockaddr_in);
27 rd_sz = Sctp_recvmsg(sock_fd, readbuf, sizeof(readbuf),
28 (SA*)&cliaddr, &len, &sri, &msg_flags);
29 if (stream_increment) {
30 sri.sinfo_stream++;
31 if (sri.sinfo_stream >=
32 sctp_get_no_strms(sock_fd, (SA*)&cliaddr, len))
33 sri.sinfo_stream = 0;
34 }
35 Sctp_sendmsg(sock_fd, readbuf, rd_sz,
36 (SA*)&cliaddr, len,
37 sri.sinfo_ppid,
38 (sri.sinfo_flags | MSG_EOF), sri.sinfo_stream, 0, 0);
39 }
Отправка ответа с закрытием ассоциации38 Изменение кода сервера состоит в том, что мы добавляем флаг MSG_EOF к прочим флагам в вызове sctp_sendmsg операцией логического ИЛИ. Благодаря этому сервер закрывает ассоциацию после подтверждения доставки сообщения.
Листинг 10.8. Клиент, выполняющий аварийное закрытие ассоциации
//sctp/sctpclient02.c
25 if (echo_to_all == 0)
26 sctpstr_cli(stdin, sock_fd, (SA*)&servaddr, sizeof(servaddr));
27 else
28 sctpstr_cli_echoall(stdin, sock_fd, (SA*)&servaddr,
29 sizeof(servaddr));
30 strcpy(byemsg, "goodbye");
31 Sctp_sendmsg(sock_fd, byemsg, strlen(byemsg),
32 (SA*)&servaddr, sizeof(servaddr), 0, MSG_ABORT, 0, 0, 0);
33 Close(sock_fd);
Аварийное закрытие ассоциации30-32 Клиент подготавливает сообщение об аварийном закрытии ассоциации, вызванном пользовательской ошибкой. Затем функция sctp_sendmsg вызывается с флагом MSG_ABORT. При этом отправляется порция данных ABORT, что приводит к немедленному закрытию ассоциации. В порцию данных включается код пользовательской ошибки и сообщение («goodbye») в поле причины ошибки вышележащего уровня.
Закрытие дескриптора сокета33 Хотя ассоциация и была завершена, дескриптор сокета все равно закрыть нужно, чтобы освободить связанные с ним системные ресурсы.
10.8. Резюме
Мы изучили простой пример клиента и сервера SCTP общим объемом около 150 строк кода. Обе программы работали с сокетами SCTP типа «один-ко-многим». Сервер был написан в последовательном стиле, который часто используется при работе с такими сокетами. Он считывал сообщения и отвечал на них по тому же потоку, из которого они приходили, или по потоку с увеличенным на единицу номером. Затем мы исследовали проблему блокирования очереди, изменив программу клиента таким образом, чтобы подчеркнуть особенности ситуации и продемонстрировать использование потоков SCTP для решения проблемы. После этого мы показали, каким образом можно изменить количество потоков при помощи одного из множества параметров сокета, используемых для управления поведением SCTP. Наконец, мы снова изменили код сервера и клиента, чтобы показать корректное и аварийное закрытие ассоциации.
Углубленное исследование SCTP будет проведено в главе 23.
Упражнения
1. Что произойдет с программой в листинге 10.1, если SCTP вернет сообщение об ошибке? Каким образом вы можете устранить указанный недостаток программы?
2. Что произойдет, если сервер завершит работу, не ответив на сообщения? Может ли клиент каким-либо образом получить уведомление об этом событии?
3. В листинге 10.7 в строке 22 аргумент out_sz устанавливается равным 800 байт. Как вы думаете, почему мы выбрали именно это значение? Существует ли лучший способ найти оптимальное значение этого аргумента?
4. Как повлияет алгоритм Нагла (см. раздел 7.10) на нашего клиента из листинга 10.7? Не лучше ли будет отключить алгоритм Нагла для этой программы? Воплотите это изменение в код клиента и сервера.
5. В разделе 10.6 мы утверждали, что приложению следует изменять количество потоков до установки ассоциации. Что произойдет в противном случае?
6. Когда мы говорили о количестве потоков, мы подчеркнули, что только для сокетов типа «один-ко-многим» можно увеличить количество потоков при помощи вспомогательных данных. Почему это так? (Подсказка: вспомогательные данные необходимо передавать с сообщениями.)
7. Почему сервер может не отслеживать открытые ассоциации? Опасно ли это?
8. В разделе 10.7 мы изменили сервер так, что он стал закрывать ассоциацию после отправки каждого сообщения. Вызовет ли это какие-либо проблемы? Хорошее ли это решение с точки зрения архитектуры приложения?
Глава 11
Преобразования имен и адресов
11.1. Введение
Во всех предшествующих примерах мы использовали численные адреса узлов (например, 206.6.226.33) и численные номера портов для идентификации серверов (например, порт 13 для стандартного сервера времени и даты и порт 9877 для нашего эхо-сервера). Однако по ряду соображений предпочтительнее использовать имена вместо чисел: во-первых, имена проще запоминаются, во-вторых, если численный адрес поменяется, имя можно сохранить, и в-третьих, с переходом на IPv6 численные адреса становятся значительно длиннее, что увеличивает вероятность ошибки при вводе адреса вручную. В этой главе описываются функции, выполняющие преобразование имен и адресов: gethostbyname и gethostbyaddr для преобразования имен узлов и IP-адресов, и getservbyname и getservbyport для преобразования имен служб и номеров портов. Здесь же мы рассмотрим две независимые от протоколов функции getaddrinfo и getnameinfo, осуществляющие преобразование между IP-адресами и именами узлов, а также между именами служб и номерами портов.
11.2. Система доменных имен
Система доменных имен (Domain Name System, DNS) используется прежде всего для сопоставления имен узлов и IP-адресов. Имя узла может быть либо простым (simple name), таким как solaris или bsdi, либо полным доменным именем (fully qualified domain name, FQDN), например solaris.unpbook.com..
ПРИМЕЧАНИЕВ техническом отношении FQDN может также называться абсолютным именем и должно оканчиваться точкой, но пользователи часто игнорируют точку в конце. Точка сообщает распознавателю о том, что имя является абсолютным и не требует проведения поиска но различным доменам верхних уровней.
В этом разделе мы рассмотрим только основы DNS, необходимые нам для сетевого программирования. Читатели, интересующиеся более подробным изложением вопроса, могут обратиться к главе 14 [111] и к [1]. Дополнения, требуемые для IPv6, изложены в RFC 1886 [121].
Записи ресурсов
Записи в DNS называются записями ресурсов (resource records, RR). Нас интересуют только несколько типов RR.
■ А. Запись типа А преобразует имя узла в 32-разрядный адрес IPv4. Вот, например, четыре записи DNS для узла freebsd в домене unpbook.com, первая из которых — это запись типа А:
freebsd IN А 12.106.32.254
IN AAAA 3ffe:b80:1f8d:1:a00:20ff:fea7:686b
IN MX 5 freebsd.unpbook.com.
IN MX 10 mailhost.unpbook.com.
■ AAAA. Запись типа AAAA, называемая «четыре А» (quad А), преобразует имя узла в 128-разрядный адрес IPv6. Название «четыре А» объясняется тем, что 128-разрядный адрес в четыре раза больше 32-разрядного адреса.
■ PTR. Запись PTR (pointer records — запись указателя) преобразует IP-адрес в имя узла. Четыре байта адреса IPv4 располагаются в обратном порядке. Каждый байт преобразуется в десятичное значение ASCII (0-255), а затем добавляется in-addr.arpa. Получившаяся строка используется в запросе PTR.
32 полубайта 128-разрядного адреса IPv6 также располагаются в обратном порядке. Каждый полубайт преобразуется в соответствующее шестнадцатеричное значение ASCII (0-9, a-f) и добавляется к ip6.arpa.
Например, две записи PTR для нашего узла freebsd будут выглядеть так:
254.32.106.12 in-addr.arpa
b.6.8.6.7.a.e.f.f.f.0.2.0.0.a.0.1.0.0.0.d.8.f.1.0.8.b.0.e.f.f.3.ip6.arpa
■ MX. Запись типа MX (Mail Exchange Record) определяет, что узел выступает в роли «маршрутизирующего почтового сервера» для заданного узла. В приведенном выше примере для узла solaris предоставлено две записи типа MX. Первая имеет предпочтительное значение 5, вторая — 10. Когда существует множество записей типа MX, они используются в порядке предпочтения начиная с наименьшего значения.
ПРИМЕЧАНИЕМы не используем в примерах книги записей типа MX, но упоминаем о них, потому что они широко используются в реальной жизни.
■ CNAME. Аббревиатура CNAME означает «каноническое имя» (canonical name). Обычно такие записи используются для присвоения имен распространенным службам, таким как ftp и www. При использовании имен служб вместо действительного имени узла перемещение службы на другой узел становится прозрачным (то есть незаметным для пользователя). Например, для нашего узла linux каноническими именами могут быть следующие записи:
