Войти
 | |
| Разработчик (и) | Арвид Норберг |
|---|---|
| Первый выпуск | сентябрь 2005 г.; 15 лет назад (2005-09) |
| Стабильный выпуск | 2.0 (6 сентября 2020 г.; 50 дней назад (2020-09-06)) |
| Репозиторий | github.com / arvidn / libtorrent / |
| Написано на | C ++ |
| Доступно на | английском языке |
| Тип | BitTorrent библиотека |
| Лицензия | Лицензия BSD |
| Веб-сайт | libtorrent.org |
libtorrent - это реализация с открытым исходным кодом протокола BitTorrent. Он написан на C ++ и имеет его основной интерфейс библиотеки. Его наиболее заметными особенностями являются поддержка Mainline DHT, IPv6, начальных значений HTTP и однорангового обмена μTorrent. libtorrent использует Boost, в частности Boost.Asio, чтобы добиться независимости от платформы. Известно, что он основан на Windows и большинстве Unix-подобных операционных систем (OS X, Linux и многих BSD. ).
libtorrent постоянно обновляется с помощью расширений bittorrent, которые разработчики считают наиболее полезными, и активно оптимизируется для работы в более широком наборе сред. Многие из его функций могут быть отключены во время компиляции, чтобы не включать код, который не будет использоваться в конкретном случае использования. Он стремится быть наиболее подходящей реализацией libtorrent для встраиваемых устройств, а также настольных компьютеров и сид-серверов. Некоторые детали его реализации описаны в разделе функций.
Первоначальным автором libtorrent является Арвид Норберг. Это первый клиент, поддерживающий протокол расширения вместе с μTorrent, который теперь является основой, на которой строятся многие другие расширения.
BEP являются частью процесса предложения по расширению BitTorrent. BEP - это проектный документ, предоставляющий информацию сообществу BitTorrent или описывающий новую функцию для протоколов BitTorrent. BEP должен содержать краткую техническую спецификацию функции и ее обоснование. Они были предназначены для использования в качестве основных механизмов для предложения новых функций, для сбора комментариев сообщества по проблеме и для документирования проектных решений, которые были приняты в BitTorrent. Автор BEP несет ответственность за достижение консенсуса в сообществе и документирование особых мнений.
Поскольку BEP поддерживаются как текстовые файлы с измененной структурой в репозитории с контролем версий, их история изменений является исторической записью предложения функции
Существует три вида BEP:
| BEP № | Заголовок | Примечание |
|---|---|---|
| 3 | BitTorrent протокол | |
| 5 | DHT протокол | без трекера торренты, Mainline Kademlia протокол DHT |
| 7 | IPv6 Tracker Extension | |
| 9 | Extension for Peers to Send Files Metadata Files | протокол передачи метаданных, включает магнитные ссылки |
| 10 | Extension Protocol | |
| 11 | Peer exchange | uTorrent PEX |
| 12 | Multitracker Metadata Расширение | также поддерживает μTorrent интерпретацию |
| 14 | Local Peer Discovery | |
| 15 | UDP Tracker Протокол для BitTorrent | |
| 16 | Super-seeding | |
| 17 | HTTP-заполнение | Hoffman-style |
| 19 | WebSeed - HTTP / FTP-заполнение (стиль GetRight) | |
| 21 | Частичная загрузка исходных данных | |
| 24 | Tracker Возвращает внешний IP-адрес | |
| 27 | Private Торренты | |
| 29 | Транспортный протокол uTorrent | начиная с версии 0.16.0 |
| 30 | хэш Меркла | начиная с версии 0.15 |
| 32 | BitTorren t DHT Extensions для IPv6 | начиная с 1.2 |
| 33 | DHT очищает | с 0.16 |
| 38 | изменяемые торренты | с 1.1 |
| 40 | канонический приоритет однорангового узла | с 1.0 |
| 43 | узлы DHT только для чтения | с 1.0.3 |
| 44 | DHT помещает / получает | с 1.0 |
| 47 | файлы заполнения и атрибуты файлов | с 0.15 |
| 51 | DHT infohash indexing | с 1.2 |
| 52 | Спецификация протокола BitTorrent v2 | с 2.0 |
| 53 | Выбор файла магнитной ссылки | с 1.2 |
| 55 | Расширение Holepunch |
Весь дисковый ввод-вывод в libtorrent выполняется асинхронно, чтобы сетевой поток, поток io диска. Когда блок читается, поток disk io считывает все последующие блоки из этого блока в кэш чтения, предполагая, что узел, запрашивающий блок, также запросит дополнительные блоки из того же блока. Это уменьшает количество системных вызовов для чтения данных. Это также уменьшает задержку поиска.
Точно так же для запросов на запись блоки кэшируются и сбрасываются на диск после завершения одного полного фрагмента, или фрагмент является наименее недавно обновленным, когда требуется больше места в кэше. Кэш динамически распределяет пространство между кешем записи и чтения. Кэш записи имеет строгий приоритет перед кешем чтения.
Используемые блоки кэша заблокированы в физической памяти, чтобы избежать ее выгружения на диск. Разрешение выгрузки дискового кэша на диск означает, что его очистка станет крайне неэффективной, поскольку его придется считывать обратно в физическую память только для того, чтобы снова сбросить на диск.
Для экономии памяти и системных вызовов файловые операции iovec используются для очистки нескольких блоков кэша за один вызов.
В системах с низким объемом памяти кэш диска можно полностью отключить или установить меньший предел для экономии памяти.
На процессорах с небольшим кэшем L2 копирование памяти может быть дорогостоящей операцией. Важно свести к минимуму количество копий на таких машинах. В основном это относится к встроенным системам.
Чтобы минимизировать количество копий полученных данных, буфер приема для данных полезной нагрузки принимается непосредственно в дисковый буфер, выровненный по страницам. Если соединение зашифровано, буфер расшифровывается на месте. Затем буфер перемещается в кеш диска без копирования. После того, как все блоки для части получены или необходимо очистить кеш, все блоки передаются непосредственно в writev (), чтобы сбросить их за один системный вызов. Это означает одну копию в памяти пользовательского пространства и одну копию обратно в память ядра.
При заполнении и загрузке в целом ненужное копирование предотвращается за счет кэширования блоков в выровненных буферах, которые копируются один раз в буфер отправки однорангового узла. Выравнивание буфера отправки однорангового узла не гарантируется, даже если это происходит в большинстве случаев. Затем буфер отправки шифруется с помощью специального ключа однорангового узла и связывается с iovec для отправки. Это означает, что существует одна копия пользовательского пространства, чтобы разрешить невыровненные запросы одноранговых узлов и шифрование, специфичное для одноранговых узлов.
Сборщик фрагментов - центральный компонент в реализации BitTorrent. Сборщик произведений в libtorrent оптимизирован для быстрого поиска самых редких произведений. В нем хранится список всех доступных предметов, отсортированных по редкости, и перемешанные предметы той же редкости. Самый редкий первый режим - доминирующий режим сборщика предметов. Другие режимы также поддерживаются и используются одноранговыми узлами в определенных ситуациях.
Сборщик штук позволяет комбинировать наличие штуки с приоритетом. Вместе они определяют порядок сортировки списка штук. Фрагменты с приоритетом 0 никогда не будут выбраны, что используется для функции выборочной загрузки.
Чтобы иметь как можно меньше частично готовых деталей, одноранговые узлы имеют склонность выбирать блоки из тех же деталей, что и другие одноранговые узлы в той же категории скорости. Категория скорости - это грубая категоризация одноранговых узлов на основе их скорости загрузки. Это заставляет медленные одноранговые узлы выбирать блоки из одного и того же фрагмента, а быстрые узлы - из одного и того же, что снижает вероятность того, что медленные узлы блокируют завершение фрагментов.
Сборщик деталей также может быть настроен на последовательную загрузку деталей.
Это BEP30 протокола BitTorrent. Хеш-дерево Меркла торренты - это расширение, которое позволяет торрент-файлу содержать только корневой хеш хеш-дерева, образующего хэши частей. Основное преимущество этой функции заключается в том, что независимо от того, сколько частей содержится в торренте, файл.torrent всегда будет одного размера. Он будет только расти с увеличением количества файлов (так как он все еще должен содержать имена файлов).
При использовании обычных торрентов клиенты должны запрашивать несколько блоков для частей, как правило, от разных одноранговых узлов, прежде чем данные можно будет проверить по хешу части. Чем крупнее части, тем больше времени потребуется, чтобы загрузить целую часть и проверить ее. До того, как кусок будет проверен, он не может быть передан рой, что означает, что чем больше размер куска, тем медленнее будут данные оборачиваемости, когда они загружаются одноранговыми узлами. Поскольку в среднем данные должны сидеть и ждать в буферах клиентов, прежде чем они будут проверены и могут быть загружены снова.
Другая проблема с большими размерами частей заключается в том, что клиенту труднее определить злонамеренного или ошибочного партнера, когда часть выходит из строя, и потребуется больше времени, чтобы повторно загрузить ее и предпринять больше попыток, прежде чем часть будет успешной. тем больше кусочки.
Размер фрагмента в обычных торрентах - это компромисс между размером самого файла.torrent и размером фрагмента. Часто для файлов размером 4 ГБ размер фрагмента составляет 2 или 4 МБ, чтобы не сделать файл.torrent слишком большим.
Торренты Merkle решают эти проблемы, устраняя компромисс между размером.torrent и размером фрагмента. При использовании торрентов Merkle размер фрагмента может быть минимальным размером блока (16 КБ), что позволяет одноранговым узлам немедленно проверять каждый блок данных, полученных от одноранговых узлов. Это дает минимальное время обработки и полностью снимает проблему выявления злонамеренных узлов.
Некоторые приложения, использующие libtorrent:
Портал бесплатного программного обеспечения с открытым исходным кодом 