La implementación de Bittorrent en java && necesita información sobre el comportamiento del enjambre

sockets (1)

Esta pregunta ya tiene una respuesta aquí:

¿Creando un cliente torrent en Java? [duplicar] 1 respuesta

Estoy desarrollando un cliente de bitTorrent en Java. Sé que hay muchas bibliotecas en línea, pero no puedo evitarlo; Quiero mi propio. De todos modos, noté algunos comportamientos extraños y quizás ustedes saben algo que me estoy perdiendo:

Aproximadamente el 80% de todos los compañeros a los que estoy tratando de conectar dan como resultado conexiones no exitosas ( socketTimeOut o "no se puede conectar"). Obviamente, la lista de pares se recibe de los rastreadores. También probé aleatoriamente algunas direcciones IP intentando hacerles ping; el ping es generalmente exitoso
Cuando me conecto:
- 50% de conexión de caída después del apretón de manos,
- en el 30% noté un comportamiento extraño: recibí un saludo, recibí BitField (tienen todas las piezas), me bombardearon con +20 mensajes (revisé el índice de piezas que ya mencionaron en BitField), luego se desconectan , lo cual es raro.

(Para todas las estadísticas, las cifras no son precisas.)

Algunas preguntas de BitTorrent:

ACTUALIZACIÓN # 4: estoy cortando algunas preguntas debido a que se considera la respuesta encontrada

esta fue la ''pregunta de tasa de conexión fallida del 80%'': ¿Cuál podría ser la razón de que mi 80% no haya podido conectar la tarifa? Esto no puede ser mala suerte, en el sentido de que cada cliente que intenté conectar no tenía más espacio para mí. Estoy escuchando en 6881, pero también probado con otros puertos. Ayer tuve un gran éxito, un montón de conexiones aceptadas (el mismo código, algunos cambios en la semana pasada), los mensajes de Piece comenzaron a fluir ... así que mi código no es totalmente inútil.
¿Los clientes de torrent envían, antes de cerrar, un último mensaje al rastreador con event=stopped para actualizar su base de datos interna con información de igual a fin de que no envíe, como respuesta, una lista con información de igual inútil? O simplemente deberían ... porque realmente parece que estoy recibiendo compañeros muertos.
¿Es el orden de los pares recibidos de alguna importancia? Tal vez el porcentaje de finalización ... o realmente al azar.
Además, de vez en cuando recibo un par con el puerto 0, lo que hace que mi constructor Socket lance una excepción. ¿Qué significa el puerto 0? ¿Puedo contactarlo en cualquier puerto?
¿Puede mi PeerId (que envío en Handshake o anunciarse a mí mismo al rastreador) influir si los clientes de torrent que intento comunicar continuarán una conexión iniciada? ¿Qué significa que si miento y digo que soy un cliente de Azureus utilizando ''-AZ2060-'' como mi ID?
esta fue la ''pregunta sobre la disponibilidad que asustaba a los compañeros'': ¿La disponibilidad de mi pieza asusta a sus compañeros? Estoy intentando conectarme y envío un campo de bits vacío (no tengo piezas, [length: 1][Id = 5][payload: {}] ); Parece que envían el campo de bits, yo envío el campo de bits ... (algunos envían como locos, tienen mensajes), se dan cuenta de que soy pobre, me sueltan ... alguna conexión de caída después del apretón de manos. (Qué grosero.)
¿Existe la ventaja de no utilizar el intervalo de puerto clásico: 6881 - 6889?
esta fue la ''lista de preguntas de los malos compañeros'': ¿Los clientes de torrent mantienen internamente una lista de compañeros malos (como una lista negra)? A veces, después de encontrar un buen compañero, continuamente usaba su información en mis pruebas, pero solo se aceptaba 1/3 de conexión. A veces debían pasar 10 minutos para tener una conexión exitosa nuevamente.

ACTUALIZACIÓN # 1: parece que las conexiones con los clientes de µTorrent se comportan en el patrón mencionado anteriormente (BITFIELD, HAVE bombardment, close connection). Probé localmente con un montón de clientes de bitTorrent (μTorrent, BitTorrent, Vuze, BitCommet, Deluge) y solo noté este patrón en μTorrent. Por lo demás, la comunicación estuvo bien (HS, BITFIELD, UNCHOCE y compartir piezas felices). Ahora, este μTorrent es probablemente el cliente más popular de bitTorrent (6/8 conexiones iniciadas fueron μTorrent), así que ... ¿alguna idea?

ACTUALIZACIÓN # 2: En términos de mantener una "bad list," , parece que sí (y en realidad tiene sentido hacerlo). Por ejemplo, con μTorrent, noté los siguientes intervalos de no conexión (30s, 1min, 1min30s, 2min ..). Por "no-connect" en la media, después de que finalizó la conexión anterior, durante x segundos no se aceptó una nueva conexión.

