Редактирование: UNИX, осень 2008, 11 лекция (от 10 декабря)

Материал из eSyr's wiki.

Перейти к: навигация, поиск

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 39 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Текущая версия Ваш текст
Строка 1: Строка 1:
-
= Артём Гавриченков. Заканчивание рассказа про DNs. =
+
Артём Гавриченков. Заканчивание рассказа про DNs.
-
Как устроен резолвинг доменных имён?
+
Как устроен резолвинг доменных имён. Есть некоторый список корневых серверов (официально, 11), есть ряд доменов первого уровня, это нац. домены (ru, us, fr, tv) и домены общего назначения (com, org, name). Далее есть второго уровня и так далее.
-
Есть некоторый список корневых серверов (официально, 11), есть ряд доменов первого уровня, это нац. домены (ru, us, fr, tv) и домены общего назначения (com, org, name).
+
-
Далее есть второго уровня и т.п..
+
-
== Типы записей ==
+
Также мы успели поговорить, что во время резолвинга запрашиваем запись опр. типа (напримеР, если по имени неолбх. получить IP адрес), один из трёх типов записей: A (IPv4), AAAA (IPv6), A6 (IPv6, deprecated). Помимо этого есть ряд других типов записей: MX (лответственный за почту домен; за счёт этого работает доменная служба гугла: она обр. к серверу и смотрит на mx-запись, а она должна указывать на гугл), SRV (запись для серверов. умеет то же, что и mx, но для любого сервиса). Помимо этого, есть записи типа CNAME и PTR. Что такое cname: предположим, есть какой-то такой сервер, например, uneex.ru, и хочется разместить ftp-сервер с доменным именем ftp.uneex.ru, но второй сервер мы не хотим заводить, поэтому мы пишем CNAME и в нём указываем домен, на который надо смотреть. Есть ещё DNAME, он для зоны.
-
Также мы успели поговорить, что во время резолвинга запрашиваем запись определённого типа (например, если по имени необходимо получить IP адрес), один из трёх типов записей: A (IPv4), AAAA (IPv6), A6 (IPv6, deprecated).
+
Когда маленькие пушистые зверьки с альдебарана были маленькими и пушистыми, был /etc/hosts, у которого был очень простой формат. Очень легко командой grep искалось не олько соответствие имени зосту, но и хоста имени. На основе этого даже работала кое-какая диагностика. В году так 94, когда dns работал в полную силу, так, как сейчас, кто-то подсчитал, что уже в 94 году таким же обращом получить ip из системы dns хотя бы только по адр. типа A, делаем след. образом: пойти на первый попавшийся зост, посмотреть у него, пойти на след. и так далее. Понятно, что это долго. Поэтому была придумана запись PTR.
-
Помимо этого есть ряд других типов записей: MX (ответственный за почту домен; за счёт этого работает доменная служба гугла (Google DomainService): она обращается к серверу и смотрит на MX-запись, а она должна указывать на гугл), SRV (запись для серверов, умеет то же, что и MX, но для любого сервиса).
+
-
Помимо этого, есть записи типа CNAME и PTR.
+
-
=== Запись CNAME ===
+
Допустим, есть след. схема: Есть маршрутизатор, который маршрутизирует 192.x.x.x, далее есть марш., марш. 192.168.x.x, и так далее. Можно заметить, что деревья похожи. Собственно, их в RFC и объединили: ввели домен arpa, там поддомен in-addr, и далее ip: таким образом адрес 192.168.1.3 будет выглядить так: доменное имя строится от листа к корню (mirror.yandex.ru), таким же оббразом будем передавать записи типа PTR: 3.1.168.192.in-addr.arpa. Таким обр. очень просто получить имя хоста по имени. Кроме того, в RFC было записано, что для любого внешнего IP должна быть запись вида PTR. На самом еле это не выполняетсмя ни разу.
-
Что такое CNAME: предположим, есть какой-то такой сервер, например, uneex.ru, и хочется разместить ftp-сервер с доменным именем ftp.uneex.ru, но второй сервер мы не хотим заводить, поэтому мы пишем CNAME и в нём указываем домен, на который надо смотреть.
+
-
Есть ещё DNAME, он для зоны.
+
-
=== Запись PTR ===
+
И так сложилась жизнь, что благодаря этому сложилась возм. для фильтрации спама --- если приходит письмо с адреса, у которого нет PTR.
-
Когда маленькие пушистые зверьки с Альдебарана были маленькими и пушистыми, был '''/etc/hosts''', у которого был очень простой формат.
+
Ещё бывает Forward Confirmed Reverse DNS. Вот пришёл нам пакет с некоего адреса. По ptr получаем dns, по a получаем ip. Тогда это FCRDNS, если ip совпали. Только если это проходит, от хоста можно получать почту, иначе можно спокойно фильтровать, так как это хост, пор который провайдер не знает, что с него ходит почта. Т. о., помимо нач. цели, которой служил RDNS --- диагностика неполадок сети, появился второй пример использования --- проверка хоста на валидность.
-
Очень легко командой grep искалось не только соответствие имени хосту, но и хоста имени.
+
-
На основе этого даже работала кое-какая диагностика.
+
-
В году так 1994, когда DNS работал в полную силу (так, как сейчас), получить ip из системы dns хотя бы только по адресу типа A, можно было только следующим образом: пойти на первый попавшийся хост, посмотреть у него, пойти на след. и так далее.
+
Всё это хорошо, красиво и прекрасно было, пока не началось ipv6 заканчиваться. После чего начали раздавать не большие подсети, а поменьше. И тогда появилась сложность. Поскольку такая ситуация: нам выдали подсети из одной подсети C, в результате DNS один, а претендуют на него двое. После чего была придумана такая вещь: всесто записи типа PTR будет ыдаваться типа CNAME, и CNAME вида 1.corbin1.1.168.192 (для ip 192.168.1.1).
-
Понятно, что это долго.
+
-
Кто-то посчитал, что это заняло бы несколько недель.
+
-
Поэтому была придумана запись PTR.
+
-
Допустим, есть следующая схема: есть маршрутизатор, который маршрутизирует 192.x.x.x, далее есть маршрутизатор 192.168.x.x, и так далее.
+
Почему в ipv6 всё лучше: там не делегируются подсети меньше /64. Но при этом ращмер гранулирования --- полубайт: ...a.8.0.b.c.f.ip6.arpa.
-
Можно заметить, что деревья похожи.
+
-
Собственно, их в RFC и объединили: ввели домен arpa, там поддомен in-addr, и далее ip: таким образом адрес 192.168.1.3 будет выглядить так: доменное имя строится от листа к корню (mirror.yandex.ru), таким же образом будем передавать записи типа PTR:
+
Про whois.
-
3.1.168.192.in-addr.arpa.
+
-
Таким образом очень просто получить имя хоста по имени.
+
Адреса и подсети выдаются не абы каму. Для каждого владельца адреса существует инф. о нём (или о провайдере, который его выдал динамически). Сущ. сервис, который позв. выдать эту инф. для любого заданного адреса. Есть утилита whois и http://ripe.net. Можно запросить инф. о владельце адреса, о его конт. данныз, адпресе орг. и так далее.
-
Кроме того, в RFC было записано, что для любого внешнего IP должна быть запись вида PTR.
+
-
На самом деле это выполняется не всегда.
+
-
=== Практическая польза от PTR ===
+
Whois может исп. не только для получ. данных об ip, но и об доменном имени. Это работает.
-
И так сложилась жизнь, что благодаря этому появилась возможность для фильтрации спама --- если приходит письмо с адреса, у которого нет PTR, высока вероятность, что это спам, фильтруем.
+
-
Ещё бывает Forward Confirmed Reverse DNS.
+
Павел. Рассказывает, потому что напросился, а Гоша разрешил.
-
Вот пришёл нам пакет с некоего адреса.
+
-
По PTR получаем dns, а по A получаем ip.
+
-
Тогда это FCRDNS, если ip совпали.
+
-
Только если это проходит, от хоста можно получать почту, иначе можно спокойно фильтровать, так как это хост, про который провайдер не знает, что с него ходит почта.
+
Рассказывать парсер будет про RPC, и ему кажет, что он знает про rpc больше, чем некоторые из нас.
-
Таким образом, помимо начальной цели, которой служил RDNS --- диагностика неполадок сети, появился второй пример использования --- проверка хоста на валидность.
+
-
=== Ipv4 vs IPv6 ===
+
В википедии написано, что RPC позв. вызывать функции в другом адр. пространстве, но это ни о чём не говорит.
-
Всё это хорошо, красиво и прекрасно было, пока не началось ipv4 заканчиваться.
+
-
После чего начали раздавать не большие подсети, а поменьше.
+
-
И тогда появилась сложность.
+
-
Поскольку такая ситуация: нам выдали подсети из одной подсети C, в результате DNS один, а претендуют на него двое.
+
-
После чего была придумана такая вещь: вместо записи типа PTR будет выдаваться типа CNAME, и CNAME вида:
+
-
1.corbin1.1.168.192 (для ip 192.168.1.1).
+
-
Почему в ipv6 всё лучше: там не делегируются подсети меньше /64.
+
О цонцепции: Необх. в RPC возн. по нес. причинам
-
Но при этом размер гранулирования --- полубайт:
+
* Когда она возн. (в 70-х годах, когда был бум произв. машин, но в расп. сисит. есть компьютеры послоабже, посильнее, и кусок посложнее было бы круто считать на мощной машине)
-
...a.8.0.b.c.f.ip6.arpa.
+
* Рещшение задачи разд. ресурсов: принтеры, файлы, whatever
-
== Про Whois ==
+
Если вспомнить как пишется каноническое сетевое прилож с беркли сокетами, то это дост. рутинная операция.
-
Адреса и подсети выдаются не абы каму.
+
На самом деле, RPC как класс технологий, стандарта RPC нет, и каждый горазд созд. их сколько угодно, и их довольно меого, не все созд. вещи плохи.
-
Для каждого владельца адреса существует информация о нём (или о провайдере, который его выдал динамически).
+
-
Существует сервис, который позволяет выдать эту информацию для любого заданного адреса.
+
-
Есть утилита '''whois''' и http://ripe.net.
+
-
Можно запросить информацию о владельце адреса, о его контактных данных, адресе организации и так далее.
+
-
'''whois''' может использоваться не только для получения данных об ip, но и о доменном имени.
+
Open Network Communication RPC, кноничный RPC, про который есть RFC.
-
Это работает.
+
-
= Павел. RPC =
+
Как обычно, разраб. раньше, чем проектировался. И делать его начали для того, чтобы реализовывать NFS. Идея появлиась в 76 году, есть RFC 707. В заголовке рфц заложено, что главное в нём --- разд. ресурсов. В 86 была реализ. от сана, а в 88 было RFC. Вторая версия появилась в 95 году. Наверное, стоит рассм. с прогр. точки зрения, чем удалённый вызов отл. от локального.
-
Рассказывает, потому что напросился, а Гоша разрешил.
+
Как осущ. лок: у нас есть общеизв. место, через которое передаём параметры, и откуда рез. получаем (стек, регистры, память), дальше произв. пляска, в стек запис. параметры, точка возщвр. и так далее, всё это известно, поск. вып. в одном адр. пр-ве. И что делать в случае своего адр. пр-ва? Можно отобрадать, но это бред. Пожтому жёстко сказано, что всё предаётся по значеннию.
-
Рассказывать парсер будет про RPC, и ему кажется, что он знает про rpc больше, чем некоторые из нас.
+
В связи с c RPC есть два RFC : 1831, который опр. транспорт, и ...., который опр. формат данных.
-
В википедии написано, что RPC позволяет вызывать функции в другом адресном пространстве, но это ни о чём не говорит.
+
Почему так многор елази RPC: RFC? RJNJHSQ DJPV/ ZDK/ CNFYLFHNJV? UB,RBQ? YT YFRK/ JUHFYBXTYBQ? RFYJYBX HTFKBP ---вызов синхронный. RFC не говорито то том, что это нужно делать синхронно, и все совр. реализ. асинхронны. Понятно, в чём проблема синхр. вызова: вызвали и ждём --- или ждём, или аовторно дёргаем, но тогда непонятно, сколько раз она выполнена. Поэтому некие минимальные огр. на ранспорт нлаагаются, в част. сопост. ответа с запросом.
-
== О концепции ==
+
Как это работает: тобы вызвать на уд. зосте уд. функцию, нам нужно её идент: поэтому в RPC есть три беззн. значения --- номер программы, функции и версии. Тут интересно то, что номера возн. из бухты-барахзты, а ими заведует тот же sun. Если вы написали программу и хотите, тобы все о неё знали, то нужно написать e-mail на rpc@sun.com и сказать об этом.
-
Необходимость в RPC возникает по нескольким причинам:
+
Про утилиты, которые можно непоср. использовать: самая главная утилита --- rpcinfo. Он позв. обр. к серверу, на котором есть прогр., которая исп. уд. вызов процедур, и получать с него информацию. -p --- опц. указывается имя хоста, по этой команже клиент подкл. к уд. серверу, запр. множество программ, по этим программам выд. функции которые униз есть с версиями и именами. бычно там можно увдиеть nfs.
-
* Когда она возникает (в 70-х годах, когда был бум производства машин, но в распределённых системах есть компьютеры послабже и посильнее, и кусок посложнее было бы круто считать на мощной машине)
+
-
* Решение задачи разделения ресурсов: принтеры, файлы, whatever
+
-
Если вспомнить как пишется каноническое сетевое приложение с беркли-сокетами, то это достаточно рутинная операция.
+
Каким обр. мы соед. с уд. сервером: понятно, что rpcinfo соед. по какому-то порту. По какому? Можно догоовртиься, что исп. такой-то порт, поэтому порту rpc выделоен порт 111, где висит portmap, который и заведует всеми rpc-шными программами, и rpc-программы регистрируются в портмапе.
-
На самом деле, RPC это класс технологий, стандарта RPC нет, и каждый горазд создавать их сколько угодно, и их довольно много, не все созданные вещи плохи.
+
Третья часть доклада посвящена p2p, зовут дендика Алексеевский Даниил, и он имеет к этому некое косвенное отношение.
-
== ONC-RPC ==
+
Дендик выбрал неск. конкретных протоколов, о которых стоит расск. боьшле всего.
-
Open Network Communication RPC, каноничный RPC, про который есть RFC.
+
Что такое p2p? Это общая идея, как можно расп. данные в сети. До этого все проотколы осн. на клиент-серверной парадигме. В коакой-то момент люди посмотрели на ситуацию с HTTP и увидели, что есть клиенты, которые с него пост. что-то спрашивают, весь трафик в итоге ходит через канал сервера и серверу приходится много платить за трафик. Но если клиентов много, то наверняка наёдтся тот, у которого данные уже есть. В этом и осн. идея.
-
Как обычно, разрабатывался раньше, чем проектировался.
+
p2p-сети бывают разные по своей расп., и дендик начнёт с классификации. Степени расп. бывают такие:
-
И делать его начали для того, чтобы реализовывать NFS.
+
* Центр. сеть. Сеть, имеющ. центр. Сеть., расч. на то, что есть сервер, знает обо всех клиентах и у какого что есть. И когда приходит новый клиент, он спрашивает , где есть какой-то фалй
-
Идея появилась в 76 году, есть RFC 707.
+
* Промежут. стадия
-
В заголовке RFC заложено, что главное в нём --- разделение ресурсов.
+
* Полностью децентр. Клиент как-то приходит в сеть, поиском по сети пытается найти, что ему нужно. Такие сети бывают постр. на разных алгоритмах, но ...
-
В 86 была реализация от Sun, а в 88 было RFC.
+
-
Вторая версия появилась в 95 году.
+
-
Наверное, стоит рассмотреть с программистской точки зрения, чем удалённый вызов отличается от локального.
+
EDonkey. Обр. она неизв. когда. Как она устроена: по большей части это неизв, протокол закрытый, все реализ. протокола ..., есть смутное понятие сервера и клиента. Что творится между серверами, неизвестно. Клиенты есть двух типов: те клиенты, которые имеют возм. откр. соед. и слушать порт (High ID) и те, которые такой возм. не имеют (Low ID). Как происх. добыча данных из edonkey: во-первых, всякий файл ищется по его хэшу. Хэш исп. md4. Во вторых: чтобы получить файл, сервер занимается поиском, как --- неизв, в рез-те ответ ---- качай с сервера или с high id. Опять же неизв., могут ли серверы ретранслировать данные. Данные можно нарез. куски станд. аразмера --- примерно 10к, ходят с щэшом, можно получать распред. Некоотрым людям стало это в опр. момент не очень нравиться, и они стали докручивать это со стороны клиента. Например, держать у себя список клиентов и обмен. с соседями. В конце концов, нек. программы могут сущ. в таком режиме: получить списки клиентов и общ. только с клиентами, не тргая сервера. Но этоо опять таки чревато и неприятно, поск. это нестанд. расширения, по которому могут договориваться разве что два экз. одной программы. Ещё одна важная фишка6 в нём каким-то обр. реализ. поиск. на серверах, причём, судя по всему, поиска не было до первого неофиц. сервера.
-
Как осуществляется локальный вызов: у нас есть общеизвестное место, через которое передаём параметры, и откуда получаем результат (стек, регистры, память), дальше производится пляска, в стек записываются параметры, точка возврата и так далее, всё это известно, поскольку выполняется в одном адресном пространстве.
+
Далее, для развития edonkey люди начали изобр. свои протоколы. Один из них --- Kademlia. В основе лежит DHT --- Ditributed Hash Table. В чём её суть: сначала надо договориться о таких понятиях, как ID --- имя машины, Key и Value. Договорённость первая --- это строки какой-то длины, и важно, что Id и ключи имеют равную длину. Мы опр. функцию, которая по двум id или по паре id-ключ умеет находить расстояние. На этих двух предположениях строится довольно простой способ, как искать данные в сети, про котрую изнач. почти ничего неизв: есть машины, с id, кажая машина хранит списки машин для кажлого бита, у которых отличие в id нач. с данного бита. Поиск стр. на 4 операциях: ping (проверить, что машина жива), store и find. Можно попросить машину зранить кусочек данных (если мы уже знаём её ip, порт). Поиск ведётся след. образом: для поиска снач. надо получить ключ, потом ищем по списку в каждом из конц. кругов, и в каждом уруге примерно один. количество соседей и подд. дост.ю надёжные. Снач. ищется во внкутр. круге, нахдоим ососеда и просим найти его соседа, самых близких к данному ключу, адльше для след. и так далее. Понятно, как теперь найти машину, на которой хранится заданная битовая строчка. Теперь понятно, как это работает.
-
И что делать в случае чужого адресного пространства?
+
-
Можно отображать, но это бред.
+
-
Поэтому жёстко сказано, что всё предаётся по значению.
+
-
В связи с RPC есть два RFC: 1831, который определяет транспорт, и который определяет формат данных.
+
bit torrent. Возник протокол где-то в 2001 году, строился он именно вокруг этой самой идеи. РОн сост. из двух частей: чисто клиент-серверный протокол, у которого есть трекер, и есть клиенты, которые к нему подключ. Общение с торрентом начинается с .torrent, который содерж. два поля: всякая метаинф., например, на какие фрагменты нарезан файл, адрес трекера, поле, которое содерж. метаинф. о файлах --- список файлов и их размер, и в торренте хранится хэш каждого кусочка (чанка).
-
Почему так много реализаций RPC: RFC, который возможно является стандартом, гибкий, не накладывающий ограничений.
+
Трекер умеет вып. тодлько одну операцию --- какие клиенты с этим файлом ещё есть, Обычно, на трекерах реализ. разные хитрые политики: ....
-
Каноническая реализация --- вызов синхронный.
+
-
RFC не говорит о том, что это нужно делать синхронно, и все современные реализации асинхронны.
+
-
Понятно, в чём проблема синхронного вызова: вызвали и ждём --- или ждём, или повторно дёргаем, но тогда непонятно, сколько раз она выполнена.
+
Bittorrent постоянно расширяется, и недавно запихали в него такую вещь, что некие клиенты сами явл. трекерами. И при этом поиск трекеров ведётся через DHT.
-
Поэтому некие минимальные ограничения на транспорт налагаются, в частности сопоставление ответа с запросом.
+
-
Как это работает. Чтобы вызвать на удалённом хосте удалённую функцию, нам нужно её идентифицировать: поэтому в RPC есть три беззнаковых значения:
 
