Can bittorrent peers handle seeding grandes cantidades de torrents inactivos

Question

Estoy considerando utilizar bittorrent para un gran problema de difusión de datos donde la fuente de datos es petascale y los usuarios querrán hasta varios terabytes. Algunos detalles

• Número de torrentes potencialmente en los millones
• tamaños torrente que van de 100 Mb a 100 Gb
• Un conjunto estable de grupos de todo el mundo capaz de actuar como sembradoras cada uno con un gran subconjunto de los torrentes totales (digamos 60% en promedio)
• Un número relativamente pequeño de usuarios simultáneos (menos de 100) que desean descargar en promedio unos pocos terabytes de datos.

espero que el número de torrents activos a ser pequeño en comparación con el disponible, pero la calidad del servicio es importante, así que debe haber varias sembradoras para cada torrent o algún mecanismo para el lanzamiento de nuevas sembradoras total.

Mi pregunta es: ¿pueden los clientes de bittorrent manejar un gran número de torrents, la mayoría de los cuales están inactivos? ¿Tendría que rastrear torrentes a través de las sembradoras en un clúster o podría cada nodo estar sembrando todos los torrentes a los que tiene acceso? ¿Qué cliente haría el mejor trabajo? ¿Hay alguna herramienta para manejar grupos de sembradoras?

Supongo que los rastreadores se pueden escalar a este nivel.

Answer 1

El protocolo lo permite, pero no sé qué clientes escalarían a millones de torrents. En el peor de los casos, tendrías que escribir tu propio cliente exclusivo de semillas.

La característica de protocolo más relevante para su caso de uso es que, cuando un compañero se conecta a otro, se supone que el par de conexión debe enviar primero el hash de información del torrente. Esto significa que un solo puerto TCP de escucha podría usarse para generar una cantidad ilimitada de torrentes, con casi cero recursos utilizados cuando está inactivo.

Esto se puede conocer en The BitTorrent Protocol Specification:

Si ambas partes no envían el mismo valor, que cortar la conexión. La única posible excepción es que si un programa de descarga desea realizar múltiples descargas en un solo puerto, puede esperar que las conexiones entrantes den primero un hash de descarga y responder con el mismo si está en su lista.

También encontré la misma en este Bittorrent Protocol Specification v1.0:

Se espera que el iniciador de una conexión para transmitir su apretón de manos inmediatamente. El destinatario puede esperar el intercambio de información del iniciador, si es capaz de servir múltiples torrentes simultáneamente (los torrents se identifican de manera única por su info_hash).

Sin embargo, hay una cosa que aumentaría su carga, y es el rastreador. Con el protocolo de seguimiento normal, cada cliente tiene que anunciar periódicamente al rastreador cada torrente que tiene, junto con información como cuánto ha subido. Con millones de torrents, esto presentaría una carga algo alta. Si estuvieras escribiendo tu propio cliente de semilla masiva, sería una buena idea un protocolo separado para anunciar tus sembradoras al rastreador.

Answer 2

Para no colapsar debajo de la cabeza del rastreador inútil anuncia y raspa millones (y eso en cada intervalo de anuncio), tiene que restringir sus clústeres de siembra para cargar únicamente el conjunto actual de elementos que se solicitan en este momento. Los descargadores deben descargar (descargar) el archivo .torrent de un lugar central de todos modos, y eso podría desencadenar su carga en los clústeres de siembra. Alternativamente, determine la actividad de un hash de información en particular al reconocer anuncios que NO se originan en uno de sus grupos de semillas.

rTorrent tiene reanudación rápida (lo que significa que no se produce hash cuando se carga un .torrent adecuadamente preparado), y es controlable a través de xmlrpc para que pueda desmantelar los elementos inactivos. De esta forma, una descarga .torrent puede desencadenar que los datos reales estén disponibles durante las próximas 24 horas, o mientras haya actividad en el enjambre.

Answer 3

Hay 2 problemas principales:

1. Cada torrente (por lo general) tiene que anunciar a un rastreador periódicamente, esto podría terminar usando una cantidad significativa de ancho de banda.
2. El cliente bittorrent sí tienen que ser escrito de una manera de escalar con un gran número de torrentes

En cuanto al tráfico de seguimiento, vamos a suponer que usted tiene 1 millón de torrentes, el intervalo de re-anunciar típico es 30 minutos, pero algún rastreador lo tiene configurado en 1 hora. Seamos conservadores y supongamos que su rastreador usa intervalos de anuncio de 1 hora. Tendrá que hacer 1 millón de solicitudes GET por hora, digamos que cada solicitud tiene 400 bytes de actividad y 100 bytes de capacidad (suponiendo que la mayoría de las respuestas no contengan ningún interlocutor), eso es aproximadamente 111 kB/s activo y 28 kB/s desactivado constantemente. Eso no es tan malo, pero tenga en cuenta que TCP requiere un viaje de ida y vuelta adicional para establecer conexiones, por lo que hay otros 40 bytes de bajada y 40 bytes de más.

Esto se puede mitigar utilizando solo UDP trackers. Entonces solo necesitaría un solo mensaje de conexión, y puede reutilizar la identificación de conexión para cada anuncio. Cada mensaje de anuncio sería entonces de 100 bytes, y el mensaje devuelto también sería un poco más compacto, supongamos 60 bytes. Eso te daría 28 kB/s y 16kB/s hacia abajo, solo para mantener los torrentes anunciados. Para esto, necesitaría un cliente con un soporte de udp tracker decente (uno que almacena en caché el ID de conexión, por ejemplo).

No está mal, suponiendo que es insignificante en comparación con los datos reales que enviarían sus semillas.

Sin embargo, no es necesario que bloquee sus torrents en centros de datos separados, también podría usar un servidor HTTP para inicializar los torrentes. Todos los principales clientes de bittorrent admiten la creación de http, y no tendría que preocuparse por anunciar al rastreador (la URL se graba en el propio .torrent).

En cuanto a un cliente que escala bien con torrents, no estoy seguro, no he hecho ninguna medición. Debería ser bastante sencillo generar un millón de torrentes aleatorios e intentar cargarlo.

He hecho algunos trabajos de optimización en libtorrent rasterbar para hacerlo escalar bien con muchos torrents, aunque no he probado millones.

He escrito una publicación en el blog sobre este tema, here.

Answer 4

Quizás esté buscando Hekate Está, en el mejor de los casos, pre-alfa en este momento, pero es casi lo que está describiendo.