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

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

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

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

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

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

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

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


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

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

Получено с http://esyr.org/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
Личные инструменты
Разделы