BitTorrent/Термины: различия между версиями

Содержимое удалено Содержимое добавлено
Строка 54:
* [[w:en:BitTorrent protocol encryption|Wikipedia: BitTorrent protocol encryption]]{{ref-en}}
 
Хто це тут розпиздівся?
== Разные термины ==
=== Раздача ===
Этот процес проходит по пизде трекера
 
=== Пир ===
(англ. <tt>peer</tt> — <tt>соучастник</tt>) — клиент, участвующий в раздаче. Иногда пирами называют только скачивающих участников.
 
=== Сид ===
(англ. <tt>seeder</tt> — <tt>сеятель</tt>) — пир, имеющий все сегменты распространяемого файла, то есть либо начальный распространитель файла, либо уже скачавший весь файл.
 
=== Личер ===
(англ. <tt>leech</tt> — <tt>пиявка</tt>) — пир, не имеющий пока всех сегментов, то есть продолжающий скачивание. Термин часто употребляется и в негативном смысле, который он имеет в других файлообменных сетях: пользователь, который отдает гораздо меньше, чем скачивает.
 
=== Рой ===
(англ. <tt>swarm</tt>) — совокупность всех пиров, участвующих в раздаче.
 
=== Доступность ===
(англ. <tt>availability</tt>) (также <tt>distributed copies</tt>) — количество полных копий файла, доступных клиенту. Каждый сид добавляет 1.0 к этому числу, личеры увеличивают доступность в зависимости от количества скачанного, которого нет у других личеров. К примеру, если на раздаче есть один сид и два личера с 50%, и скачанные части равны между собой, то доступность равна 1.50.
 
=== Рейтинг(ратио) ===
(англ. <tt>share ratio</tt>) — отношение отданного к скачанному. Часто на трекерах выставленно ограничение на кол-во одновременно скачиваеммых файлов при маленьком <tt>рейтинге(ратио)</tt>.
 
=== Announce ===
 
Обращение клиента к трекеру.
 
При каждом <tt>announce</tt> клиент передаёт на трекер информацию об объёмах им скачанного и отданного, a трекер передаёт клиенту список адресов других клиентов.
 
Обращение клиента к трекеру происходит через определённые интервалы времени, которые определяются настройками клиента и трекера.
 
=== Announce URL ===
 
Адрес трекера, к которому клиент делает <tt>announce</tt>. Во многих клиентах называется <tt>Tracker URL</tt>. Может включать passkey.
 
=== Scrape ===
 
Дополнительный протокол запроса клиента к трекеру, при котором трекер сообщает клиенту общее количество сидов и пиров на раздаче.
 
В отличие от <tt>announce</tt>, запрос <tt>scrape</tt>:
* не имеет прямого отношения к скачиванию раздачи
* является необязательным
* может запрашиваться и для остановленных в клиенте заданий
* отнимает меньше ресурсов и клиента и трекера
* может одним запросом получить информацию сразу по нескольким торрентам (<tt>multi-scrape</tt>)
 
Клиент с помощью scrape может показать пользователю точные количества сидов и пиров на каждом задании, включая остановленнные.
 
Некоторые клиенты, например Azureus, также могут с помощью <tt>scrape</tt>:
* раньше узнать о том, что на раздаче появились дополнительные участники, и сделать внеочередной <tt>announce</tt> для получения их адресов
* автоматически останавливать и запускать сидирование заданий в зависимости от числа сидов и пиров, в результате сидируя там, где это нужнее
 
Для уменьшения бесполезной нагрузки на клиент и на трекер <tt>scrape</tt> в клиенте лучше выключить. Включайте <tt>scrape</tt> только если он вам действительно нужен, и админы вашего трекера подтвердили, что их трекер поддерживает <tt>scrape</tt>. Существует мнение, что большинство русскоязычных трекеров <tt>scrape</tt> не поддерживают.
 
См. также
* [http://wiki.theory.org/BitTorrentSpecification#Tracker_.27scrape.27_Convention wiki.theory.org: Scrape]{{ref-en}}
* [http://www.azureuswiki.com/index.php/Scrape Azureus Wiki: Scape]{{ref-en}}
 
=== Файл метаданных ===
[[BitTorrent|BitTorrent]] не имеет системы поиска: для каждого распространяемого файла создаётся файл метаданных с расширением <tt>torrent</tt>, который содержит следующую информацию:
 
* URL трекера (см. ниже).
* общую информацию о закачиваемом файле (имя, длину и пр.)
* контрольные суммы (точнее, хэш-суммы SHA1) сегментов закачиваемого файла.
 
<tt>Файлы метаданных</tt> могут распространяться через любые каналы связи — например, эти файлы (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публиковаться в блогах или новостных лентах RSS.
 
Клиент начинает закачку, получив каким-либо образом файл с метаданными, в котором есть ссылка на трекер.
 
=== Трекер ===
(англ. <tt>tracker</tt>) — специализированный сервер, работающий по протоколу HTTP. <tt>Трекер</tt> нужен для того, чтобы клиенты могли найти друг друга. Фактически, на <tt>трекере</tt> хранятся IP-адреса и входящие порты клиентов и хэш-суммы, уникальным образом идентифицирующие объекты, участвующие в закачках. По стандарту, имена файлов на трекере не хранятся, и узнать их по хэш-суммам нельзя. В практических реализациях, однако, <tt>трекер</tt> часто, помимо своей основной функции, выполняет и функцию небольшого веб-сервера. Такой сервер хранит файлы метаданных и описания распространяемых файлов, предоставляет статистику закачек по разным файлам, показывает текущее количество подключенных пиров и пр.
 
=== Супер сид ===
(англ. <tt>Super seeding</tt>) — является особенностью некоторых клиентов [[BitTorrent|BitTorrent]], которые пытаются минимизировать объём данных до первого завершения загрузки пира. Это было задумано Джоном Хофманом и сначала было осуществлено на клиенте BitTornado в середине 2003 г. Эта особенность должна использоваться, когда есть только один сидер. Super seeding характеризуется изменением в поведении сидеров и не может быть осуществлено без нарушения протокола [[BitTorrent|BitTorrent]]. Тем не менее, это не утверждается ни разработчиком протокола, Брэмом Коэном, ни в официальном клиенте. <tt>Супер-сид</tt> заставляет пользователей делиться скачаным. Отдав одному участнику какую-либо часть файла, твой клиент ничего больше ему не даст, пока не увидит в сети вторую копию этой части. Естественно, общая скорость отдачи падает. Как только ты переключаешься в обычный режим, твой клиент начинает раздавать всем, кто чего попросит,и скорости возрастают. <tt>Супер-сид</tt> эффективен при раздачах с большим количеством качающих. Если качающих 2-3 человека и их клиенты в силу разных причин отказались устанавливать связь друг с другом, все сидят и ждут, когда именно твой клиент их осчастливит, поскольку обмена между ними нет. Когда качающих много (ну, пусть 10-20 человек), из экономии достаточно раздать до коэффициента 1. Тогда в сети окажутся все части файла и пиры смогут ими обменяться.