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

en1: <UP BCAST MCAST >
 MTU: 1500
 IP addr: 172 24.37.81 <i>третий псевдоним</i>
 broadcast addr: 172.24.37 95
Если мы запустим ту же программу под FreeBSD, используя реализацию функции 
get_ifi_info
, приведенную в листинге 18.9 (которая может легко получить аппаратный адрес), то получим:
freebsd4 % <b>prifinfo inet4 1</b>
de0: &lt;UP BCAST MCAST &gt;
 0:80:c8:2b:d9:28
 IP addr: 135.197.17.100
 broadcast addr: 135.197.17.255
de1: &lt;UP BCAST MCAST &gt;
 0:40:5:42:d6:de
 IP addr: 172.24.37.94 <i>основной IP-адрес</i>
 broadcast addr: 172.24.37.95
ef0: &lt;UP BCAST MCAST &gt;
 0:40:5:42:d6:de
 IP addr: 172.24.37.93 <i>псевдоним</i>
 broadcast addr: 172.24.37.93
lo0: &lt;UP MCAST LOOP &gt;
 IP addr: 127.0.0.1
В этом примере мы указали программе выводить псевдонимы, и мы видим, что один из псевдонимов определен для второго интерфейса Ethernet (
de1
) с идентификатором узла 93.
Теперь мы покажем нашу реализацию функции 
get_ifi_info
, использующую вызов 
SIOCGIFCONF
 функции 
ioctl
. В листинге 17.4 показана первая часть этой функции, получающая от ядра конфигурацию интерфейса.
Листинг 17.4. Выполнение вызова SIOCGIFCONF для получения конфигурации интерфейса
//lib/get_if_info.c
 1 #include &quot;unpifi.h&quot;
 2 struct ifi_info*
 3 get_ifi_info(int family, int doaliases)
 4 {
 5  struct ifi_info *ifi, *ifihead, **ifipnext;
 6  int sockfd, len, lastlen, flags, myflags, idx = 0, hlen = 0;
 7  char *ptr, *buf, lastname[IFNAMSIZ], *cptr, *haddr, *sdlname;
 8  struct ifconf ifc;
 9  struct ifreq *ifr, ifrcopy;
10  struct sockaddr_in *sinptr;
11  struct sockaddr_in6 *sin6ptr;
12  sockfd = Socket(AF_INET, SOCK_DGRAM, 0);
13  lastlen = 0;
14  len = 100 * sizeof(struct ifreq); /* начальное приближение к нужному размеру буфера */
15  for (;;) {
16   buf = Mallос(len);
17   ifc.ifc_len = len;
18   ifc.ifc_buf = buf;
19   if (ioctl(sockfd, SIOCGIFCONF, &amp;ifc) &lt; 0) {
  
20    if (errno != EINVAL || lastlen != 0)
21     err_sys(&quot;ioctl error&quot;);
22   } else {
23    if (ifc.ifc_len == lastlen)
24    break; /* успех, значение len не изменилось */
25    lastlen = ifc.ifc_len;
26   }
27   len += 10 * sizeof(struct ifreq); /* приращение */
28   free(buf);
29  }
30  ifihead = NULL;
31  ifipnext = &amp;ifihead;
32  lastname[0] = 0;
33  sdlname = NULL;
Создание сокета Интернета
11
 Мы создаем сокет UDP, который будет использоваться с функциями 
ioctl
. Может применяться как сокет TCP, так и сокет UDP [128, с. 163].
Выполнение вызова SIOCGIFCONF в цикле
12-28
 Фундаментальной проблемой, связанной с вызовом 
SIOCGIFCONF
, является то, что некоторые реализации не возвращают ошибку, если буфер слишком мал для хранения полученного результата [128, с. 118–119]. В этом случае результат просто обрезается так, чтобы поместиться в буфер, и функция 
ioctl
 возвращает нулевое значение, что соответствует успешному выполнению. Это означает, что единственный способ узнать, достаточно ли велик наш буфер, — сделать вызов, сохранить возвращенную длину, снова сделать вызов с большим размером буфера и сравнить полученную длину со значением, сохраненным из предыдущего вызова. Только если эти две длины одинаковы, наш буфер можно считать достаточно большим.
 
ПРИМЕЧАНИЕ
 
Беркли-реализации не возвращают ошибку, если буфер слишком мал [128, с. 118-199], и результат просто обрезается так, чтобы поместиться в существующий буфер. Solaris 2.5 возвращает ошибку EINVAL, если возвращаемая длина больше или равна длине буфера. Но мы не можем считать вызов успешным, если возвращаемая длина меньше размера буфера, поскольку Беркли-реализации могут возвращать значение, меньшее размера буфера, если часть структуры в него не помещается.
 
В некоторых реализациях предоставляется вызов SIOCGIFNUM, который возвращает число интерфейсов. Это позволяет приложению перед выполнением вызова SIOCGIFCONF выделить в памяти место для буфера достаточного размера, но такой подход не является широко распространенным.
 
Выделение в памяти места под буфер фиксированного размера для результата вызова SIOCGIFCONF стало проблемой с ростом Сети, поскольку большие веб-серверы используют много альтернативных адресов для одного интерфейса. Например, в Solaris 2.5 был предел в 256 альтернативных адресов для интерфейса, но в версии 2.6 этот предел вырос до 8192. Обнаружилось, что на сайтах с большим числом альтернативных адресов перестают работать программы с буферами фиксированного размера для размещения информации об интерфейсе. Хотя Solaris возвращает ошибку, если буфер слишком мал, эти программы размещают в памяти буфер фиксированного размера, запускают функцию ioctl, но затем перестают работать при возвращении ошибки.
 
12-15
 Мы динамически размещаем в памяти буфер начиная с размера, достаточного для 100 структур 
ifreq
. Мы также отслеживаем длину, возвращаемую последним вызовом 
SIOCGIFCONF
 в 
lastlen
, и инициализируем ее нулем.