stringtranslate.com

libretorrent

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 la compatibilidad con Mainline DHT , IPv6 , semillas HTTP y el intercambio entre pares de μTorrent . libtorrent usa Boost , específicamente Boost.Asio para ganar independencia de plataforma. Se sabe que se basa en Windows y en la mayoría de los sistemas operativos tipo Unix ( OS X , Linux y muchos BSD ).

libtorrent se mantiene actualizado con 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 escritorios 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 la base sobre la que se basan muchas otras extensiones.

Características

MPA implementadas

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 que describe una nueva característica para los protocolos BitTorrent. El BEP debe proporcionar una especificación técnica concisa de la característica y una justificación de la misma. Estaban destinados a ser los mecanismos principales para proponer nuevas funciones, recopilar opiniones de la comunidad sobre un tema y documentar las decisiones de diseño que se han tomado en BitTorrent. El autor del BEP es responsable de generar consenso dentro de la comunidad y 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:

  1. Un BEP de Standards Track describe una extensión de uno de los protocolos 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.
  2. Un BEP informativo describe un problema de diseño de BitTorrent o proporciona pautas generales o información a la comunidad BitTorrent, pero no propone una extensión. Los BEP informativos no necesariamente representan un consenso o recomendación de la comunidad BitTorrent, por lo que los usuarios e implementadores son libres de ignorar los BEP informativos o seguir sus consejos.
  3. Un BEP de proceso 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 a los protocolos BitTorrent. Son más que recomendaciones y, por lo general, los usuarios no pueden ignorarlas. Los ejemplos incluyen cronogramas 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.

Lista de características varias

Almacenamiento en caché de disco

Toda la E/S del disco en libtorrent se realiza de forma asincrónica con el hilo de la red, mediante el hilo io del disco. Cuando se lee un bloque, el subproceso disk io lee todos los bloques posteriores de esa pieza en la memoria caché de lectura, suponiendo que el par que solicita el bloque también solicitará más bloques de la misma pieza. Esto disminuye la cantidad de llamadas al sistema para leer datos. También disminuye 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 actualizada menos recientemente cuando se necesita más espacio de caché. El caché asigna dinámicamente espacio entre el caché de escritura y lectura. La caché de escritura tiene estrictamente prioridad sobre la caché de lectura.

Los bloques de caché que están en uso están bloqueados en la memoria física para evitar que se paginan en el disco. Permitir que la memoria caché del disco se pagina en el disco significa que sería extremadamente ineficiente vaciarlo, ya que tendría que volver a leerse en la memoria física para luego vaciarse nuevamente al disco.

Para conservar memoria y llamadas al sistema, las operaciones de archivos iovec se utilizan para vaciar varios bloques de caché en una sola llamada.

En sistemas con poca memoria, la caché del disco se puede desactivar por completo o establecer en un límite menor para ahorrar memoria.

Búfers 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 dichas máquinas. Esto se aplica principalmente a los sistemas integrados.

Para minimizar la cantidad de veces que se copian los datos recibidos, el búfer de recepción de datos de carga útil se recibe directamente en un búfer de disco alineado con páginas. Si la conexión está cifrada, el búfer se descifra in situ. Luego, el búfer se mueve al caché del disco sin copiarse. Una vez que se han recibido todos los bloques de una pieza, o es necesario vaciar el 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 nuevamente en la memoria del kernel.

Al realizar la siembra y la carga en general, se evitan copias innecesarias 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 lo esté la mayor parte del tiempo. 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.

Recogedor de piezas

El selector de piezas es un componente central en una implementación bittorrent. El selector de piezas de 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 dominante de selección de piezas. Otros modos también son compatibles y utilizados por pares 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. Nunca se seleccionarán piezas con prioridad 0, 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 pares lentos elijan bloques de la misma pieza y los pares rápidos elijan de la misma pieza y, por lo tanto, disminuye la probabilidad de que los pares lentos bloqueen la finalización de las piezas.

El selector de piezas también se puede configurar para descargar piezas en orden secuencial.

Torrentes del árbol de hash 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. [5] El principal beneficio de esta característica 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 debe contener los nombres de los archivos).

Con los torrents normales, 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 cuanto más grandes sean las piezas, más lento será el tiempo de respuesta de los datos cuando los descarguen los pares. Dado que, en promedio, los datos tienen que permanecer esperando en los buffers del cliente antes de que se verifiquen y se puedan cargar nuevamente.

Otro problema con los tamaños de piezas 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 realizar más intentos antes de que la pieza tenga éxito cuanto más grandes sean las piezas.

El tamaño de la pieza en los torrents normales 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, sólo para evitar que el archivo .torrent sea demasiado grande.

Merkle torrents resuelve estos problemas eliminando el equilibrio 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 los pares, de inmediato. Esto proporciona un tiempo de respuesta mínimo y elimina por completo el problema de identificar pares maliciosos.

Aplicaciones

Algunas aplicaciones notables que usan libtorrent:

Ver también

Referencias

  1. ^ "Versión 2.0.10". 19 de febrero de 2024 . Consultado el 20 de febrero de 2024 .
  2. ^ "bep_0001.rst_post". www.bittorrent.org . Archivado desde el original el 12 de febrero de 2020 . Consultado el 19 de febrero de 2020 .
  3. ^ "Google Code Archive: almacenamiento a largo plazo para el alojamiento de proyectos de Google Code". código.google.com . Archivado desde el original el 18 de abril de 2021 . Consultado el 5 de febrero de 2022 .
  4. ^ abcdefg "arvidn/libtorrent". 4 de febrero de 2022. Archivado desde el original el 5 de febrero de 2022 . Consultado el 5 de febrero de 2022 a través de GitHub.
  5. ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 18 de diciembre de 2014 . Consultado el 6 de diciembre de 2010 .{{cite web}}: CS1 maint: archived copy as title (link)

enlaces externos