ACTUALIZACIÓN # 3: Ese mensaje de HAY bombardeo podría haber sido el llamado "campo de bits lento" (hizo un par de pruebas, cada pieza mencionada en HAVE no estaba presente en BITFIELD). Veo que μTorrent y BitTorrent utilizan este enfoque.

Otra conclusión : algunos clientes son más restrictivos en cuanto a respetar las especificaciones de BitTorrent y cerrarán la conexión si infringe una regla. Por ejemplo: noté con BitTorrent y BitTornado que si envía un mensaje de campo de bits pero no tiene partes, se cerrará la conexión (sin piezas = campo de bits vacío ... pero las especificaciones dicen "Es opcional, y no es necesario enviarlas si el cliente no tiene piezas "), mientras que otros cierran la conexión si envías cualquier tipo de mensaje antes de que envíen un mensaje DESACTIVADO (ni siquiera INTERESADO).

ACTUALIZACIÓN # 4: Ya que estoy más interesado en la primera pregunta (¿Cuál podría ser la razón por la que mi 80% no logró conectar la tarifa? ... las preguntas en huelga son las que más me gustan), aquí hay algunas explicaciones de por qué a veces las conexiones fueron infructuosas:

1) si comienzo una conexión con un compañero poco después de detener una conexión anterior (con parada, me refiero a cerrar socket): el compañero del otro lado no sabrá hasta la próxima lectura / escritura.

Detalles: noté esto un montón de veces, esto es más obvio después de terminar una descarga ... si cierro la conexión, mi par no se dará cuenta de esto hasta que intente enviar un nuevo KEEP_ALIVE (~ 2 minutos). Pero si cierro durante un intercambio REQUEST-PIECE, un par se dará cuenta muy rápido. En el primer escenario, después de cerrar la conexión, todavía estoy presente en la pestaña de compañeros de uTorrent. Si miro dentro de la pestaña del registrador, después de unos 2 minutos, se dará cuenta de que me he ido.

2) parece que uTorrent ve mi mensaje BITFIELD dañado (y obviamente debería cerrar la conexión después de recibirlo) (esto no siempre sucede ... también verifiqué y revisé nuevamente, msg está bien y con otro cliente de BT no hubo tales problemas) .

Detalles: - si miro dentro de la pestaña del registrador de uTorrent, aparece "Desconectado: Paquete incorrecto" justo después de enviar el campo de bits. Estoy planeando probar una implementación de campo de bits flojo, tal vez pueda escapar de esto (también veo que la mayoría de BT los clientes hacen esto)

3) (más que probablemente vinculado al # 1) cuando uTorrent no me permite volver a conectarme, veo en la pestaña del registrador: "Desconectar: ya tengo la misma conexión (conexión adicional perdida)". Actualmente elijo un puerto local aleatorio cuando inicia una nueva conexión (vio esto implementado en la mayoría de los clientes de BT), pero esto no lo engaña, todavía ve que soy un compañero ya presente en su "lista de pares" (probablemente no coincida con IP) .. Buuut: en el 30% de las pruebas, en el mismo escenario, me permite volver a conectarme :) .. No tengo explicaciones de por qué todavía

4) una cosa más: parece que el ''oyente para las conexiones entrantes'' sigue vivo después de que cierras un torrent en uTorrent (por cierre, quiero decir: clic derecho + detener). Esto significa que todavía puedo iniciar una conexión, enviar HANDSHAKE ... después de esto, estoy desconectado (no hace HANDSHAKE). Mensaje en el registrador de uTorrent: "Desconectar: No hay un torrent de este tipo: 80FF40A75A3B907C0869B798781D97938CE146AE", esta cadena larga es mi hash de información ... visto esto mientras se prueba con otros clientes de BT también.

Un poco más de información :

los escenarios con uTorrent de tipo de carga completa / carga parcial y descarga completa son exitosos, los de descarga parcial no ... probablemente debido al # 2
Todavía obtengo con uTorrent que bitField + tiene un bombardeo + una conexión cercana ... ya que recuerdo el mismo mensaje en la pestaña del registrador "Desconectado: paquete incorrecto" ... probablemente debido al # 2
además de uTorrent, he probado con: BitTorrent, BitTornado, BitCommet, qBitTorrent, FlashGet (la comunicación fue correcta) y con Vuze, FrostWire, Shareaza (con estos muchachos, fue super OK).
No todos los clientes se comportan igual. Por ejemplo: FlashGet y uTorrent (¿y BitCommet?) No se desbloquea hasta que envíe INTERESADOS .. mientras que otros parecen desbloquearse justo después de BITFIELD .. en este sentido, estoy planeando de alguna manera tratar a los clientes de manera diferente (realmente creo que esto es necesario) .. probablemente adivine su nombre desde el campo de bits (solo hay 2 convenciones de nomenclatura) y comience desde allí .. Ya tengo algo implementado, así es como sé que me conecté al cliente de tipo uTorrent ..