-
* номер программы
 
-
* номер функции
 
-
* номер версии
 
-
Тут интересно то, что номера не возникают из бухты-барахты, а ими заведует тот же Sun.
+
Конспект Kda:
-
Если вы написали программу и хотите, чтобы все о ней знали, то нужно написать e-mail на '''rpc@sun.com''' и сказать об этом.
+
-
 
+
-
== rpcinfo ==
+
-
Про утилиты, которые можно непосредственно использовать: самая главная утилита --- '''rpcinfo'''.
+
-
Она позволяет обращаться к серверу, на котором есть программа, которая использует удалённый вызов процедур, и получать с него информацию.
+
-
 
+
-
'''rpcinfo -p''' --- полезная опция: указываем имя хоста, по этой команде клиент подключается к удалённому серверу, запрашивает множество программ, по этим программам выдаются функции которые у них есть, с версиями и именами. Обычно там можно увидеть nfs.
+
-
 
+
-
Каким образом мы соединяемся с удалённым сервером: понятно, что rpcinfo соединяет по какому-то порту?
+
-
По какому?
+
-
Можно договориться, что используется такой-то порт, поэтому rpc выделен порт 111, где висит portmap, который и заведует всеми rpc-шными программами, и rpc-программы регистрируются в портмапе.
+
-
 
