Pierdo conexion al abrir Bitcomet

[guess400]

Buenas noches soy usuario del BitComet 1.20

tengo conectado un modem adsl SmartAx MTbb2a con puerto USB el cual no uso por falta de drivers a mi SO este se conecta a un Router Linksys wrt54g2 actualizado al ultimo fimw oficial no he redirigido puerto

versión de Windows 7, Cortafuegos del windows, Antivirus AVG free

Nunca habia presentado problemas con mi Bitcomet el cual ya tengo mas de 2 anos utilizando pero hace menos de un mes al obtener este nuevo Router comenzo mi dolor de cabeza;

en mi casa tenemos 4 laptop 3 conectadas por inalambrico y la mia la cual la conecto por cable al router, pues bien todos estamos trabajando sin problemas hasta cuando conecto el Bitcomet y comienzo a bajar algo todos pierden la conexion incluso yo, por el explorador, pero se mantiene el bitcomet funcionando perfectamente, es como si se apoderada el de toda la conexion y como es logico todos me empiezan a chillar... antes tenia mi viejito WRT54G sin ningun problema!! amigos les agradezco me den una luz!!

Saludos y gracias anticipadas

como dato importante al quitar el bitcomet, todos logramos la conexion de nuevo de inmediato

ya fui a esta pagina http://portforward.c...GS/BitComet.htm y no me resulto

Good evening. I'm a user of BitComet 1.20.

I have a USB-port ADSL SmartAx MTbb2a modem connected, which I don't use, for lack of drivers for my OS. My OS connects to a Linksys WRT54G2 router (upgraded with the latest official firmware). I haven't forwarded any port.

Windows 7, Windows firewall, AVG Free antivirus.

I had never had any problems with my BitComet, which I had been using for two years but, less than one month ago, when I acquired this new router, my headaches began.

In my house, we have 4 laptops: 3 connect wirelessly and mine, which I connect via a cable to the router. Right, well we're all working without problems up until I connect BitComet and start to download something. Everybody loses the connection (including myself), through/via the Explorer [iE?], but BitComet continues to function perfectly. It's as though it takes over the entire connection and, as would be logical, everyone begins to yell at me... before, I had my little old WRT54G without any trouble!! Friends, I'd really appreciate you shedding some light!!

Regards and thank you in advance.

As an important fact, when I turn off/shut down BitComet, we all regain the connection inmediately.

I already went to this page http://portforward.c...GS/BitComet.htm but it didn't help any.

Edited April 30, 2010 by cassie (see edit history)

[guess400]

el modem es un huawei SmartAx MT882a

The modem is a Huawei SmartAx MT882A.

Edited April 30, 2010 by cassie (see edit history)

[greywizard]

You should follow this guide and cap your upload speed to something lower than in the guide. I'd recommend 65-70%.

But you really need to perform the speed tests several times a day (say, in the morning, at noon, and in the evening) and preferable for more than one day (with no other PCs and applications using the net at that moment) in order to get a realistic view of the network speeds you get. Then make an average and use it in the calculations.

Deberías seguir esta guía y limitar tu velocidad de subida a algo más bajo que lo que ésta indica. Yo te recomendaría 65% - 70%.

Aún así, necesitas hacer las pruebas de velocidad varias veces al día (por ejemplo por la mañana, al mediodía y por la tarde/noche) y, preferiblemente, durante más de un día (sin que haya ningún otro programa o PC usando Internet, en ese momento), para que así puedas obtener una idea realista de las velocidades de red que puedes obtener. Después, calcula una media y usa ésta para tus ajustes.

Edited November 30, 2010 by cassie (see edit history)

[guess400]

Gracias amigo voy a intentarlo y le digo como me fue

Saludos

Thank you, friend. I'm going to try it and tell you how it goes.

Regards.

Edited May 4, 2010 by cassie (see edit history)

[gatoakuma]

Hola amigo, ami me sucedio este problemilla hace mucho tiempo, cuando cambie de version de Bitcomet, al abrirlo ya no podia navegar por internet.

Lo solocione así; Deshabilitando la red DHT.

1.- Abres Bitcomet

2.- Herramientas -> opciones -> Tarea -> BitTorrent

3.-Quito la palomita que esta en la opcion de arriba "Habilitar red DHT"

