libtorrent

Las BEP forman parte del Proceso de Propuestas de Mejora de BitTorrent. Una BEP es un documento de diseño que proporciona información a la comunidad de BitTorrent o describe una nueva funcionalidad para los protocolos de BitTorrent. La BEP debe ofrecer una especificación técnica concisa de la funcionalidad y su justificación. Su propósito original era servir como mecanismo principal para proponer nuevas funcionalidades, recabar la opinión de la comunidad sobre un tema y documentar las decisiones de diseño de BitTorrent. El autor de la 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 características ^{[ 2 ].}

Existen tres tipos de BEP:

1. Un BEP (Proceso de Mejora de BitTorrent) de la vía de estándares 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 directrices o información general 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 ignorarlos o seguir sus consejos.
3. Un BEP de proceso describe un proceso relacionado con BitTorrent o propone un cambio (o un evento) en dicho proceso. Los BEP de proceso son similares a los BEP de la vía de estándares, pero se aplican a áreas distintas de los protocolos BitTorrent. Son más que simples recomendaciones, y los usuarios generalmente no pueden ignorarlos. Algunos ejemplos incluyen calendarios de lanzamiento, procedimientos, directrices, cambios en el proceso de toma de decisiones y modificaciones en las herramientas o el entorno utilizados en el desarrollo de BitTorrent.

• Interfaz de complemento para implementar extensiones personalizadas de BitTorrent 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).
• Rastreadores
• 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.
• Compatibilidad con torrents basados ​​en árboles hash Merkle. Esto permite que el tamaño de los archivos torrent se ajuste proporcionalmente al tamaño del contenido.
• Utiliza un hilo de E/S de disco independiente para evitar que el disco se bloquee en cualquier momento debido a la interacción con la red o con el cliente.
• Admite archivos de más de 2 gigabytes en sistemas que lo admitan.
• Soporte para reanudación rápida: una forma de eliminar la costosa verificación de fragmentos al inicio de una descarga de torrent reanudada. Guarda el estado de almacenamiento, el estado de piece_picker y todos los pares locales en un archivo de reanudación rápida independiente.
• Dispone de una caché de disco de lectura y escritura ajustable para mejorar el rendimiento del disco.
• pone en cola los torrents para la comprobación de archivos, en lugar de comprobarlos todos en paralelo.
• No tiene requisitos sobre el orden de las partes en un torrent que reanuda. Esto significa que puede reanudar un torrent descargado por cualquier cliente.
• Admite tanto archivos dispersos como asignación de archivos compacta (donde las partes se mantienen consolidadas en el disco).
• En el modo semilla, se asume que los archivos en el disco están completos y el hash de cada fragmento 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 básica de proxy.
• Admite respuestas de seguimiento comprimidas con gzip.
• puede limitar el uso del ancho de banda de carga y descarga y el número máximo de pares sin restricciones.
• Posibilidad de limitar el número de conexiones.
• Los retrasos tienen mensajes si no hay otro tráfico saliente hacia el par, y no envían mensajes a los pares que ya tienen la pieza. Esto ahorra ancho de banda.
• Descarga selectiva. La posibilidad de seleccionar qué partes de un archivo torrent se desean descargar.
• Filtro IP para impedir que direcciones IP y rangos de IP se conecten y sean conectados.
• Compatibilidad con NAT-PMP y UPnP (mapeo automático de puertos en routers compatibles).
• Puede redirigir el tráfico de torrents a través de la red de anonimato I2P .

En libtorrent, todas las operaciones de entrada/salida de disco se realizan de forma asíncrona con respecto al hilo de red, mediante el hilo de E/S de disco. Al leer un bloque, el hilo de E/S de disco lee todos los bloques subsiguientes de esa pieza y los almacena 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 la lectura de datos y también disminuye el retardo de búsqueda.

De forma similar, para las solicitudes de escritura, los bloques se almacenan en caché y se escriben en el disco una vez que se completa una operación o cuando se necesita más espacio en la caché. La caché asigna espacio dinámicamente entre la caché de escritura y la de lectura. La caché de escritura tiene prioridad absoluta sobre la de lectura.

