PDA

Просмотр полной версии : CallBook база на основе DNS



RN3DLL
30.11.2011, 12:13
Раньше доступ в Сеть можно было получить только со стационарного компьютера или, на худой конец, с ноутбука. Сегодня во Всемирную Паутину умеет выходить огромное количество других устройств, взять хотя бы мобильные телефоны. Естественно, новые возможности несколько изменили характер использования Интернета: сегодня многие пользователи заходят в Сеть, находясь на улице, в кафе или других общественных местах, для того чтобы оперативно получить какую-либо информацию, например, узнать адрес и телефон какого-нибудь магазина.

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

Есть ли выход из этой ситуации? Конечно, можно создать отдельный веб-ресурс, состоящий всего из одной страницы, на которой будут опубликованы контактные данные. В этом случае для размещения информации потребуется зарегистрировать домен, заказать услугу хостинга и подготовить веб-страницу. С одной стороны это достаточно просто, с другой – весьма затратно, ведь, например, за хостинг придется платить ежемесячно даже несмотря на то, что количество загруженной на сайт информации будет минимальным. Необходимо также помнить, что доступ к созданному ресурсу будет возможен только с использованием веб-браузера - устройства, в которых он не установлен, не смогут получить данные. Одним словом, эффективность отдельного интернет-сайта для публикации контактных данных весьма сомнительна.


Теперь немного о том, в каком виде система DNS сохраняет данные, указанные владельцем доменного имени в зоне TEL. В DNS для этого предусмотрено три типа записей: NAPTR, TXT и LOC. Первая позволяет хранить контактную информацию (телефон, факс, e-mail, логин в Skype и др.), а вторая и третья предназначены для публикации коротких текстов и указания местоположения, соответственно. При этом данные NAPTR строго структурированы – пользователь может задать приоритет их отображения. Таким образом, владелец домена в зоне TEL вправе самостоятельно определять порядок, в котором указанная им контактная информация будет выводиться на экран того или иного устройства. Например, номер телефона может быть первым в списке публикуемых данных, а может отображаться вслед за адресом электронной почты.

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

Что касается данных LOC, то они имеют вид географических координат, которые при желании могут быть привязаны к любому картографическому сервису для наглядного отображения текущего местоположения владельца доменного имени. В частности, если пользователь отправляет запрос к домену TEL из браузера, происходит автоматическая привязка географических данных к картам от Google.

Еще одно преимущество доменной зоны TEL состоит в том, что вся опубликованная в ней информация активна – то есть, получив ее в ответ на запрос к системе DNS, посетитель домена может сразу воспользоваться данными, например, осуществить телефонный звонок или отправить письмо по электронной почте.

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

Например, зарегистрировав домен Moscow.tel, пользователь на его базе может создать домен Cinema.moscow.tel и опубликовать на нем список московских кинотеатров. Затем для каждого кинотеатра он может назначить отдельный домен (например, Pushkinsky.cinema.moscow.tel) для размещения соответствующих контактных данных. Количество поддоменов не ограничено, поэтому к каталогу кинотеатров на базе имени Moscow.tel можно добавить и другие данные – например, аналогичным способом создать справочник московских ресторанов. При этом вся информация в каждом каталоге будет отображаться в структурированном виде. Так, при доступе к домену в зоне TEL через браузер сведения о существующих на его базе поддоменах будут показаны в виде ссылок на них.

Наконец, домен TEL будет полезен и тем, кто хочет разместить приватные контактные данные в Сети – при желании публикуемую информацию можно сделать доступной только ограниченному кругу лиц, список которых утверждается и редактируется владельцем доменного имени. В частности, он может объединить пользователей в группы, представители каждой из которых смогут просматривать одни данные, в то время как другие данные будут от них скрыты.

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

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

http://info.nic.ru/st/9/out_2473.shtm

Жаль что там (в домене TEL) нельзя создать миллионы записей

UT4UKW
30.11.2011, 12:31
Чет не уловил мысль при чем здесь колбук?

RN3DLL
30.11.2011, 12:54
Чет не уловил мысль при чем здесь колбук?

Я предложил создать его на базе DNS системы серверов в интернете.

+Высокая производительность
+Масштабируемость
+ платформенная независимость

Пока вы будите получать данные с вэб сервера, из DNS данные о позывном будут уже получены.