4.- Cierras Bitcomet

6.- Reinicias tu equipo y listo. espero te sirva

gatoakuma

Hello friend.

The same problem happened to me a long time ago, when I changed versions - when I opened it, I couldn't surf the Net.

I solved it, by doing this - disabling the DHT network:

1. You open BitComet.

2. Tools--> Options--> Task--> BitTorrent

3. Uncheck "Enable DHT network"

4. Close BitComet

5. Reboot your computer and Voilà.

I hope this helps you.

gatoakuma

Edited November 30, 2010 by cassie (see edit history)

[cassie]

Hola, gatoakuma.

Me temo que tu sugerencia no va a solucionar el problema que describió guess400, en mayo.

Me explico:

El DHT sólo te ayuda a buscar otros pares ("peers") con quien intercambiar las piezas del torrent, aparte de los que te puede ofrecer un rastreador.

En tiempos recientes, han habido algunos sitios índice ("index sites") que, por causas legales, han dejado de tener su propio rastreador y han optado usar otros medios para que los pares se encuentren, entre si mismos. ¿Cómo? A través de DHT.

Conforme digo esto, el primer sitio que me viene a la mente, como ejemplo, es el de Pirate Bay. Ahora, para poder descargar cualquiera de los torrents que están listados en sus páginas, se necesita usar DHT, ya que no poseen rastreadores propios. Sin embargo, si se ha deshabilitado esta función en el cliente (BitComet) pues... bueno te lo imaginas.

Por eso es mejor la solución que le ofreció greywizard, de ajustar sus parámetros de velocidad (bien de subida, como de bajada y LT Seeding) especialmente cuando eran varios los usuarios que compartían la misma conexión.

Hello, gatoakuma.

.

I'm afraid that your suggestion is not going to solve the problem which guess400 described, in May.

Let me explain myself:

DHT is only going to help you to find other peers, with which to interchange the pieces of the torrent, besides those which a tracker may offer you.

In recent times, there have been some index sites that, for legal reasons, have stopped having their own tracker(s) and have opted for using other means for peers to find each other, How? Through the use of DHT.

As I say this, the first site that comes to mind, as an example, is that of the Pirate Bay. Now, in order to be able to download any of the torrents that are listed in their pages, DHT needs to be used, since they do not posses their own trackers. However, if this function has been disabled in the client (BitComet) well... you can imagine.

That is why the solution that greywizard offered him is better - that of adjusting the parameters of his speed (both uploading, downloading, and LT Seeding), specially when there were various users that were sharing the same connection.

[jove724]

A mi me ha pasado un caso parecido al de guess400.

Resulta que al arrancar Bitcomet v1.24 el router (Thomson TCW710) rebota. He probado el método que gatoakuma sugería y desde entonces no me ha sucedido más. El problema es que, como comenta cassie, se necesita tener habilitado el DHT network para poder hacer búsquedas ya que la mayoría de los torrents, al intentarlos bajar piden que se habilite el DHT network. O sea que lo de desabilitar el DHT network es un "apaño" para poder realizar descargas sin que el router rebote, pero no es la solución definitiva.

Si alguien tiene una sugerencia se lo agradecería.

I've encountered a situation similar to that of guess400.

It so happens that upon starting BitComet 1.24, the router (Thompson TCW710) 'bounces back' [rebuffs??]. I've tried the method that gatoakuma suggested and, since then, it hasn't happened again. The problem is that, as cassie says, one needs to have DHT enabled, in order to do searches as the majority of torrents, when you try to download them, ask that the DHT network be enabled. Thus, disabling the DHT network is a "workaround" [quick fix] to be able to download without the router 'bouncing back', but it's not the definitive solution.

If someone has a suggestion, I'd appreciate it.

Edited December 8, 2010 by cassie (see edit history)

[kluelos]

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.

Edited December 10, 2010 by cassie (see edit history)

[jove724]

El problema no es que la conexión me vaya lenta cuando conecto bitcomet con "DHT NEtwork on", lo que ocurre es que el router REBOTA (se re-inicia) solo. La conexión que tengo es de 12 Mb reales download y 1 Mb de subida. Tengo configurada las descargas a 500MB (4000 Mb), es decir un 30% de la capacidad total del enlace. Con DHT Netrwork off, las descargas funcionan (aunque algo lenta) pero cuando modifico el DHT Network a on, al cabo de unos pocos minutos el router vuelve a rebotar. Voy a intentar coger trazas de la salida ethernet con el ethereal a ver si veo que tipo de paquete es el que provoca esta situación.

