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

11.20. Устаревшие функции поиска адресов IPv6

В процессе разработки IPv6 интерфейс поиска адресов IPv6 много раз претерпевал серьезные изменения. В какой-то момент интерфейс был сочтен усложненным и недостаточно гибким, так что от него полностью отказались в RFC 2553 [38]. Документ RFC 2553 предлагал собственные функции, которые в RFC 3493 [36] были попросту заменены

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

Константа RES_USE_INET6

Поскольку функция

не имеет аргумента для указания нужного семейства адресов (подобного для ), в первом варианте API использовалась константа , которая должна была добавляться к флагам распознавателя посредством внутреннего интерфейса. Этот API был недостаточно переносимым, поскольку системам, использовавшим альтернативные внутренние интерфейсы распознавателя, приходилось имитировать интерфейс BIND.

Включение

приводило к тому, что функция начинала поиск с записей AAAA, а записи А возвращались только в случае отсутствия первых. Поскольку в структуре есть только одно поле длины адреса, функция могла возвращать адреса только одного типа (либо IPv6, либо IPv4).

Кроме того, включение

приводило к тому, что функция начинала возвращать адреса IPv4 в преобразованном к IPv6 виде.

Функция gethostbyname2

Функция

имеет добавочный аргумент, позволяющий задать семейство адресов.

Возвращаемое значение то же, что и у функции

— указатель на структуру , и сама эта структура устроена так же. Логика функции зависит от аргумента и параметра распознавателя (который мы упомянули в конце предыдущего раздела).

Функция getipnodebyname

Документ RFC 2553 [38] запретил использование

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

Функция возвращает указатель на ту же структуру

, которая использовалась . Аргументы и непосредственно соответствуют полям и . Для обеспечения безопасности в многопоточной среде возвращаемое значение выделяется динамически, поэтому его приходится освобождать вызовом .

Функции

и были отменены в RFC 3493 [36], а вместо них было предложено использовать и .

11.21. Другая информация о сетях

В этой главе мы сфокусировали внимание на именах узлов, IP-адресах, именах и номерах портов служб. Если же обобщить полученную информацию, мы увидим, что существует четыре типа данных (имеющих отношение к сетям), которые могут понадобиться приложению: узлы, сети, протоколы и службы. В большинстве случаев происходит поиск данных, относящихся к узлам (функции

и ), реже — к службам (функции и ) и еще реже — к сетям и протоколам.

Все четыре типа данных могут храниться в файле, и для каждого из четырех типов определены три функции:

1. Функция

, читающая следующую запись в файле, при необходимости открывающая файл.

2. Функция

, которая открывает файл (если он еще не открыт) и переходит к началу файла.

3. Функция

, закрывающая файл.

Для каждого из четырех типов данных определяется его собственная структура (соответственно, структуры

, , и ), что требует включения заголовка .

В дополнение к трем функциям

, и , которые допускают последовательную обработку файла, для каждого из четырех типов данных предоставляются функции ключевого поиска, или поиска по ключу (keyed lookup). Эти функции последовательно проходят файл (вызывая функцию для чтения каждой строки файла), но вместо того чтобы возвращать каждую строку вызывающему процессу, эти функции ищут элемент, совпадающий с аргументом. Имена функций поиска по ключу имеют вид . Например, две функции ключевого поиска для информации об узле — это функции (ищет элемент, совпадающий с именем узла) и (ищет элемент, совпадающий с IP-адресом). Таблица 11.5 обобщает эту информацию.