UT4UKW
30.11.2011, 13:02
Это как... каждому радиолюбителю зарегистрировать домен? :)
И чем не устраивают существующие qrz.com или бесплатный HamQTH (http://www.hamqth.com/)

RN3DLL
30.11.2011, 13:22
Это как... каждому радиолюбителю зарегистрировать домен? :)
И чем не устраивают существующие qrz.com или бесплатный HamQTH (http://www.hamqth.com/)

Формируется домен третьего уровня RU.QRZ.COM
Информация запрашивается из DNS запросом RN3DLL.RU.QRZ.COM

Децентрализация, можно вводить сервера очень быстро для снижения нагрузки на основные, нет регистрации.

Хочу обратить внимание на то, что при таком подходе один сервер может обслуживать в 100-150 раз больше запросов, чем если делать запросы через вэб сервер.
А для добавления сервера обслуживания нет необходимости создавать целую ферму вэб серверов

А для экспедиций это еще большие плюсы одно дело получить 1 кб полезной информации и другое дело 1кб полезной информации и еще куку мегабайт бесполезной.

RN3ANT
30.11.2011, 13:44
+Высокая производительность
А чем не устраивает производительность тех же, уже упомянутых «существующих qrz.com или бесплатный HamQTH»?

+Масштабируемость
Разве БД «существующих qrz.com или бесплатный HamQTH» уже достигли своего потолка масштабируемости?

+ платформенная независимость
Мне, например, пока трудновато представить себе, что какому либо радиолюбителю вот вдруг ни с того, ни с сего, откуда ни пойми, потребуется получить какие-либо данные о другом радиолюбителе с мобилки или еще с какой-нибудь джобсовской фигни. В 99,99...% случаев эти данные нужны не так спешно, из места, в котором есть обычный ноут или десктоп, а уж их платформы упомянутые выше сервисы вполне устраивают.

Далее, глянув мельком по диагонали то, что пишут о *.TEL, заглянул в несколько этих самых .TEL — компания Telnic, оккупировав домен, соорудила на скорую руку свое приложение, пока непонятно, насколько удобное, и проталкивает его и свои услуги, надо заметить — не бесплатные, самыми разными способами. Побегав по этим *.TEL с помощью обычного браузера и канала 20 МБит/с, отметил для себя, что сервис несколько тормозной, во всяком случае, у меня QRZ.com открывается не в пример шустрее, чем любой из *.TEL.
Глянув из любопытства, какова ситуация с callbook.tel и hamradio.tel, а также еще с десятком пришедших на ум доменных имен, обнаружил, что все они уже зарегистрированы на domainmonster.com )) который, даже к бабке не ходи, отдаст их никак не за 6,99 евро (как предлагает ничейные пока имена Telnic), а во много раз дороже. Да и потом, использование и поддержка чего-либо своего в зоне .TEL потребует какого-то количества ресурсов. Не говоря уже о том, что саму базу позывных кому-то придется изначально составлять, поддерживать актуальность и добавлять впоследствии новые позывные.

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

Хочу обратить внимание на то, что при таком подходе один сервер может обслуживать в 100-150 раз больше запросов, чем если делать запросы через вэб сервер.
А для добавления сервера обслуживания нет необходимости создавать целую ферму вэб серверов стоит внимательнее разобраться )

Добавлено через 13 минут
О кроссплатформенности или платформонезависимости…

В DNS для этого предусмотрено три типа записей: NAPTR, TXT и LOC

преимущество доменной зоны TEL состоит в том, что вся опубликованная в ней информация активна – то есть, получив ее в ответ на запрос к системе DNS, посетитель домена может сразу воспользоваться данными, например, осуществить телефонный звонок или отправить письмо по электронной почте
С помощью чего именно предполагается «читать» данные из этих полей? Для этого явно должно быть какое-либо приложение на клиентской стороне? И оно должно быть для каждой вероятной платформы?

RN3DLL
30.11.2011, 13:47
Побегав по этим *.TEL с помощью обычного браузера и канала 20 МБит/с, отметил для себя, что сервис несколько тормозной, во всяком случае, у меня QRZ.com открывается не в пример шустрее, чем любой из *.TEL.


Домен TEL это как реализована идея.

По сути

Если вы понимаете как работает интернет то должны согласиться с тем что данные из DNS вы сможете получить быстрее на устройство чем с вэб сайта.

Может тогда скинемся и подадим заявку на домен .HAM :-) домен только для радиолюбителей

RN3ANT
30.11.2011, 13:50
А для экспедиций это еще большие плюсы одно дело получить 1 кб полезной информации и другое дело 1кб полезной информации и еще куку мегабайт бесполезной.

Тот же Logger32 уже позволяет получать от «существующих qrz.com или бесплатного HamQTH» килобайт полезной информации без мегабайтов бесполезной. К чему еще огород? А потом, зачем в экспедиции нужны данные из колбуков?

Добавлено через 2 минуты

данные из DNS вы сможете получить быстрее на устройство чем с вэб сайта
Цена вопроса — доли секунды. В нашем деле это, конечно же, жизненно важно ;)