The problem isn't that the connection slows down when I connect BitComet with DHT Network turned "on",, what happens is that the router re-boots, by itself.

The connection that I have is 12 Mb ("real") down and 1 Mb up. I have the downloads configured at 500 MB (4000 Mb), this is to say 30% of the total capacity of the link [?/connection].

With DHT Network "off", the downloads work (though somewhat slow), but when I change the DHT Network to "on", after a few minutes the router, once again, re-boots.

I'm going to try to [obtain traces/track down] from the ethernet exit with the ethereal, to see what type of packet is provoking this situation.

Edited December 24, 2010 by cassie (see edit history)

[greywizard]

The obvious issue here is your router. Certain routers can't handle a high number of simultaneous connections (or to be more accurate, active entries in the NAT table), beyond a certain limit. Be it due to the fact that they run out of memory or whatever other error, when this happens the router halts/crashes and finally reboots itself.

BitComet (with DHT enabled) sends very many UDP packets to different IP addresses (UDP being the transport protocol for DHT). LT-seeding also uses by default the UDP protocol for transport besides TCP. That combined can easily mount up to a 1200-1800 simultaneous active entries into the NAT table of your router.

You could try disabling only LT-Seeding and see if that brings you under the crash threshold while still being able to use the benefits of DHT.

But if that doesn't help, other than changing your router with a different model which doesn't present this type of issue, I don't see any quick fix for your problem.

Unfortunately, there is not, at present time, any modality to limit the number of simultaneous "UDP active sockets" so to speak, meaning that you can't limit to how many different IP addresses UDP datagrams can be sent in a certain preset amount of time.

We've already repeatedly demanded to the dev team that such an option be included in Advanced Options if possible. Tweaking that could help restrict the number of new entries added to the NAT table per time unit, leaving enough time for the older ones to expire and perhaps avoid this situation in cases of routers like yours.

