Читать онлайн «UNIX: разработка сетевых приложений». Страница 258

11.8. Сначала размещаем в памяти массивы, содержащие имя узла и имя службы:

char host[NI_MAXHOST], serv[NI_MAXSERV];

После того как функция accept возвращает управление, вызываем вместо функции sock_ntop функцию getnameinfo:

if (getnameinfo(cliaddr, len, host, NI_MAXHOST, serv, NI_MAXSERV,

 NI_NUMERICHOST | NI_NUMERICSERV) == 0)

 printf("connection from %s.%s\n", host, serv);

Поскольку мы имеем дело с сервером, определяем флаги NI_NUMERICHOST и NI_NUMERICSERV, чтобы избежать поиска в DNS и /etc/services.

11.9. Первая проблема состоит в том, что второй сервер не может связаться (bind) с тем же портом, что и первый сервер, поскольку не установлен параметр сокета SO_REUSEADDR. Простейший способ справиться с такой ситуацией — создать копию функции udp_server, переименовать ее в udp_server_reuseaddr, сделать так, чтобы она установила параметр сокета, и вызывать ее в сервере.

11.10. Когда клиент выводит Trying 206.62.226.35..., функция gethostname возвращает IP-адрес. Пауза перед этим выводом означает, что распознаватель ищет имя узла. Вывод Connected to bsdi.unpbook.com. значит, что функция connect возвратила управление. Пауза между этими двумя выводами говорит о том, что функция connect пытается установить соединение.

12.1. Далее приведен сокращенный листинг. Обратите внимание, что клиент FTP в системе freebsd всегда пытается использовать команду EPRT (независимо от версии IP), но если это не срабатывает, то он пробует команду PORT.

freebsd % ftp aix-4

Connected to aix-4.unpbook.com.

220 aix FTP server ...

...

230 Guest login ok. access restrictions apply.

ftp> debug

Debugging on (debug=1).

ftp> passive

Passive mode: off; fallback to active mode= off

ftp> dir

---> EPRT |1|192 168.42.1|50484|

500 'EPRT |1|192.168.42.1|50484|' command not understood.

disabling epsv4 for this connection

---> PORT 192.168.42.1.197.52

200 PORT command successful.

---> LIST

150 Opening ASCII mode data connection for /bin/ls

...

freebsd % ftp ftp.kame.net

Trying 2001.200:0:4819:203:47ff:fea5:3085...

Connected to orange.kame.net.

220 orange.kame.net FTP server ...

...

230 Guest login ok. access restrictions apply.

ftp> debug

Debugging on (debug=1).

ftp> passive

Passive mode: off; fallback to active mode: off.

ftp> dir

---> EPRT |2|3ffe:b80:3:9ad1::2|50480|

200 EPRT command successful

---> LIST

150 Opening ASCII mode data connection for '/bin/ls'.

13.1. Все сообщения об ошибках, даже ошибка загрузки, такая как неправильный аргумент командной строки, должны сохраняться в файлах журнала с помощью функции syslog.

13.2. TCP-версии серверов echo, discard и chargen запускаются как дочерние процессы, после того как демон inetd вызовет функцию fork, поскольку эти три сервера работают, пока клиент не прервет соединение. Два других TCP-сервера, time и daytime, не требуют использования функции fork, поскольку эти службы легко реализовать (получить текущую дату, преобразовать ее, записать и закрыть соединение). Эти два сервера обрабатываются непосредственно демоном inetd. Все пять UDP-служб обрабатываются без использования функции fork, поскольку каждая из них генерирует единственную дейтаграмму в ответ на клиентскую дейтаграмму, которая запускает эту службу. Эти пять служб обрабатываются напрямую демоном inetd.

13.3. Это известная атака типа «отказ в обслуживании» [18]. Первая дейтаграмма с порта 7 заставляет сервер chargen отправить дейтаграмму обратно на порт 7. На эту дейтаграмму приходит эхо-ответ, и серверу chargen посылается другая дейтаграмма. Происходит зацикливание. Одним из решений, реализованным в системе BSD/OS, является игнорирование дейтаграмм, направленных любому внутреннему серверу, если номер порта отправителя пришедшей дейтаграммы принадлежит одному из внутренних серверов. Другим решением может быть запрещение этих внутренних служб — либо с помощью демона inetd на каждом узле, либо на маршрутизаторе, связывающем внутреннюю сеть организации с Интернетом.

13.4. IP-адрес и номер порта клиента могут быть получены из структуры адреса сокета, заполняемой функцией accept.