+
-
= Даниил Алеексеевский. Пиринговые протоколы. =
+
-
 
+
-
Третья часть доклада посвящена p2p, зовут дендика Алексеевский Даниил, и он имеет к этому некое косвенное отношение.
+
-
 
+
-
Дендик выбрал несколько конкретных протоколов, о которых стоит рассказать больше всего.
+
-
 
+
-
== Что такое p2p? ==
+
-
Это общая идея, как можно располагать данные в сети.
+
-
До этого все протоколы основывались на клиент-серверной парадигме.
+
-
В какой-то момент люди посмотрели на ситуацию с HTTP и увидели, что есть клиенты, которые с него постоянно что-то спрашивают, весь трафик в итоге ходит через канал сервера и серверу приходится много платить за трафик.
+
-
Но если клиентов много, то наверняка найдётся тот, у которого данные уже есть.
+
-
В этом и основная идея.
+
-
 
+
-
== Классификация ==
+
-
 
+
-
p2p-сети бывают разные по своей распределённости, и дендик начнёт с классификации.
+
-
 
+
-
Степени распределённости бывают такие:
+
-
* Централизованная сеть. Сеть, имеющая центр. Сеть, рассчитанная на то, что есть сервер, знает обо всех клиентах и у какого что есть. И когда приходит новый клиент, он спрашивает, где есть такой-то файл;
+
-
* Промежуточная стадия;
+
-
* Полностью децентрализованная. Клиент как-то приходит в сеть, поиском по сети пытается найти, что ему нужно. Такие сети бывают построены на разных алгоритмах, но нужно знать кого-либо из клиентов, чтобы подключиться
+
-
 
