stringtranslate.com

libretorrent

libtorrent es una implementación de código abierto del protocolo BitTorrent . Está escrito en C++ 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 ganar 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 ).

libtorrent se mantiene actualizado con extensiones de bittorrent que los desarrolladores consideran más útiles y se optimiza 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 de semillas. 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

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 de BitTorrent o describe una nueva característica para los protocolos de BitTorrent. El BEP debe proporcionar una especificación técnica concisa de la característica y una justificación de la misma. Se pretendía que fueran los mecanismos principales para proponer nuevas características, para recopilar las opiniones de la comunidad sobre un tema y para 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 discrepantes.

Debido a que los BEP se mantienen como archivos de texto reestructurados en un repositorio versionado, su historial de revisiones 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 actualmente son 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 de BitTorrent, pero no propone una extensión. Los BEP informativos no necesariamente representan 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.
  3. Un BEP de proceso describe un proceso relacionado con BitTorrent o propone un cambio en un proceso (o un evento en el mismo). Los BEP de proceso son como los BEP de seguimiento de estándares, pero se aplican a otras áreas además de los protocolos de BitTorrent. Son más que recomendaciones y, por lo general, los usuarios no tienen la libertad de ignorarlas. Algunos 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 de disco en libtorrent se realiza de forma asincrónica con el subproceso de red, por medio del subproceso de E/S de disco. Cuando se lee un bloque, el subproceso de E/S de disco lee todos los bloques subsiguientes de esa parte en la caché de lectura, asumiendo que el par que solicita el bloque también solicitará más bloques de la misma parte. Esto disminuye la cantidad de llamadas al sistema para leer datos. También disminuye la demora de la búsqueda.

De manera similar, en el caso de las solicitudes de escritura, los bloques se almacenan en caché y se vacían en el disco una vez que se completa una parte o cuando la parte es la que se actualizó menos recientemente, cuando se necesita más espacio en caché. La caché asigna espacio de manera dinámica entre la caché de escritura y la de lectura. La caché de escritura tiene 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 extraigan al disco. Si se permite que la caché del disco se extraiga al disco, resultaría extremadamente ineficiente vaciarla, ya que tendría que volver a leerse en la memoria física para luego vaciarse nuevamente al disco.

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

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

Búferes de red

En las CPU con cachés L2 pequeñas, copiar memoria puede ser una operación costosa. Es importante mantener la copia 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 los datos de carga útil se recibe directamente en un búfer de disco alineado con la página. Si la conexión está cifrada, el búfer se descifra en el lugar. Luego, el búfer se mueve a la memoria caché del disco sin copiarse. Una vez que se han recibido todos los bloques de una pieza, o es necesario vaciar la memoria caché, todos los bloques se pasan directamente a writev() para vaciarlos en una única llamada al sistema. Esto significa una única copia en la memoria del espacio de usuario y una única copia de regreso a la memoria del núcleo.

En general, al sembrar y cargar, 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 a iovec para enviar. Esto significa que hay una copia en el espacio de usuario para permitir solicitudes de pares no alineadas y cifrado específico del par.

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 modo más raro primero es el modo de selección de piezas dominante. También se admiten otros modos y los utilizan los 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. Las piezas con prioridad 0 nunca se seleccionarán, lo que se utiliza para la función de descarga selectiva.

Para tener la menor cantidad posible de piezas parcialmente terminadas, los pares tienen una tendencia a elegir bloques de las mismas piezas que otros pares en la misma categoría de velocidad. La categoría de velocidad es una categorización aproximada de pares basada en su velocidad 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 de árboles de hash de Merkle

Este es el 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 aún debe contener los nombres de los archivos).

Con los torrents habituales, los clientes tienen que solicitar varios bloques de fragmentos, normalmente a diferentes pares, antes de que los datos puedan ser verificados con el hash del fragmento. Cuanto más grandes sean los fragmentos, más tiempo llevará descargar un fragmento completo y verificarlo. Antes de que el fragmento sea verificado, no puede ser compartido con el enjambre, lo que significa que cuanto mayor sea el tamaño de los fragmentos, más lento será el procesamiento de los datos cuando los pares los descarguen. Dado que, en promedio, los datos tienen que esperar en los búferes de los clientes antes de que se los haya verificado y se los pueda volver a cargar.

Otro problema con los tamaños de piezas grandes es que es más difícil para un cliente identificar el par malicioso o con errores cuando una pieza falla, y tomará más tiempo volver a descargarla y se necesitarán más intentos antes de que la pieza tenga éxito cuanto más grandes sean las piezas.

El tamaño de los fragmentos en los torrents normales es una compensación entre el tamaño del archivo .torrent en sí y el tamaño de los fragmentos. A menudo, para archivos de 4 GB, el tamaño de los fragmentos es de 2 o 4 MB, solo para evitar que el archivo .torrent sea demasiado grande.

Merkle torrents resuelve estos problemas eliminando la disyuntiva entre el tamaño de .torrent y el tamaño de fragmento. Con Merkle torrents, el tamaño de fragmento puede ser el tamaño de bloque mínimo (16 KB), lo que permite a los pares verificar cada bloque de datos recibido de sus pares de forma inmediata. Esto ofrece un tiempo de respuesta mínimo y elimina por completo el problema de identificar a los pares maliciosos.

Aplicaciones

Algunas aplicaciones notables que utilizan libtorrent:

Véase 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 2020-02-12 . Consultado el 2020-02-19 .
  3. ^ "Archivo de código de Google: almacenamiento a largo plazo para el alojamiento de proyectos de código de Google". code.google.com . Archivado desde el original el 2021-04-18 . Consultado el 2022-02-05 .
  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 – vía 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