И опять про P2PNS
Feb. 27th, 2012 04:51 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
doldoniusПросто собираю мысли в кучку.
Что есть и к чему стремиться:
Еще подумать:
А еще вредно много писать на баше. Так и норовлю вместо "</tag>" ляпнуть "<gat>".
Что есть и к чему стремиться:
| DNS | P2PNS |
|---|---|
| Иерархическая система. | Узел считается "хозяином" захваченных им доменов; в остальном система плоская. |
| Авторитетные серверы для доменов известны только серверам более высокого уровня. | Все знают всех. |
| Имена в доменах, серверы которых недоступны, узнать невозможно. | Каждый узел хранит возможно полную копию всей таблицы имен-адресов. |
| Существует платная система регистратур, которые могут в любой момент отменить делегирование. | Регистрация домена осуществляется бесплатно, явочным порядком; пока узел ведет себя прилично, никто у него домен не отнимет. |
| Существуют корневые серверы, без которых вся система быстро перестанет работать. | Более-менее актуальную информацию можно получить, пока жива хотя бы часть пиров. |
| Доменные имена продают и покупают. | Тоже возможно, но заведомые сквоттеры рискуют угодить в черный список. |
| Домен освобождается тогда, когда истекает срок оплаты. | Домен освобождается, если самой свежей записи исполнилось, допустим, 32 миллиона секунд. |
| Записи считаются валидными в течение установленного времени. Пока оно не истекло, конечные пользователи могут получать устаревшие данные. | Запись считается валидной год с лишним, но изменения попадают к пирам так быстро, как только возможно. |
| Нагрузка на серверы пропорциональна их рангу. Корневые загружены по самые уши. | Пиры стараются распределить нагрузку. |
Еще подумать:
- Надо как-то ограничить число "соседей", которым узел пихает данные, иначе начнется лишняя реверберация. И при этом избежать развала системы на изолированные области. Смутно подозреваю, что должно существовать математическое решение, "но доказать не могу".
- Проверка свободности имени узла и домена, особенно удачная, дело хлопотное. По уму, надо опросить всех пиров. Нужно хорошенько продумать процедуру, чтобы негодяй не мог зафлудить систему запросами.
А еще вредно много писать на баше. Так и норовлю вместо "</tag>" ляпнуть "<gat>".
no subject
Date: 2012-02-28 03:56 am (UTC)no subject
Date: 2012-02-28 07:06 am (UTC)no subject
Date: 2012-02-28 07:53 am (UTC)no subject
Date: 2012-03-01 09:05 am (UTC)Каждый хост имеет уникальный идентификатор фиксированной длины, обычно это криптографический ключ в 20 байт.
Каждый файл в системе имеет уникальный ключ такой же длины -- хеш имени файла.
Файл хранится на всех хостах, ключ которых похож на ключ этого файла, т.е. отличается всего на несколько бит.
Клиент, которому нужен файл, вычисляет ключ его имени и отправляет в сеть.
Дальше возможны варианты -- как хосты договариваются, как находят друг друга, как проверяют, можно ли доверять пиру, и тому подобное.
Самое близкое к задаче распределенного DNS, что мне пока встретилось, это http://freenetproject.org/understand.html. Залишайтеся на нашiй хвилi, далi буде.
no subject
Date: 2012-03-01 09:39 am (UTC)Впрочем, ОК, жду.
no subject
Date: 2012-03-07 09:23 pm (UTC)В общем, мысль такая.
1) Каждый хост имеет уникальный случайный ID.
2) Сам по себе ID ценности не имеет; если мы впервые подключились к сети и узнали, что кто-то уже этот ID занял, мы просто генерируем новый.
Если мы не собираемся держать свой сайт, то мы представляемся в сети только своим ID. (Наша машина тоже будет обеспечивать работу сети - хранить и выдавать какую-то информацию об именах, хэши которых похожи на наш ID.)
Если собираемся, и хотим себе имя первого уровня, то
3) Вычисляем хэш имени.
4) Находим хосты, чьи ID похожи на этот хеш,
5) Спрашиваем у них, занято ли это имя.
В идеальном случае они дружно отвечают "занято" либо "свободно". Если занято, уходим придумывать новое имя.
Если свободно, просим их запомнить наши имя и IP-адрес, а также наш публичный криптографический ключ. Это надо на случай, если мы сменим IP и попросим хосты, которые отвечают за наше имя, запомнить новый адрес -- они смогут переспросить и убедиться, что это и правда мы.
Если случай не идеальный, и часть хостов отвечает "имя занято", а часть "свободно", тогда мы уведомляем все эти хосты, что пришел момент для Instant Carma. Пусть они ругаются друг с дружкой и владельцем имени и выясняют, жив ли владелец, у кого устаревшая информация и т.д. Через пол-часа спрашиваем у выживших, свободно ли имя.
no subject
Date: 2012-03-08 02:22 am (UTC)И вообще, что-то меня тут тревожит. Я планировал держать на каждом узле возможно полную копию справочника. Если узел держит только часть, убиваемость системы в целом возрастает. И круглосуточная доступность данных не очень-то обеспечивается (допустим, нужный нам адрес по случайному совпадению хранится только на узлах в Катманду — а тут бац, и Катманду обесточили).
Ну и, опять-таки, коллизии.
no subject
Date: 2012-03-07 09:29 pm (UTC)