ER1CS
30.11.2011, 13:55
Снова мечта о халяве. Даже смысла объяснять почему не получится не вижу - восторженный пыл топикстартера (шутка) сам угаснет по мере углубления в материал.
В очередной раз просто хочу напомнить - бесплатного сыра нет даже в мышеловке.

Добавлено через 59 секунд

данные из DNS вы сможете получить быстрее на устройство чем с вэб сайта.

Там электроны быстрее бегают? :)

RN3ANT
30.11.2011, 13:55
Если вы понимаете как работает интернет
Владимир, научите чайника, с помощью какого приложения вот прямо сейчас мне прочитать

три типа записей: NAPTR, TXT и LOC

RN3DLL
30.11.2011, 13:59
Тот же Logger32 уже позволяет получать от «существующих qrz.com или бесплатного HamQTH» килобайт полезной информации без мегабайтов бесполезной. К чему еще огород? А потом, зачем в экспедиции нужны данные из колбуков?

Добавлено через 2 минуты

Цена вопроса — доли секунды. В нашем деле это, конечно же, жизненно важно ;)


Нет, это не жизненно важно, но возможно это пригодится
Преимущества не всегда очевидны.

RN3DLL
30.11.2011, 14:00
Владимир, научите чайника, с помощью какого приложения вот прямо сейчас мне прочитать

nslookup

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nslookup__subcommands.mspx?mfr=true

PS Пока вам отправлял получил
Fatal error: Out of memory (allocated 14417920) (tried to allocate 122880 bytes) in /home/qrz/forum.qrz.ru/includes/class_mail.php on line 256

RN3ANT
30.11.2011, 14:00
Там электроны быстрее бегают?
Нет, электроны там бегают точно так же. Только вот прежде чем получить какие-либо данные от какого-либо вэб-сервера, вам (вашему компьютеру) требуется получить от DNS-сервера информацию о том, по какому маршруту слать запрос к вэб-серверу, потом слать сам запрос, и только потом уже получать нужную вам информацию. А в этом случае вы исключаете, ставшие ненужными «информацию о том, по какому маршруту слать запрос к вэб-серверу, потом слать сам запрос, и только потом уже получать нужную вам информацию», так как сразу получаете от DNS-сервера всё, что нужно

ER1CS
30.11.2011, 14:05
А в этом случае вы исключаете, ставшие ненужными «информацию о том, по какому маршруту слать запрос к вэб-серверу, потом слать сам запрос, и только потом уже получать нужную вам информацию», так как сразу получаете от DNS-сервера всё, что нужно
А если в этом случае я включаю понимание наличия практически везде кэша arp, то вся разница оказывается в первом запросе, после которого отличий в смысле лишних запросов нет.

RN3DLL
30.11.2011, 14:07
Снова мечта о халяве. Даже смысла объяснять почему не получится не вижу - восторженный пыл топикстартера (шутка) сам угаснет по мере углубления в материал.
В очередной раз просто хочу напомнить - бесплатного сыра нет даже в мышеловке.

Добавлено через 59 секунд


Там электроны быстрее бегают? :)

Мечты о «халяве» это в Молдавии

ЗЫ: Что такое Молдавия с точки зрения физики?
— Хаотическое движение ИОНОВ

RN3ANT
30.11.2011, 14:11
nslookup
хорошо, мне не в лом набрать в командной строке nslookup -type=any <имя сервера>, чтоб получить кучку ненужной мне информации. А с помощью чего эту ненужную (или, как предполагается, нужную от *.tel) информацию получит обычный пользователь Сети? ;)

ER1CS
30.11.2011, 14:13
Мечты о «халяве» это в Молдавии
Веско, значимо, аргументированно и совершенно без перехода на личности. Поздравляю, спорить не собираюсь.

RN3DLL
30.11.2011, 14:14
хорошо, мне не в лом набрать в командной строке nslookup -type=any <имя сервера>, чтоб получить кучку ненужной мне информации. А с помощью чего эту ненужную (или, как предполагается, нужную от *.tel) информацию получит обычный пользователь Сети? ;)

http://www.nic.tel/tools-landing.html

Добавлено через 1 минуту

Веско, значимо, аргументированно и совершенно без перехода на личности. Поздравляю, спорить не собираюсь.

Не обижатесь :)

ER1CS
30.11.2011, 14:22
Не обижатесь
И не собирался, просто констатировал. Как и в первом моём посте. Всё давно придумано, и пытаться притянуть за уши микроскоп к забиванию гвоздей - имхо не самое мудрое занятие. Кстати, никто не мешает к любой сетевой бд обращаться через ip адрес, или вписать его в hosts - тогда вообще никаких днс запросов не будет.

RN3DLL
30.11.2011, 14:27
И не собирался, просто констатировал. Как и в первом моём посте. Всё давно придумано, и пытаться притянуть за уши микроскоп к забиванию гвоздей - имхо не самое мудрое занятие. Кстати, никто не мешает к любой сетевой бд обращаться через ip адрес, или вписать его в hosts - тогда вообще никаких днс запросов не будет.

