UNIX: разработка сетевых приложений
вернуться

Стивенс Уильям Ричард
Шрифт:

5 int unixfd, recvfd;

6 char c;

7 ssize_t n;

8 socklen_t len;

9 struct sockaddr_storage ss;

10 unixfd = client[i].connfd;

11 recvfd = -1;

12 if ((n = Read_fd(unixfd, &c, 1, &recvfd)) == 0) {

13 err_msg("client %d terminated, recvfd = %d", i, recvfd);

14 goto clientdone; /* вероятно, клиент завершил работу */

15 }

16 /* данные от клиента, должно быть, дескриптор */

17 if (recvfd < 0) {

18 err_msg("read_fd did not return descriptor");

19 goto clienterr;

20 }

Считывание данных клиента и, возможно, дескриптора

13-18
Вызываем функцию
read_fd
, приведенную в листинге 15.9, для считывания данных и, возможно, дескриптора. Если возвращаемое значение равно нулю, клиент закрыл свою часть соединения, вероятно, завершив свое выполнение.

ПРИМЕЧАНИЕ

При написании кода пришлось выбирать, что использовать для связи между приложением и демоном — либо потоковый доменный сокет Unix, либо дейтаграммный доменный сокет Unix. Дескриптор сокета UDP может быть передан через любой доменный сокет Unix. Причина, по которой предпочтение было отдано потоковому сокету, заключается в том, что он позволяет определить момент завершения клиента. Все дескрипторы автоматически закрываются, когда клиент завершает работу, в том числе и доменный сокет Unix, используемый для связи с демоном, в результате чего данный клиент удаляется демоном из массива client. Если бы мы использовали сокет дейтаграмм, то не узнали бы, когда клиент завершил работу.

16-20
Если клиент не закрыл соединение, ждем получения дескриптора. Вторая часть функции
readable_conn
приведена в листинге 28.28.

Листинг 28.28. Получение номера порта, который клиент связал с UDP-сокетом

//icmpd/readable_conn.c

21 len = sizeof(ss);

22 if (getsockname(recvfd, (SA*)&ss, &len) < 0) {

23 err_ret("getsockname error");

24 goto clienterr;

25 }

26 client[i].family = ss.ss_family;

27 if ((client[i].lport = sock_get_port((SA*)&ss, len)) == 0) {

28 client[i].lport = sock_bind_wild(recvfd, client[i].family);

29 if (client[i].lport <= 0) {

30 err_ret("error binding ephemeral port");

31 goto clienterr;

32 }

33 }

34 Write(unixfd, "1", 1); /* сообщение клиенту об успехе */

35 Close(recvfd); /* работа с UDP-сокетом клиента завершена */

36 return(--nready);

37 clienterr:

38 Write(unixfd, "0", 1); /* сообщение клиенту об ошибке */

39 clientdone:

40 Close(unixfd);

41 if (recvfd >= 0)

42 Close(recvfd);

43 FD_CLR(unixfd, &allset);

44 client[i].connfd = -1;

45 return(--nready);

46 }

Получение номера порта, связанного с сокетом UDP

21-25
Вызывается функция
getsockname
, так что демон может получить номер порта, связанного с сокетом. Поскольку неизвестно, каков размер буфера, необходимого для размещения структуры адреса сокета, мы используем структуру
sockaddr_storage
, которая достаточно велика для структуры адреса сокета любого поддерживаемого системой типа и обеспечивает нужное выравнивание.

26-33
Семейство адресов сокета вместе с номером порта сохраняется в структуре
client
. Если номер порта равен нулю, мы вызываем функцию
sock_bind_wild
для связывания универсального адреса и динамически назначаемого порта с сокетом, но, как отмечалось ранее, такой подход не работает в реализациях SVR4.

Сообщение клиенту об успехе

34
Один байт, содержащий символ
"1"
, отправляется обратно клиенту.