Причина, по которой демон inetd не делает этого для UDP-сокета, состоит в том, что чтение дейтаграмм (recvfrom) осуществляется с помощью функции exec сервером, а не самим демоном inetd.

Демон inetd может считать дейтаграмму с флагом MSG_PEEK (см. раздел 14.7), только чтобы получить IP-адрес и номер порта клиента, но оставляет саму дейтаграмму для чтения серверу.

14.1. Если не установлен обработчик, первый вызов функции signal будет возвращать значение SIG_DFL, а вызов функции signal для восстановления обработчика просто вернет его в исходное состояние.

14.3. Приведем цикл for:

for (;;) {

 if ((n = Recv(sockfd, recvline, MAXLINE, MSG_PEEK)) == 0)

  break; /* сервер закрыл соединение */

 Ioctl(sockfd, FIONREAD, &npend);

 printf("%d bytes from PEEK, %d bytes pending\n", n, npend);

 n = Read(sockfd, recvline, MAXLINE);

 recvline[n] = 0; /* завершающий нуль */

 Fputs(recvline, stdout);

}

14.4. Данные продолжают выводиться, поскольку выход из функции main — это то же самое, что и возврат из этой функции. Функция main вызывается программой запуска на языке С следующим образом:

exit(main(argc, argv));

Следовательно, вызывается функция exit, а затем и программа очистки стандартного ввода-вывода.

15.1. Функция unlink удаляет имя файла из файловой системы, и когда клиент позже вызовет функцию connect, она не выполнится. Это не влияет на прослушиваемый сокет сервера, но клиенты не смогут выполнить функции connect после вызова функции unlink.

15.2. Клиент не сможет соединиться с сервером с помощью функции connect, даже если полное имя существует, поскольку для успешного соединения с помощью функции connect доменный сокет Unix должен быть открыт и связан с этим полным именем (см. раздел 15.4).

15.3. При выводе адреса протокола клиента путем вызова функции sock_ntop мы получим сообщение datagram from (no pathname bound) (дейтаграмма от (имя не задано)), поскольку по умолчанию с сокетом клиента не связывается никакое имя.

Одним из решений является проверить доменный сокет Unix в функциях udp_client и udp_connect и связать с сокетом при помощи функции bind временное полное имя. Это приведет к зависимости от протокола в библиотечной функции, но не в нашем приложении.

15.4. Даже если мы заставим сервер вернуть в функции write 1 байт на его 26- байтовый ответ, использование функции sleep на стороне клиента гарантирует, что все 26 сегментов будут получены до вызова функции read, в результате чего функция read вернет полный ответ. Это еще одно подтверждение того, что TCP является потоком байтов с отсутствием границ записей.

Чтобы использовать доменные протоколы Unix, запускаем клиент и сервер с двумя аргументами командной строки /lосаl (или /unix) и /tmp/daytime (или любое другое временное имя, которое вы хотите использовать). Ничего не изменится: 26 байт будут возвращаться функцией read каждый раз, когда будет запускаться клиент.

Поскольку для каждой функции send сервер определяет флаг MSG_EOR, каждый байт рассматривается как логическая запись, и функция read при каждом вызове возвращает 1 байт. Причина в том, что Беркли-реализации поддерживают флаг MSG_EOR по умолчанию. Однако этот факт не документирован и не может использоваться в серийном коде. В данном примере мы используем эту особенность, чтобы показать разницу между потоком байтов и ориентированным на записи протоколом. С точки зрения реализации, каждая операция вывода идет в mbuf (буфер памяти) и флаг MSG_EOR сохраняется ядром вместе с mbuf, когда mbuf переходит из отправляющего сокета в приемный буфер принимающего сокета. Когда вызывается функция read, флаг MSG_EOR все еще присоединен к каждому mbuf, так что основная подпрограмма ядра read (поддерживающая флаг MSG_EOR, поскольку некоторые протоколы используют этот флаг) сама возвращает каждый байт. Если бы вместо read мы использовали recvmsg, флаг MSG_EOR возвращался бы в поле msg_flags каждый раз, когда recvmsg возвращала бы 1 байт. Такой подход в TCP не срабатывает, поскольку отправляющий TCP не анализирует флаг MSG_EOR в отсылаемом mbuf и в любом случае у нас нет возможности передать этот флаг принимающему TCP в TCP-заголовке. (Выражаем благодарность Мату Томасу (Matt Thomas) за то, что он указал нам это недокументированное «средство».)