libtorrent es una implementación de código abierto del protocolo BitTorrent . Está escrito y tiene su interfaz de biblioteca principal en C ++ . Sus características más notables son el soporte para Mainline DHT , IPv6 , semillas HTTP y el intercambio de pares de μTorrent . libtorrent usa Boost , específicamente Boost.Asio para obtener su independencia de plataforma. Se sabe que se basa en Windows y la mayoría de los sistemas operativos similares a Unix ( OS X , Linux y muchos BSD ).
Desarrollador (es) | Arvid Norberg |
---|---|
Versión inicial | Septiembre de 2005 |
Lanzamiento estable | 2.0.3 [1] (28 de marzo de 2021 ) [±] |
Repositorio | github |
Escrito en | C ++ |
Disponible en | inglés |
Tipo | Biblioteca BitTorrent |
Licencia | Licencia BSD |
Sitio web | libtorrent |
libtorrent se mantiene actualizado con las extensiones de bittorrent que los desarrolladores consideran más útiles, y se está optimizando activamente para funcionar en un conjunto más amplio de entornos. Muchas de sus funciones se pueden desactivar en tiempo de compilación para no incluir código que no se usaría en un caso de uso particular. Su objetivo es ser la implementación de libtorrent más adecuada para dispositivos integrados, así como para computadoras de escritorio y servidores semilla. Algunos de los detalles de su implementación se describen en la sección de características.
El autor original de libtorrent es Arvid Norberg. Es el primer cliente que admite el protocolo de extensión junto con μTorrent , que ahora es una base sobre la que se basan muchas otras extensiones.
Características
BEP implementados
Los BEP son parte del proceso de propuesta de mejora de BitTorrent. Un BEP es un documento de diseño que proporciona información a la comunidad BitTorrent o describe una nueva característica de los protocolos BitTorrent. El BEP debe proporcionar una especificación técnica concisa de la función y una justificación para la función. Se pretendía que fueran los mecanismos principales para proponer nuevas funciones, para recopilar las opiniones de la comunidad sobre un problema y para documentar las decisiones de diseño que se tomaron en BitTorrent. El autor de BEP es responsable de generar consenso dentro de la comunidad y de documentar las opiniones disidentes.
Debido a que los BEP se mantienen como archivos de texto reestructurados en un repositorio versionado, su historial de revisión es el registro histórico de la propuesta de función [2]
Hay tres tipos de BEP:
- Un BEP de seguimiento de estándares describe una extensión de uno de los protocolos de BitTorrent o un cambio en el comportamiento de uno de los actores en estos protocolos, donde los actores son actualmente clientes, rastreadores y servidores web.
- Un BEP informativo describe un problema de diseño de BitTorrent o proporciona pautas generales o información a la comunidad de BitTorrent, pero no propone una extensión. Los BEP informativos no representan necesariamente un consenso o recomendación de la comunidad de BitTorrent, por lo que los usuarios e implementadores son libres de ignorar los BEP informativos o seguir sus consejos.
- Un proceso BEP describe un proceso que rodea a BitTorrent o propone un cambio (o un evento en) un proceso. Los BEP de proceso son como los BEP de seguimiento de estándares, pero se aplican a áreas distintas de los protocolos BitTorrent. Son más que recomendaciones y, por lo general, los usuarios no tienen la libertad de ignorarlas. Los ejemplos incluyen programas de lanzamiento, procedimientos, pautas, cambios en el proceso de toma de decisiones y cambios en las herramientas o el entorno utilizados en el desarrollo de BitTorrent.
BEP # | Título | Nota |
---|---|---|
3 | Protocolo BitTorrent | |
5 | Protocolo DHT | torrents sin seguimiento , protocolo Mainline Kademlia DHT |
7 | Extensión del rastreador IPv6 | |
9 | Extensión para que los pares envíen archivos de metadatos | protocolo de transferencia de metadatos, habilita enlaces magnéticos |
10 | Protocolo de extensión | |
11 | Intercambio de pares | uTorrent PEX |
12 | Extensión de metadatos multipista | también es compatible con la interpretación μTorrent |
14 | Descubrimiento de Pares Locales | |
15 | Protocolo de seguimiento UDP para BitTorrent | |
dieciséis | Super-siembra | |
17 | Inicialización HTTP | Estilo Hoffman |
19 | WebSeed: propagación HTTP / FTP (estilo GetRight) | |
21 | Solo carga de semillas parciales | |
24 | El rastreador devuelve IP externa | |
27 | Torrents privados | |
29 | Protocolo de transporte uTorrent | desde 0.16.0 [3] |
30 | Hachís merkle | desde 0.15 [4] |
32 | Extensiones DHT de BitTorrent para IPv6 | desde 1.2 |
33 | Raspado DHT | desde 0.16 [5] |
38 | torrents mutables | desde 1.1 [6] |
40 | prioridad canónica de pares | desde 1.0 [7] |
43 | nodos DHT de solo lectura | desde 1.0.3 [8] |
44 | DHT poner / obtener | desde 1.0 [9] |
47 | archivos pad y atributos de archivo | desde 0.15 [10] [11] |
51 | Indexación DHT infohash | desde 1.2 |
52 | La especificación del protocolo BitTorrent v2 | desde 2.0 |
53 | Selección de archivo de enlace magnético | desde 1.2 |
55 | Extensión de perforadora |
Lista de funciones varias
- interfaz de complemento para implementar extensiones bittorrent personalizadas sin tener que modificar libtorrent
- admite el protocolo de intercambio de pares μTorrent (PEX).
- admite el descubrimiento de pares locales (multidifusión para pares en la misma red local)
- rastreador raspa
- admite la extensión lt_trackers, para intercambiar rastreadores entre pares
- admite la extensión no_peer_id = 1 que aliviará la carga de los rastreadores.
- admite el parámetro de seguimiento compact = 1.
- soporte para torrents merkle hash tree. Esto hace que el tamaño de los archivos torrent se adapte bien al tamaño del contenido.
- utiliza un hilo de E / S de disco separado para que el disco nunca se bloquee en la red o en la interacción del cliente.
- admite archivos de más de 2 gigabytes en sistemas que lo admitan.
- Soporte de reanudación rápida, una forma de deshacerse de la costosa verificación de piezas al comienzo de un torrent reanudado. Guarda el estado de almacenamiento, el estado de piece_picker y todos los pares locales en un archivo separado de reanudación rápida.
- tiene un caché de disco de lectura y escritura ajustable para mejorar el rendimiento del disco.
- pone en cola los torrents para la verificación de archivos, en lugar de verificarlos todos en paralelo.
- no tiene ningún requisito sobre el pedido de piezas en un torrente que se reanuda. Esto significa que puede reanudar un torrent descargado por cualquier cliente.
- admite archivos dispersos y asignación de archivos compactos (donde las piezas se mantienen consolidadas en el disco)
- modo semilla, donde se supone que los archivos en el disco están completos, y el hash de cada pieza se verifica la primera vez que se solicita.
- ajusta la longitud de la cola de solicitudes en función de la velocidad de descarga.
- sirve múltiples torrents en un solo puerto y en un solo hilo
- admite proxies http y autenticación de proxy básica
- admite respuestas de seguimiento con gzip
- puede limitar el uso de ancho de banda de carga y descarga y el número máximo de pares sin bloquear
- posibilidad de limitar el número de conexiones.
- los retrasos tienen mensajes si no hay otro tráfico saliente al par, y no envían mensajes a los pares que ya tienen la pieza. Esto ahorra ancho de banda.
- descarga selectiva. La capacidad de seleccionar qué partes de un torrent desea descargar.
- filtro de IP para no permitir que las direcciones IP y los rangos de IP se conecten y estén conectados
- Compatibilidad con NAT-PMP y UPnP (asignación automática de puertos en los enrutadores que lo admiten)
- puede proxy el tráfico de torrents a través de la red anónima I2P .
Almacenamiento en caché de disco
Toda la E / S de disco en libtorrent se realiza de forma asíncrona al hilo de la red, mediante el hilo del disco io. Cuando se lee un bloque, el hilo io del disco lee todos los bloques subsiguientes de esa pieza en la caché de lectura, asumiendo que el par que solicita el bloque también solicitará más bloques de la misma pieza. Esto reduce el número de llamadas al sistema para leer datos. También reduce la demora en la búsqueda.
De manera similar, para las solicitudes de escritura, los bloques se almacenan en caché y se vacían en el disco una vez que se completa una pieza completa o la pieza es la menos actualizada cuando se necesita más espacio de caché. La caché asigna dinámicamente espacio entre la caché de lectura y escritura. La caché de escritura tiene una prioridad estricta sobre la caché de lectura.
Los bloques de caché que están en uso se bloquean en la memoria física para evitar que se paguen en el disco. Permitir que la memoria caché del disco se pague en el disco significa que sería extremadamente ineficaz vaciarlo, ya que tendría que volver a leerse en la memoria física solo para volver a vaciarlo en el disco.
Para conservar la memoria y las llamadas al sistema, las operaciones de archivo iovec se utilizan para vaciar varios bloques de caché en una sola llamada.
En sistemas con poca memoria, la caché de disco se puede deshabilitar por completo o establecer un límite más pequeño para ahorrar memoria.
Búferes de red
En CPU con cachés L2 pequeñas, copiar memoria puede ser una operación costosa. Es importante mantener las copias al mínimo en estas máquinas. Esto se aplica principalmente a los sistemas integrados.
Para minimizar el número de veces que se copian los datos recibidos, el búfer de recepción para los datos de carga útil se recibe directamente en un búfer de disco alineado en páginas. Si la conexión está cifrada, el búfer se descifra en el lugar. Luego, el búfer se mueve a la caché del disco sin ser copiado. Una vez que se han recibido todos los bloques de una pieza, o se necesita vaciar la caché, todos los bloques se pasan directamente a writev () para vaciarlos en una sola llamada al sistema. Esto significa una única copia en la memoria del espacio de usuario y una única copia de nuevo en la memoria del kernel.
Al sembrar y cargar en general, se evita la copia innecesaria almacenando en caché los bloques en búferes alineados, que se copian una vez en el búfer de envío del par. No se garantiza que el búfer de envío del par esté alineado, aunque la mayor parte del tiempo lo está. Luego, el búfer de envío se cifra con la clave específica del par y se encadena al iovec para su envío. Esto significa que hay una copia del espacio de usuario para permitir solicitudes de pares no alineadas y cifrado específico de pares.
Selector de piezas
El selector de piezas es un componente central en una implementación de bittorrent. El selector de piezas en libtorrent está optimizado para encontrar rápidamente las piezas más raras. Mantiene una lista de todas las piezas disponibles ordenadas por rareza y las piezas con la misma rareza mezcladas. El primer modo más raro es el modo de selector de piezas dominante. Otros modos también son compatibles y los usuarios los utilizan en situaciones específicas.
El selector de piezas permite combinar la disponibilidad de una pieza con una prioridad. Juntos determinan el orden de clasificación de la lista de piezas. Las piezas con prioridad 0 nunca se seleccionarán, que se utiliza para la función de descarga selectiva.
Para tener la menor cantidad posible de piezas parcialmente terminadas, los compañeros tienen afinidad por recoger bloques de las mismas piezas que otros compañeros en la misma categoría de velocidad. La categoría de velocidad es una categorización aproximada de pares basada en su tasa de descarga. Esto hace que los compañeros lentos elijan bloques de la misma pieza y los compañeros rápidos elijan de la misma pieza, y por lo tanto, disminuye la probabilidad de que los compañeros lentos bloqueen la finalización de las piezas.
El selector de piezas también se puede configurar para descargar piezas en orden secuencial.
Torrents del árbol de hachís de Merkle
Este es BEP30 del protocolo BitTorrent. Merkle hash tree torrents es una extensión que permite que un archivo torrent solo contenga el hash raíz del árbol hash que forma los hashes de las piezas. [12] El principal beneficio de esta función es que, independientemente de cuántas piezas haya en un torrent, el archivo .torrent siempre tendrá el mismo tamaño. Solo crecerá con la cantidad de archivos (ya que todavía tiene que contener los nombres de los archivos).
Con torrents regulares, los clientes tienen que solicitar múltiples bloques de piezas, generalmente de diferentes pares, antes de que los datos puedan verificarse con el hash de la pieza. Cuanto más grandes sean las piezas, más tiempo llevará descargar una pieza completa y verificarla. Antes de que se verifique la pieza, no se puede compartir con el enjambre, lo que significa que los tamaños de pieza más grandes, los datos de respuesta más lenta tienen cuando es descargado por pares. Dado que, en promedio, los datos tienen que quedarse, esperando, en los búferes del cliente antes de que se verifiquen y se puedan cargar nuevamente.
Otro problema con los tamaños de pieza grandes es que es más difícil para un cliente identificar al par malicioso o con errores cuando una pieza falla, y tomará más tiempo volver a descargarla y tomar más intentos antes de que la pieza tenga éxito cuanto más grandes sean las piezas.
El tamaño de la pieza en torrents regulares es una compensación entre el tamaño del archivo .torrent en sí y el tamaño de la pieza. A menudo, para archivos de 4 GB, el tamaño de la pieza es de 2 o 4 MB, solo para evitar que el archivo .torrent sea demasiado grande.
Merkle torrents resuelve estos problemas eliminando el compromiso entre el tamaño de .torrent y el tamaño de la pieza. Con merkle torrents, el tamaño de la pieza puede ser el tamaño de bloque mínimo (16 KB), lo que permite a los pares verificar cada bloque de datos recibidos de sus pares, de inmediato. Esto proporciona un tiempo de respuesta mínimo y elimina por completo el problema de identificar a los compañeros malintencionados.
Aplicaciones
Algunas aplicaciones que usan libtorrent:
- Diluvio , cliente BitTorrent multiplataforma
- Protector de pantalla de oveja eléctrica , cliente BitTorrent para protector de pantalla
- Free Download Manager , administrador de descargas de código abierto de Windows
- Cliente Koinonein BitTorrent, cliente BitTorrent para Windows
- LimeWire , cliente de intercambio de archivos multiplataforma
- Miro , una aplicación de televisión por Internet multiplataforma
- qBittorrent , cliente C ++ / Qt BitTorrent
- Tribler , cliente BitTorrent de igual a igual descentralizado y anónimo
- Runes of Magic, un MMORPG cuyo descargador FOG usa libtorrent para actualizar el cliente del juego.
- World of Tanks , un MMORPG cuyo lanzador usa libtorrent para actualizar el cliente del juego.
Ver también
- Comparación de bibliotecas BitTorrent
Referencias
- ^ "Lanzamientos · arvidn / libtorrent" . GitHub . Consultado el 23 de marzo de 2021 .
- ^ "bep_0001.rst_post" . www.bittorrent.org . Consultado el 19 de febrero de 2020 .
- ^ libtorrent 0.16.0 registro de cambios
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ registro de cambios de libtorrent
- ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 18 de diciembre de 2014 . Consultado el 6 de diciembre de 2010 .CS1 maint: copia archivada como título ( enlace )
enlaces externos
- Página web oficial