Ok, tengo una respuesta para usted, pero debo advertirle que yo mismo nunca escribí un cliente de bit-torrent y algunas respuestas podrían no ser 100% precisas, todo lo que escribí es desde mi entendimiento de la visión global de cómo bit-torrent trabajo. Por lo tanto, pido disculpas si perdí el tiempo, pero sigo creyendo que podrías aprender sobre el núcleo de lo que estás preguntando en mi respuesta.

• ¿Cuál podría ser la razón de que mi 80% no haya podido conectar la tarifa?

Muy complicado de explicar en una explicación lineal, pero: - la ideología de bit torrent es tit-4-tat ... si no está dando / teniendo tit, no está recibiendo tatuajes. A MENOS QUE acaba de comenzar a descargar y, en ese caso, podría comenzar con una "donación" ... O el otro lado es una sembradora dedicada ... en ese caso, puede verificar si usted es un donante o simplemente un tomador ... O muchos de los que actualmente descargan esto ... O (complete su idea ...) Entonces, verá que hay muchos, y en realidad mecanismos muy inteligentes para asegurarse de que el enjambre pueda ser ágil y eficiente, y si bien algunos de ellos se pueden rastrear en su máquina, la mayoría de ellos ni siquiera se pueden monitorear. Por su máquina menos que decir bajo su control.

• ¿Los clientes de torrent envían, antes de cerrar, un último mensaje al rastreador con evento = detenido para actualizar su base de datos interna con información de igual a fin de que no envíe, como respuesta, una lista con información de igual inútil? O simplemente deberían ... porque realmente parece que estoy recibiendo compañeros muertos.

Depende del código del cliente, algunos pueden hacer que otros no ... (seguir leyendo)

• ¿El orden de los compañeros recibidos es de alguna importancia? Tal vez el porcentaje de finalización ... o realmente al azar.

Depende del código del servidor, algunos pueden hacer que otros no ... (seguir leyendo)

Muy bien, tenga en cuenta que para esas dos notas (siga leyendo). Debe tener en cuenta que en una red P2P no hay autoridad para vincular estrictamente a los clientes o incluso a los servidores para mantener el protocolo en la letra, incluso si el protocolo establece algo que debería Se debe hacer, no significa que cada cliente lo implementará o actuará de la misma manera o se lo perderá.

• Además, de vez en cuando recibo un par con el puerto 0, lo que hace que mi constructor Socket lance una excepción. ¿Qué significa el puerto 0? ¿Puedo contactarlo en cualquier puerto?

El puerto 0 es una especie de comodín, si te conectas, te conectará automáticamente al siguiente puerto disponible. (Algunos dicen que el siguiente puerto disponible está por encima de 1023, pero nunca lo probé)

• ¿Puede mi PeerId (que yo envíe Handshake o me anuncie al rastreador) influir si los clientes de torrent que estoy intentando comunicar continuarán una conexión iniciada? ¿Qué significa que si miento y digo que soy un cliente de Azureus utilizando ''-AZ2060-'' como mi ID?

Pensará que usted es Azureus y si otros Azureuses promueven la conexión a Azureuses de acuerdo con eso (y eso es un gran problema), obtendrá un beneficio de ello.

• ¿La disponibilidad de mi pieza asusta a sus compañeros? Estoy intentando conectarme y envío un campo de bits vacío (no tengo piezas, [longitud: 1] [Id = 5] [carga útil: {}]); Parece que envían el campo de bits, yo envío el campo de bits ... (algunos envían como locos, tienen mensajes), se dan cuenta de que soy pobre, me sueltan ... alguna conexión de caída después del apretón de manos. (Qué grosero.)

posible..

• ¿Existe la ventaja de no utilizar el intervalo de puerto clásico: 6881 - 6889?

No lo creo, excepto tal vez confundir su ISP ..

• ¿Los clientes de torrent mantienen internamente una lista de compañeros malos (como una lista negra)? A veces, después de encontrar un buen compañero, continuamente usaba su información en mis pruebas, pero solo se aceptaba 1/3 de conexión. A veces debían pasar 10 minutos para tener una conexión exitosa nuevamente.

Depende del código del cliente.

Resumen

Es una jungla allá afuera, todos pueden escribir su propia lógica siempre que él envíe los comandos de protocolo correctos, sus preguntas se centran en el comportamiento lógico de los clientes, pero no hay un punto en común como probablemente ya haya entendido, esta es también la belleza de El bit-torrent y probablemente la principal razón de su éxito.