You should understand clearly why the solution apparently works:
All DHT traffic uses UDP for its purposes. UDP is a “broadcast”, one-way protocol. Nearly everything else that you do on the internet uses TCP instead. TCP is two-way, so it requires that the receiver acknowledge every packet received. The sender depends on this to assure that the last packet made it through, before sending the next one.
Each packet, including the one containing the ACKnowledgement, has a definite “time to live”. When it expires, that packet is no longer forwarded anywhere. This keeps the internet from being flooded with ancient packets roaming around forever.
Every packet goes into a queue to be sent. If your send queue is very full, then it’s possible for some packets to expire while waiting in the queue, or to be delayed so long that when the paccket is finally sent, it expires in just a few hops and before it gets where it’s going.
When the sending site doesn’t get the ACK, it sends the same packet again. If the sender has already actually received that packet, the connection appears to have stalled out. After enough tries, the sender stops trying.
This means that it’s important to limit what your bittorrent client is sending. You must keep your client’s global maximum speed below your internet connection’s upstream speed maximum, otherwise your queue builds up and packets start expiring.
UDP packets take their place in the queue and so contribute to the delay, but UDP packets aren’t acknowledged. So if your system is ALMOST maxed out, but not quite, then adding the UDP packets from DHT can push it over the edge. Disabling DHT brings the number of outgoing packets back down below the max-out point, but this isn’t an ideal solution.
The real solution is to properly set your client’s global maximum upload speed, so that all of the packets it generates, TCP and UDP, leave enough room for other traffic to send those ACK’s back to their sources.
You must actually test your connection’s upload speed. Connections always talk about their DOWNSTREAM speeds, and usually measure it in bits, not bytes. Applications use bytes, but using bits inflates the numbers. 1 Byte == 8 bits. That means a “1 megabit per second !!!” connection is actually, 125 KiloBytes per second. But the speed UPstream, that’s not nearly as fast, and is usually mentioned only in the fine print. It can be a great deal slower than the downstream speed.
So test it, several times in a day and on several different days to get a good idea of the average. Limit your client’s speed accordingly, to about 80% of that, then you should be able to use DHT and coexist with other applications as well.
Deberías entender claramente por qué la solución aparenta funcionar:
Todo tráfico DHT usa UDP para sus fines. UDP es un protocolo de dirección única que se “anuncia”. Casi todo lo demás que haces en Internet usa TCP en vez. TCP es bidirecional y por eso necesita que el receptor/destinatario confirme cada paquete que se recibe. El remitente depende de esto para asegurar que el último paquete fue recibido, antes de enviar el siguiente.
Cada paquete, incluyendo el que contiene la confirmación (“ACKnowledgement”), tiene una determinada longevidad. Cuando ésta caduca, dicho paquete ya no es dirigido a ninguna parte. Esto previene que Internet se inunde con paquetes antiguos que puedan están vagando “por ahí” indefinidamente.
Cada paquete entra en una cola para ser enviado. Si tu cola está muy llena, entonces es posible que algunos paquetes caduquen mientras esperan en la misma, o que se retrasen tanto que, cuando el paquete finalmente se envía, caduca a los poquitos pasos, antes de poder llegar a su destino.
Cuando la página web remitente no recibe el ACK (confirmación), vuelve a enviar el mismo paquete, de nuevo. Si el remitente ya ha recibido ese paquete, actualmente, la conexión aparecerá como si estuviese ralentizada. Tras el suficiente número de intentos, el remitente desiste intentar enviar.
Esto significa que es importante limitar lo que tu cliente bittorrent está mandando. Tienes que mantener la máxima velocidad de subida de tu cliente por debajo de la máxima velocidad de subida de tu conexión, porque si no tu cola aumenta y los paquetes empiezan a caducar.
Los paquetes UDP toman sus lugares en la cola y, de esta forma, contribuyen a la demora pero los paquetes UDP no son confirmados. Por tanto, si tu sistema está CASI al límite [de velocidad] - sin llegar a este - añadir paquetes UDP del DHT puede causar que se sobrepase. Inhabilitar el DHT disminuye el número de paquetes salientes a un nivel por debajo del punto máximo, pero esto no es una solución ideal.
La solución real es el configurar la velocidad máxima de subida global de tu cliente adecuadamente, para que todos los paquetes que genera - TCP y UDP - dejen suficiente sito/espacio para que otro tráfico pueda enviar los ACKs, de vuelta a sus fuentes de origen.
Actualmente debes de comprobar la velocidad de subida d tu conexión. Los proveedores de conexiónes (ISP) siempre hablan de su velocidad de BAJADA/DESCARGA, y normalmente la miden en bits, no bytes. Los programas usan bytes pero, al usar bits, los números suenan “mayores”. 1 Byte = 8 bits. Esto significa que una conexión de “¡ Un Megabit por segundo !” es, en realidad, 125 KiloBytes/segundo. Pero la velocidad de SUBIDA (que jamás es tan rápida) normalmente sólo se menciona en ‘letras pequeñas’ en tu contrato… y puede llegar a ser mucho más lenta que la velocidad de bajada.
Así que compruébala, varias veces durante el día y durante varios días diferentes para obtener una buena indicación de la media. Limita la velocidad de tu cliente a un 80% (aproximadamente) del resultado y, de esta forma, podrás usar DHT a la vez que usas otras aplicaciones/programas también.