Los bloques de caché en uso se bloquean en la memoria física para evitar que se transfieran al disco. Permitir que la caché de disco se transfiera al disco implicaría que vaciarla sería extremadamente ineficiente, ya que habría que volver a cargarla en la memoria física para luego transferirla de nuevo al disco.

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

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

En las CPU con cachés L2 pequeñas, copiar memoria puede ser una operación costosa. Es importante minimizar las copias en este tipo de máquinas. Esto se aplica principalmente a los sistemas embebidos.

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 a páginas. Si la conexión está cifrada, el búfer se descifra in situ. A continuación, el búfer se mueve a la caché de disco sin copiarse. Una vez que se han recibido todos los bloques de una pieza, o cuando es necesario vaciar la caché, todos los bloques se pasan directamente a writev() para vaciarlos en una sola llamada al sistema. Esto implica una sola copia en la memoria del espacio de usuario y una sola copia de vuelta a la memoria del kernel.

Al compartir y cargar archivos, se evita la copia innecesaria mediante el almacenamiento en caché de bloques en búferes alineados, que se copian una sola 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 suele estarlo. 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 implica una copia en el espacio de usuario para permitir solicitudes de pares no alineados y un cifrado específico para cada par.

El selector de fragmentos es un componente fundamental en una implementación de BitTorrent. El selector de fragmentos de libtorrent está optimizado para encontrar rápidamente los fragmentos más raros. Mantiene una lista de todos los fragmentos disponibles ordenados por rareza, y los fragmentos con la misma rareza se muestran en orden aleatorio. El modo de selección de fragmentos que prioriza los más raros es el modo dominante. También se admiten otros modos, que los pares utilizan en situaciones específicas.

El selector de piezas permite combinar la disponibilidad de una pieza con su prioridad. Juntos, determinan el orden de la lista de piezas. Las piezas con prioridad 0 nunca se seleccionarán, lo cual se utiliza para la función de descarga selectiva.

Para minimizar la cantidad de piezas parcialmente terminadas, los nodos tienden a seleccionar bloques de las mismas piezas que otros nodos de la misma categoría de velocidad. Esta categoría clasifica a los nodos según su tasa de descarga. Esto provoca que los nodos lentos seleccionen bloques de la misma pieza, y viceversa, reduciendo así la probabilidad de que los nodos lentos bloqueen la finalización de las piezas.

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

Este es el BEP30 del protocolo BitTorrent. Los torrents de árbol hash Merkle son una extensión que permite que un archivo torrent contenga únicamente el hash raíz del árbol hash que forma los hashes de las piezas. ^{[ 5 ]} La principal ventaja 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 aumentará con el número de archivos (ya que aún debe contener los nombres de los archivos).

Con los torrents convencionales, los clientes deben solicitar varios bloques para cada fragmento, generalmente a diferentes pares, antes de que los datos puedan verificarse con el hash del fragmento. Cuanto mayores sean los fragmentos, más tiempo tardará en descargarse un fragmento completo y verificarse. Antes de que el fragmento se verifique, no se puede compartir con el enjambre, lo que significa que cuanto mayor sea el tamaño de los fragmentos, más lento será el tiempo de respuesta de los datos cuando los pares los descarguen. Esto se debe a que, en promedio, los datos deben permanecer en espera en los búferes de los clientes antes de que se verifiquen y puedan volver a subirse.

Otro problema con los tamaños de fragmentos grandes es que es más difícil para un cliente identificar al par malicioso o defectuoso cuando un fragmento falla, y llevará más tiempo volver a descargarlo y se necesitarán más intentos antes de que el fragmento tenga éxito cuanto más grandes sean los fragmentos.

El tamaño de los fragmentos en los torrents convencionales es un compromiso entre el tamaño del archivo .torrent en sí y el tamaño del fragmento. A menudo, para archivos de 4 GB, el tamaño del fragmento es de 2 o 4 MB, simplemente para evitar que el archivo .torrent sea demasiado grande.

Merkle Torrents resuelve estos problemas eliminando la disyuntiva entre el tamaño del archivo .torrent y el tamaño de los fragmentos. Con Merkle Torrents, el tamaño de los fragmentos puede ser el tamaño mínimo del bloque (16 KB), lo que permite a los pares verificar inmediatamente cada bloque de datos recibido. Esto reduce al mínimo el tiempo de respuesta y elimina por completo el problema de identificar pares maliciosos.