+
-
== EDonkey ==
+
-
 
+
-
Образовалась она неизвестно когда.
+
-
Как она устроена: по большей части это неизвестно, протокол закрытый, все реализации протокола ..., есть смутное понятие сервера и клиента.
+
-
Что творится между серверами, неизвестно.
+
-
Клиенты есть двух типов: те клиенты, которые имеют возможность открывать соединения и слушать порт (High ID) и те, которые такой возможности не имеют (Low ID).
+
-
 
+
-
Как происходит добыча данных из edonkey:
+
-
* всякий файл ищется по его хэшу. Хэш используется md4.
+
-
* чтобы получить файл, сервер занимается поиском, как --- неизвестно, в результате ответ ---- качай с сервера или с high id.
+
-
Опять же неизвестно, могут ли серверы ретранслировать данные.
+
-
Данные можно нарезать на куски стандартного размера --- примерно 10к, ходят с хешом, можно получать распределённо.
+
-
 
+
-
Некоторым людям стало это в определённый момент не очень нравиться, и они стали докручивать это со стороны клиента.
+
-
Например, держать у себя список клиентов и обмениваться с соседями.
+
-
В конце концов, некоторые программы могут существовать в таком режиме: получить списки клиентов и общаться только с клиентами, не трогая сервера.
+
-
 