Можно и так, но тогда распределенной базы нет.

И сравнение с забиванием гвоздей с микроскопом тут тоже не уместно.

RN3ANT
30.11.2011, 14:30
http://www.nic.tel/tools-landing.html
Уаахахахахх! Владимир, чем эта фигня отличается от другой фигни, которую называют жутким словом «браузер»? О чем я и говорил вначале. Чтоб понимать «DNS-записи» от Telnic слепившего своё нечто, нужна для каждой платформы клиентская фигня для этого нечто. Иначе не прочитать ни саму запись, ни понять про её «активность»

RN3DLL
30.11.2011, 14:36
Уаахахахахх! Владимир, чем эта фигня отличается от другой фигни, которую называют жутким словом «браузер»? О чем я и говорил вначале. Чтоб понимать «DNS-записи» от Telnic слепившего своё нечто, нужна для каждой платформы клиентская фигня для этого нечто. Иначе не прочитать ни саму запись, ни понять про её «активность»

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

ER1CS
30.11.2011, 14:41
но тогда распределенной базы нет
А её и так не будет, по причине что любой нормальный провайдер не станет кэшировать у себя эти данные от непонятно кого и нестандартного формата, а если и станет - то в любом случае по принципу работы днс - путь запроса будет такой: к днс провайдера-к рутам-к хозяину домена- ответ к днс провайдера - ответ от провайдера юзеру. учитывая что каждый раз запрос будет новый - толку от кэша 0.
Так что всё уместно - для всего есть свои механизмы, и заставлять их выполнять функции для которых они не предназначены - неразумно.

RN3DLL
30.11.2011, 14:51
А её и так не будет, по причине что любой нормальный провайдер не станет кэшировать у себя эти данные от ......

А мы будем пользоваться НЕНОРМАЛЬНЫМИ! :-)

Задаю вопрос, обладает ли сервера CallBook следующими характеристиками

• Распределённость администрирования.
• Распределённость хранения информации.
• Кеширование информации.
• Иерархическая структурой
• Резервирование.

UA3MQJ
30.11.2011, 18:28
Вот сижу я на даче. У меня в кармане Samsung SGH X-210. Что я смогу узнать с него? Ничего. Надо лезть в другой карман за подаренным Fly e-135, на нем хоть ява с сокетами работает. Ну а раз она работает, то можно на неё поставить программу, которая получит 1кб информации о позывном. Соединится с сервером TCP соединением и будет на нём висеть больше никого постороннего (типа DNS) и ни о чем не спрашивая.

Все очень просто. Есть программа - есть ответ!
Нет программы - нет ответа!
И совершенно нет никакой разницы есть ли на той стороне распределенность администрирования, хранения, кэширования, и какая структура у БД. Вот есть сервер qrz.ru и мы не знаем один он или 101, или может это кластер из 101 сервера, а логически сервер один...

Мысль использовать DNS как БД - интересная, но не более того. Такой способ нужно воспринимать только как вариант реализации.

Вот у меня была мысль скрестить сервер SAMBA и торрент систему на всех ПК предприятия. Так, чтобы файловый сервер хранил файлы в сети компьютеров. Но идея никого из моего окружения не удивила своей оригинальностью. Хотя там тоже распределенность, резервирование.

UT4UKW
30.11.2011, 19:13
Распределённость администрирования.
• Распределённость хранения информации.
• Кеширование информации.
• Иерархическая структурой
• Резервирование.

А зачем это все нужно? сколько там нашего брата... пару миллионов... так с такой задачей справится связка МySQL+PHP написанная на коленке за 20мин... и установленная на обычном ПК.. а дальше как хочешь так и получай информацию, хочешь с простой странички типа HamQTH а хочешь просто одной строкой...
Основная проблема ИМХО не в быстродействии, а в том что колбуков таких много и в котором из них самая актуальная информация не поймешь.

zibadun
30.11.2011, 21:54
Цитата:
Сообщение от RN3DLL
данные из DNS вы сможете получить быстрее на устройство чем с вэб сайта
Цена вопроса — доли секунды. В нашем деле это, конечно же, жизненно важно

ради интереса сравнил скорсть запросов через qrz.com XML API и .tel DNS NAPTR

QRZ.COM xml:
request HTTP h ttp://w ww.qrz.com/xml?;callsign=AA3B
...
response: 1148 bytes . response time: 123 ms

.tel NAPTR Query:
;; QUESTION SECTION:
;smallco.tel. IN NAPTR
....
;; Query time: 26 msec
;; MSG SIZE rcvd: 606


т.е. DNS ответил в 5 раз быстрее чем qrz.com XML feed