CC BY
96
ТЕХНИЧЕСКИЕ НАУКИ
УДК 004.72
NAME SERVICE IMPLEMENTATION FOR DECENTRALIZED
NETWORKS
Kruchinin Sergey, Ph.D. in politics, chief editor,
“Journal of scientific research publications”, siblis@yandex.ru
Vishnyakov Alexey, engineer, JSC “Concern “Sozvezdie”, vishnyakofff@rambler.ru
The article proposes methods of name service development for decentilized net-works,particulary VANET. Proposed solutions are compatible with international standard network protocols, such as DNA and SMTP. Technical solutions are researched with usage of domestic and foreign experience.
Keywords: network topology, DNS, software architecture, email, VANET (vechicu-lar ad-hoc network), mapML (network map markup language).
РЕАЛИЗАЦИЯ СЛУЖБЫ ИМЕН В ДЕЦЕНТРАЛИЗОВАННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЯХ
Кручинин Сергей Владимирович, кандидат политических наук, главный редактор журнала «Научно-исследовательские публикации», siblis@yandex.ru
Вишняков Алексей Владимирович, инженер, ОАО «Концерн «Созвездие»,
vishnyakofff@rambler.ru
В статье предложены способы построения службы имен в децентрализованных сетях, в частности VANET-сетях. Предложенные решения совместимы со стандартными протоколами связи, такими как DNS и SMTP. Рассматриваются технические решения с привлечением отечественного и зарубежного опыта.
Ключевые слова: вычислительные сети, DNS, криптомаршрутизатор, архитектура программного обеспечения, электронная почта, МСТС (мобильные сети транспортных средств).
В настоящее время существующая централизованная архитектура сети Интернет стала фактически безальтернативным стан-
дартом глобальных коммуникаций.
Можно поспорить насчет того, является ли Интернет централизованной или децентрализованной системой, но трудно спорить с тем, что его устройство включает в себя довольно важный централизованный компонент. Это и архитектура распределения IP-имен, и организация службы DNS, и доставка контента провайдерами.
Это стало причиной общественного возмущения, связанного с вопросами цензуры в сети Интернет и несовершенством вновь вводимых законов, позволяющих произвольно блокировать Интернет-ресурсы, с вопросами «прослушки» Интернет спецслужбами США (информация, раскрытая Э. Сноуденом), и т.д. Возникают проекты создания децентрализованных сетей, такие как netsukuku, cjdns.
Кроме того, существуют проблемы роста, например, исчерпание диапазона IP-адресов в сети Интернет. Разумеется, следует далее искать новые решения по построению сети Интернет.
Весь мир следит за судьбой марсохода Curiosity, на Западе обсуждаются перспективы отправки первых колонистов на Марс. В определенном будущем сеть Интернет изменится, и для этого необходимые изыскания надо проводить уже сейчас.
Авторы, работая над созданием специализированной сети для ЕСУ ТЗ, представляющей собой децентрализованную сеть (хотя и обслуживающую централизованную структуру организации пользователей), надеются, что какие-то из их наработок могут быть полезны в будущем, а не только в рамках той узкой задачи, в ходе изучения которой они были разработаны.
Хотя в данной работе построение службы DNS привязано к обслуживанию транспортных средств, способных работать в различной пространственной конфигурации относительно друг друга,
теоретически опыт настройки службы имен может быть перенесен на любую, в том числе виртуальную, или оверлейную архитектуру построения сети, используя ресурсы существующей сети Интернет.
Мы поставили задачу разработать решение, позволяющие обеспечить мобильность пользователей в условиях функционирования децентрализованных мобильных сетей транспортных средств (МСТС, VANET) [1], но при этом достигнуть совместимости предложенного решения с существующими в международной науке и практике решениями.
Учитывая то, что в ходе уже реализованных работ применяются средства, отличающиеся нестандартностью и несовместимостью с рядом общепринятых сетевых стандартов, пришлось дополнительно изучать вопрос обеспечения совместимости при использовании уже разработанных программных средств, так и стандартных протоколов, при внедрении таких средств, как электронная почта, SIP-протоколы и т.д.
Сам метод обеспечения прозрачного функционирования сетевых служб при переходе пользователей из одного транспортного средства в другое описан в статье [2], в этой же работе мы остановимся на технической реализации службы имен, позволяющей прозрачно функционировать как стандартные сетевые службы, так и специально-разработанные для конкретных задач ранее.
1. Назначение службы имен
Служба имен предназначена для автоматизации настройки мобильного транспортного средства, оснащенного программнотехническими средствами, именуемого программно-техническим комплексом (далее ПТК) в части распределения должностных лиц
(далее ДЛ) по ПТК и отслеживания их перемещений.
Для этого в состав программного обеспечения телекоммуникационного модуля сопряжения (ТКОМ) абонентской и транспортной сетей [3] вводится серверное программное обеспечения для хранения и обслуживания (пополнение, коррекция) сопоставлений доменных имен и IP-адресов.
В состав программного обеспечения абонентских ЭВМ вводится клиентское программное обеспечение для уведомлений программного обеспечения службы имен о входе (login) и выходе (logout) пользователей в/из систему/ы.
Для доступа к службе имен серверное ПО ТКОМ должно обращаться к службе имен. Так как большинство серверов стандартные (служба электронной почты, IP-телефония), и только сервер ПО СТ [4] нестандартный, то для совместимости, расширяемости и удобства предлагается использовать стандартный протокол DNS.
ПО СТ придется модифицировать с тем, чтобы вместо использования таблицы tlk_names, используемой в ПО СТ, производился запрос посредством функциеи GetHostByName() к службе имен.
Таким образом, переход от tlk_names к службе имен аналогичен переходу от /etc/hosts к системе DNS, который уже произошел в глобальной сети.
Отличие рассматриваемой службы имен от используемой в стационарных сетях Интернет заключается преимущественно в том, что пользователям присваиваются отдельные доменные имена (в качестве которых могут выступать коды ДЛ с приписанной в конец кода точкой - для отличия от целочисленных IP-адресов, например 2222666.)
2. Выбор ПО для реализации
Из существующих реализаций системы DNS авторами выбрана реализация DjbDNS от Дэвида «DJB» Бернштейна[5], американского профессора, преподавателя и программиста.
Особенностью продуктов от DJB заключается в их модульности, лаконичности написания, экономности используемой памяти и надежности. Помимо DjbDNS заслуживает внимания иной продукт от DJB - qmail - система электронной почты.
Важной отличительной особенностью ПО, написанного DJB, является свободная лицензия - наиболее свободная из всех, потому как Дэвид Бернштйен передал свое по в свободное достояние (public domain), следовательно, нет никаких ограничений по модификации, использованию, применению, продаже программного обеспечения его авторства.
На наш взгляд, в дальнейшем стоит также заменить реализацию почты XMail (лицензия GPL) на QMail (public domain), а остальные компоненты в случае их не свободности (GPL) на аналогичные по функциям но с лицензией BSD.
Стоит рассмотреть возможность применения Jabber (XMPP), который сможет заменить и телекоммуникационный сервер, и службу передачи файлов, и, возможно, IP-телефонию.
Таким образом, при грамотном проектировании и выборе за основу готовых компонентов только со свободным кодом (не GPL, а Public Domain и BSD) можно сделать реализацию ТКОМ более функциональной, свободной и лаконичной, и избежать стихийнохаотического процесса разработки.
При этом необходимо уделять внимания лаконичности и еди-
нообразия архитектуры и исходных текстов ПО, и использование программ с большим числом непонятного и запутанного кода и такой же логикой работы свести к нулю.
Также стоит отметить, что во всех продуктах ЩЪБКВ используются унифицированные компоненты, такие как система ведения логов (журналирование), 1ер-клиент-сервер (И8СР1), которые, как мы предлагаем, необходимо использовать в любом ПО ТКОМа.
3. Архитектура DjbDNS
Возможности ЩЪБЫЗ позволяют выполнять итеративные и рекурсивные запросы. Итеративный запрос - это когда сервер имен имеет список адресов других серверов имен и опрашивает у них по очереди, не знает ли из них кто 1Р-адрес для того-то имени. Поиск продолжается либо до первого положительного ответа, либо до того момента когда список исчерпан (в этом случае, естественно, возвращается - не найдено).
Иллюстрацию принципа работы итеративного запроса см. рис. 3.1
Все эти сервера находятся в списке ОЫЗ-серверов опрашивающего ОИв-сервера
Сервер,
осуществляющий
поиск
Рис. 3.1. Иллюстрация итеративного поиска имен
Рекурсивный поиск имен производится, когда Б^-сервер спрашивает у вышестоящего (или нижестоящего), а последующий сервер, если не знает - дальше по цепочке.
Логично совместить рекурсивный поиск с кешированием -временным запоминанием полученного результата.
Таким образом, если другой кто запросит вскоре после первого запроса, можно ему выдать тот же ответ (должностное лицо не успеет за это время далеко переместиться).
Поэтому время жизни для записей имен в этом случае нужно устанавливать не очень большим. Например, несколько меньшим, чем время, которое затратит должностное лицо на переход с одного ПТК на другой, но не несколько часов, как это может быть в сети Интернет).
Иллюстрацию рекурсивного поиска имен см. рис. 3.2.
До этого сервера очередь не дошла
Все дальше не ищем!
Рис. 3.2. Иллюстрация рекурсивного поиска имен
Рекурсивный поиск может сочетаться с итеративным, то есть каждый в цепочке может производиться опрос нескольких других,
но такое сочетание не желательно, так как вырастает время поиска, что приводит к истечению таймаута и возвращается ответ «не найдено».
Впрочем, возможно использование рекурсивного поиска и в тех случаях, когда у последующего сервера несколько вариантов -к какому еще серверу можно отправит запрос, при условии, что на сервере явным образом задано - какие сервера предназначены для запроса! Подробнее см. на рис. 3.3.
Поясним суть: на каждом из серверов имеются таблицы должностных лиц, но они привязаны не к ІР-адресам ПТК, в которых они находятся (т.к. эти самые ПТК постоянно меняются), но к ІР-адресам ответственных серверов имен. У этих ПТК служба имен и запрашивает актуальный ІР-адрес.
Таким образом, за перемещения ДЛ одного уровня отвечает узел связи соответствующего уровня, за перемещения ДЛ нижестоящего уровня - соответственно сервер имен нижестоящего уровня (например, установленный на ПТК этого уровня).
Если ДЛ перемещается внутри уровня - то таблицы имен остальных серверов не меняются (подобно тому, как если в помещении отдела человек пересел в другую комнату, все равно надо спрашивать у его начальника, а каждому знать, кто за каким рабочим местом сидит - вовсе излишне).
Хотя результат может на некоторое время и быть запомненным - но и у нас для этого есть кеширующие сервера).
Если ДЛ переходит в другое подразделение, то производится обмен между серверами имен, причем между такими, у которых произошли изменения в таблицах «кто за кого отвечает» - но об этом подробнее в дальнейшем - в соответствующем разделе.
А
с
___ Его ІР -
192.168.15.20
Какои"адрес
22266^\
Комментарий: Нет записи, но
х
известно где можно
запросить. 2226666 надо
запрашивать у А
33366666 у В 44466666 у С Запросим у А и
И
Какой адр эс у 222666?
V
Да, его ІР -,192.168.15.20
ответим
Тот кто ищет!
Рис. 3.3. Иллюстрация рекурсивного поиска имен (когда сервер знает -
у кого спросить)
Теперь настало время отметить, что для выполнения итеративного и рекурсивного поиска в ЩЬВЫ8 сервер отвечают различные сервера. Остановимся на них более подробно.
ТтуБК8 - авторитетный (авторитарный) сервер имен. Он непосредственно читает таблицы сопоставлений «имя - 1Р-адрес» своей зоны ответственности и отвечает на итеративные запросы. Рекурсивные запросы ТтуОЫ8 получает, но далее не посылает. Потому ТтуО№ служит в качестве так сказать «первоисточника» информации о том, у какого ДЛ в данный момент актуальный 1Р-адрес.
БК8СасЬе - кеширующий сервер имен. Умеет переспрашивать (выполнять рекурсивный поиск, запрашивая данные у других ВЫ8СасЬе - которые могут далее переспросить - т.е. рекурсивный поиск, и у ТтуБК8 - т.е. итеративный поиск).
Цепочка из рекурсивных запросов в конечном итоге (если все Кеши пусты, разумеется), упирается в ТтуО№-сервер, в то время как все промежуточные узлы - БК8СасЬе. Б^СасЬе умеет кешировать записи, но сохраняет их ровно то время, которое содержится 140
в ответе на запрос, то есть время кеширования задается не в БШСасИе, а в таблицах Т1пуБК8(!)
Особенностью реализации ЩЬБК8 является то, что Т1пуБК8 и БК8СасИе требуют отдельных 1Р-адресов. Как вариант один из этих серверов может использовать локальный 127.0.0.1, а другой -внешний 1Р-адрес.
4. Построение службы имен, используя ЩВБ^
Возможны различные варианты построения службы имен на основе ЩЬБК8, основанные на различных комбинациях Т1пуОК8, Б^СасИе и службы уведомлений, которую необходимо написать на основе и8СР1 и который будет уведомлять сервера имен о происходящих изменениях, а также менять таблицы серверов.
В данном разделе мы рассмотрим построение системы имен, основанной на иерархической структуре (для тех случаев, когда иерархические организации пользователей работают на децентра-лизованно-организованной связи транспортных средств).
В качестве примера мы рассмотрим трехуровневую систему управления. Она позволяет описать достаточного уровня иерархию (на предприятии - высшее руководство, среднее руководство - рабочие группы, или иерархию в силовых структурах). В каждом из уровней есть сегменты.
Соответственно на самом верхнем это будет целиком руководство высшего уровня, на втором уровне - среднего уровня, и на третьем - группы исполнителей.
В каждом сегменте есть один (или один + несколько дублирующих-резервных) сервер имен, на которых установлен Т1пуОК8 и ведутся таблицы сопоставлений для каждого ДЛ в этом сегменте.
Рассмотрим эту ситуацию на картинке 4.1.
Сервер ответов имен Р^СасИе
Сервер таблиц имен V 4, Сервер ответов имен
ТіпуОМЗ > Р^СасИе
• Сервер обновлений имен 1
2 (на основе иЗСР1) Сервер таблиц имен
тшуомз
Клиент уведомления службы имен I ^ (собственный, на основе 118СР1) |
Регистрация нового ДЛ
Архитектура службы имен
Рисунок 4.1. Взаимодействие ПО службы имен и оповещения
Рассмотрим взаимодействие и состав программного обеспечения службы имен.
Службу имен, на наш взгляд, нежелательно рассматривать вне ТКОМ, потому как самостоятельную ценность она приобретает только при обслуживание каких-то серверных модулей. Поэтому остановимся на месте и роли службы имен в ТКОМе.
Сразу отметим, что при реализации ТКОМ в различных МСТС могут быть применена как данная концепция ТКОМ, так и
альтернативные варианты, потому мы рассмотрим данную концепцию, не останавливаясь на альтернативных данной концепциях и вариантах изложения.
Итак, в нашей концепции ТКОМ необходимо использовать:
• Стандартные и опробованные средства и протоколы (постольку, поскольку есть возможность);
• Использовать и писать высококачественный, компактный и читаемый код, использовать лучшие практики (best practises) в разработке программного обеспечения (software design);
• Использовать унифицированную и единообразную архитектуру без дублирования одних и тех же функций в разных модулях.
Мы считаем, что указанным выше критериям удовлетворяет программное обеспечение, написанное Дэвидом Бернштйеном, и подходит для решения наших задач.
Это:
• DjbDNS (включая TinyDNS и DNSCache) - для реализации протоколов службы имен;
• Daemontools (включая Multilog) - для управления приложениями ТКОММ и унифицированного ведения логов;
• UCSPI (включая tcpserver и tcpclient) - для организации tcp соединений;
• QMail - система электронной почтый, разработанная DJB, унифицированная с остальными DJB-средствами и обладающая максимально-свободной лицензией (общественное достояние -public domain).
Подробнее см. рис. 4.2.
Необходимо разрабатывать с расчетом на использование daemontools
! Клиент оповещения о входе/ ] выходе пользователя
| (требует разработки)
Рис. 4.2. Архитектура ТКОМ и службы имен в его составе
Кроме того необходимо использовать другие средства:
• Сервер XMPP, который позволяет обмениваться сообщениями, передавать файлы, осуществлять SIP-телефонию и может работать поверх разных протоколов (в том числе, как следует понимать, поверх протоколов ПО СТ)
• HTTP-сервер, PHP, и т.д. для реализации удаленных пользовательских интерфейсов (контроля и управления), но по принципу - лицензия общественное достояние (Public domain) или BSD, позволяющая модифицировать ПО и делать на его основе продукты
без ограничений.
Помимо этого, если какие-то средства будут использоваться помимо указанных (из существующего в мировой практике ПО или вновь разработанное), оно должно быть адаптировано для использования Daemontools и Multilog и использования доменных имен по правилам службы имен
5. Установка DJBDNS
Официальный релиз DJBDNS доступен по адресу http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
Необходимо исправить ошибку с errno (скопировать ссылку из c-файла в h-файл). Можно скачать готовый патч с http://www.qmail.org/rpms/patches/djbdns-1.05.errno.patch либо исправить самостоятельно.
Сборка, установка:
make
make setup check
Для работы используем Daemontools. Официальный релиз доступен по адресу http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
Точно также необходимо исправить ошибку с errno или воспользоваться патчем
http: //www.qmail. org/moni .csi .hu/pub/glibc-2.3.1/ daemontools-
0.76.errno.patch
Итак, подведем итоги.
1) Разработанная архитектура позволяет поддерживать все возможности МСТС
2) Предложенные решения для уже разработанных сетей МСТС при незначительной адаптации позволяют использовать их совместно с уже внедренными протоколами МСТС.
3) Легкость внедрения существующих решений, стандартных для Интернет.
Но также следует отметить, что придется адаптировать как решения, используемые в МСТС (интерпретировать систему адресации как доменные имена), а также стандартные средства (адаптируя их к однодоменной системе адресации, обладающей несколько отличной внутренней архитектурой построения сети).
Таким образом, можно создать программно-аппаратную систему, использующую как накопленный входе работ, в которых принимали участие авторы, так и в мировой практике опыт и обеспечить бесшовное функционирование существующих и новых компонентов, избегая ошибок, которые возможны при повторной реализации существующих решений, в случае игнорирования накопленного в науке и технике опыта.
Авторы надеются, что предложенные решения будут интересны всем тем, кого интересует судьба не только построения специализированных и нестандартных сетевых решений, но и сети Интернет в целом, децентрализованных, Р2Р и защищенных сетей будущего.
Литература
1. Кручинин С.В. К вопросу о терминологии в области мобильных сетей транспортных средств // Теория и техника радиосвязи, 2011, № 1. - С. 117-120.
2. Кручинин С.В. Особенности построения системы доменных имен (DNS) в мобильных Ad Hoc сетях // Теория и техника радиосвязи: науч.-техн. Журнал, 2011, № 2. - С. 79-83.
3. Кручинин С.В. Телекоммуникационный модуль сопряжения абонентской и транспортной сетей // Патент на полезную модель RU 128 052 U1 Опубликовано 10.05.2013 бюл. № 13; заявка № 2012151805/08; заявл. 03.12.2012. - Москва. Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
4. Обельченко М.В., Пономарев М.П. Сервер системных телекоммуникаций // Свидетельство о государственной регистрации программы для ЭВМ №2007613864. - Москва. 2007. Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
5. DjbDNS http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