+
-
Но это опять-таки чревато и неприятно, поскольку это нестандартное расширение, по которому могут договориваться разве что два экземпляра одной программы.
+
-
Ещё одна важная фишка: в нём каким-то образом реализован поиск на серверах, причём, судя по всему, поиска не было до первого неофициального сервера.
+
-
 
+
-
== Развитие EDonkey ==
+
-
 
+
-
Далее, для развития edonkey люди начали изобретать свои протоколы.
+
-
Один из них --- Kademlia.
+
-
В основе лежит DHT --- Distributed Hash Table.
+
-
 
+
-
В чём её суть: сначала надо договориться о таких понятиях, как ID --- имя машины, Key и Value.
+
-
Договорённость первая --- это строки какой-то длины, и важно, что Id и ключи имеют равную длину.
+
-
Мы определяем функцию, которая по двум id или по паре id-ключ умеет находить расстояние.
+
-
 
+
-
На этих двух предположениях строится довольно простой способ, как искать данные в сети, про которую изначально почти ничего неизвестно, есть машины, с id, каждая машина хранит списки машин для каждого бита, у которых отличие в id начинается с данного бита.
+
-
 
+
-
Поиск строится на 4 операциях:
+
-
* ping (проверить, что машина жива)
+
-
* store
+
-
* find_node - искать N штук ID, самых ближних к ключу
+
-
* find_value - то же, но заодно и искать по ключу у себя
+
-
 