But until such an option will be available (if that's even feasible to code) the only solution I can think about, is for you to find a router that can handle more "connections" than your actual one. That should take care of your problem.

El problema obvio aquí es con tu rúter. Ciertos ruters no pueden manejar un alto número de conexiones simultáneas (o, para ser más preciso, entradas activas en la tabla NAT), más allá de cierto límite. Bien sea porque agotan su memoria o cualquier otro error, cuando esto ocurre, el rúter se detiene/"estrella" y, finalmente, se reinicia.

BitComet (con DHT habilitado) envía muchos paquetes UDP a distintas direcciones IP (siendo UDP el protocolo de transporte para DHT). 'Semilla a Largo Plazo' ("LT-Seeding") también usa, por defecto, el protocolo de transporte UDP, además de TCP. Esta combinación puede fácilmente ascender hasta 1200-1800 entradas activas simultáneas en la tabla de tu rúter.

Podrías intentar deshabilitar sólo el LT-Seeding, y ver si eso te aproxima al umbral de 'estrello', mientras puedas seguir aprovechándote de los beneficios de DHT.

Pero si eso no te ayuda, aparte de cambiar de rúter con otro modelo que no presente este tipo de problema, no veo ningún arreglo rápido para el mismo.

Por desgracia, no hay, de momento, ninguna modalidad para limitar el número de "sockets UDP activos", por decirlo de alguna manera, lo cual significa que no puedes limitar cuantas direcciones IP UDP datagramas pueden ser enviadas, dentro de un cierto tiempo predefinido.

Nosotros ya hemos exigido repetidamente al Equipo de Desarrollo que tal opción fuese incluida dentro de las Opciones Avanzadas, a ser posible. Algo que pudiese restringir el número de nuevas entradas añadidas a la tabla NAT por unidad de tiempo, dejando suficiente tiempo para que las antiguas pudiesen caducar y, quizás, evitar esta situación, en el caso de ruters como el tuyo.

Pero, hasta que tal opción sea disponible (y si ésta fuese factible de codificar) la única solución que se me ocurre, es que encuentres un rúter que pueda manejar más "conexiones" que el actual. Eso debería de subsanar tu problema.

Edited December 27, 2010 by cassie (see edit history)

[kluelos]

You might explore swapping routers with someone else. This issue doesn't make the router bad in any sense, just unsuitable for bittorrenting. If you know someone who doesn't do that and doesn't intend to start, you may well be able to swap with them to your mutual happiness.

Quizás podrías considerar el cambiar rúter con otra persona. Esta situación no significa que el rúter es "malo", de ninguna forma, solamente que no es apto para bittorrent. Si conoces alguien que no usa bittorrent (y no tiene intención de empezar a hacerlo), posiblemente puedas intercambiar dicho aparato con él, para un disfrute mútuo.

Edited December 27, 2010 by cassie (see edit history)

[cansogain]

Hola Seeder:

A ver cómo me explico.

Pese a que te puedo asegurar que debes hacer caso a todos los compañeros que aquí te aportan soluciones, (( a cual más diligente)), yo intentare aportar un granito mas de arena, que si de por si es insignificante, no por ello es menos importante.

Tal como te dicho, haz caso de todo los consejos que te han ofrecido en este foro, ((ahora bien)), te aconsejo mantener el [DHT] conectado.

Por otro lado, deberías tener en cuenta los temas que descargas. Como bien sabrás, no es lo mismo descargarte una de las últimas novedades del tema que sea, que descargarte los últimos éxitos de Paco Porras.

.- No satures tu BitComet, ... hazte cuenta que la red P2P es una red de intercambio, pero de la misma forma esta puede disminuir (( darte un tijeretazo)), si los torrents en descarga activos que tienes son excesivos.

.- Fíjate bien en tus conexiones.... Si usas DHT, estas utilizando puerto UDP, a parte de los puertos TCP, ... esto puede llegar a crear una saturación en tu ancho de banda.

Los UDP ((hablan y escuchan))... lo cual quiere decir que por cada paquete recibido tu pc envia una confirmación del mismo..... (( Desventajas: SATURACION))...

Por hacerte una similitud.... será como un ataque a un servidor por Ddos ((envío masivo con peticiones masivas de recepción de envío)).

Por supuesto, teniendo habilitado tu puerto TCP y el nódulo DHT, (( aun a riesgo de ralentizar tu navegacion por la web)), la velocidad de descarga en tu BitComet debería ser optima

Aquí te envío una muestra ((más o menos de las prestaciones que puedes sacar a este estupendo gestor))

Espero que este pequeño aporte te sirva de algo.

Hello, Seeder:

Let's see if I can explain myself.

Although I can assure you that you should take heed of all of the solutions that the colleagues here provide for you (bar none more diligent), I'll try to provide one more small grain of sand that although, in itself, may be insignificant, makes it no less important.

As I have said, heed all of the adivce that you were offered in this forum. Now, then, I recommend leaving the DHT enabled.

On another note, you should take into account the contents of your downloads. As you will undoubtedly know, it's not the same thing to download the latest novelties of a certain topic, than it is to download the latest hits of Paco Porras.

• Don't overload your BitComet... bear in mind that the P2P network is one for interchanging but, by the same token, this may decrease if your number of active downloading tasks is excessive.

• Look closely at your connections... If you use DHT, you are using a UDP port, as well as TCP ports - this may end up causing your bandwidth to become saturated.

The UDPs (speak and listen)... which means that, for every packet received, you PC sends back a confirmation of its receipt (Disadvantages: Saturation). To give you an idea of something similar... it would be like a DDOS attack to a server (a massive send-out with massive requests for reception acknowlegements)

Of course, having your TCP port and your DHT node enabled (despite of the risk of idling your surfing), your BitComet download speed should be optimal.

Here, I'm sending you a sample (more or less) of the options that you can obtain from this wonderful [downloading management client].

Number of downloads: 0

I hope that this small contribution is of help to you.

cansogain - [[AgAmEnOn]] ©

Visitanos en DuendesIrc

http://noestamospato...s.webgarden.es/

©Un saludo,问候

Facebook cansogain - Skype - [[AgAmEnOn]]- Msn cansogain - [[AgAmEnOn]]

Edited January 13, 2011 by cassie (see edit history)