+
-
Можно попросить машину сохранить кусочек данных (если мы уже знаём её ip, порт).
+
-
Поиск ведётся следующим образом: для поиска сначала надо получить ключ, потом ищем по списку в каждом из концевых кругов, и в каждом круге примерно одинаковое количество соседей и подд. дост. надёжные.
+
-
 
+
-
Сначала ищется во внутреннем круге, находим соседа и просим найти его соседа, самых близких к данному ключу, дальше для следующего и так далее.
+
-
Понятно, как теперь найти машину, на которой хранится заданная битовая строчка.
+
-
Теперь понятно, как это работает.
+
-
 
+
-
== bit torrent ==
+
-
Возник протокол где-то в 2001 году, строился он именно вокруг этой самой идеи.
+
-
 
+
-
Он состоит из двух частей:
+
-
* чисто клиент-серверный протокол, у которого есть трекер
+
-
* клиенты, которые к нему подключены
+
-
Общение с торрентом начинается с .torrent, который содержит два поля: всякая метаинформация, например, на какие фрагменты нарезан файл, адрес трекера, поле, которое содержит метаинформацию о файлах --- список файлов и их размер, и в торренте хранится хэш каждого кусочка (чанка).
+
-
 
+
-
Трекер умеет выполнять только одну операцию --- какие клиенты с этим файлом ещё есть.
+
-
Обычно, на трекерах реализуются разные хитрые политики: ....
+
-
 
+
-
Bittorrent постоянно расширяется, и недавно запихали в него такую вещь, что некие клиенты сами являются трекерами.
+
-
И при этом поиск трекеров ведётся через DHT.
+
-
 
+
-
= Экзамен =
+
-
17 числа будет экзамен здесь, в 6 часов.
+
-
 
+
-
Нужно посылать письмо на адрес george@po.cs.msu.su с темой Экзамен за два-три дня.
+
-
 
+
-
На uneex.ru/LecturesCMC это написано.
+
-
 
+
-
= Конспект Kda: =
+
Георгий Владимирович уехал в Петербург и попросил его заменить на лекцию.
Георгий Владимирович уехал в Петербург и попросил его заменить на лекцию.
Строка 374: Строка 228:
Клиент подключается на 111 порт и запрашивает информацию.
Клиент подключается на 111 порт и запрашивает информацию.
-
Выступает Алексеевский Даниил.
+
Выступает Алексей.
Рассказ о p2p.
Рассказ о p2p.
Общая идея о распространении данных в сети.
Общая идея о распространении данных в сети.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!


Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.name/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2008%2C_11_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_10_%D0%B4%D0%B5%D0%BA%D0%B0%D0%B1%D1%80%D1%8F%29
Разделы