syockit Posted December 1, 2009 Share Posted December 1, 2009 BitComet version 1.16 stable release On Cable Internet (ADSL equivalent), up/down: 30Mps/8Mps Wireless router: Corega CG-WLBARAGM, port forwarding enabled (failed though for some reason) OS: Windows Vista Home Basic SP2 Japanese Firewall: Windows Firewall A/V: Windows Defender (malware protection only) I want to use BitComet because it doubles as a HTTP downloader (with mirror support). That's why I will have it in the tray at all times. But I come across this problem with BitComet (which I also see in other computers using BitComet) where other internet applications stop working i.e. internet connection lost. There are no active downloads, the list is empty yet this problem occurs. Is there something that BitComet do when idle? As for other computers I get the point as they always have something downloading, but mine is empty. Yet my browser becomes unusable, and IM clients (Yahoo! Messenger) becomes disconnected. When that happens I usually exit BitComet client and the problem resolves. What is the cause for this? Would speed settings have anything to do with it? Link to comment Share on other sites More sharing options...
greywizard Posted December 1, 2009 Share Posted December 1, 2009 The only network activity BC does when not downloading anything is DHT Network bootstrapping and control traffic. But that amounts to a negligible traffic, as compared to your connection specs. It may use several connections, though. Try disabling DHT to test if this makes any difference. Link to comment Share on other sites More sharing options...
kluelos Posted December 1, 2009 Share Posted December 1, 2009 A typical cause of this symptom is a router which cannot handle the very large number of connections which P2P makes. Because your router is Japanese and all of the distribution/documentation/commentary is likewise in Japanese, I can't say whether yours is reported to have these issues. The problem typically occurs in routers that try to "help" you by memorizing connections that you use frequently. For most things, that's a good idea. It's not a good idea for P2P, which makes hundreds of connections per hour to peers,and seldom re-uses any of them. The problem arises when the router's memory for these connections fills up. A few routers do not handle this gracefully, and drop the connection until they're reset. You can try temporarily taking the router out of the loop and connecting directly to the modem (remembering to change your network settings when you do this), in order to see if that makes the problem go away. If so, then you will need to replace the router with a different make/model that does not have these issues. Link to comment Share on other sites More sharing options...
greywizard Posted December 1, 2009 Share Posted December 1, 2009 I've been doing a little searching and it seems that he might be out of luck with that. The router seems to be integrated with the modem (don't you just love guessing?), though I might be wrong, since Google Translate comes up with the most weird translations. Link to comment Share on other sites More sharing options...
sophia0316 Posted December 2, 2009 Share Posted December 2, 2009 I asked the team, they suggest you try the following: 1. Disable UDP protocole: Options->Advanced, set bittorrent.connection.ltseed_protocol_selection as 1. 2. Limit your Longtime seeding rate in Options->Long-time seeding Link to comment Share on other sites More sharing options...
syockit Posted December 2, 2009 Author Share Posted December 2, 2009 (edited) Sorry to forget to mention the modem (I always forget this thing), it's a Motorola Surfboard SB5100. Greywizard, after disabling DHT, I seem to have no problem surfing for hours. That might be the culprit. Though I'm not sure if not having DHT while downloading torrents in the future will affect my d/l speed (as long as you have connection to tracker, no problem right?). Kluelos, Does this apply to when you're not doing anything with BitComet too? Sophia, Okay, gonna try enabling DHT again and use TCP only, and limit long-time seeding rate to same as upload (50 kB/s). Gonna try surfing (without any torrents downloading) again tonight... Just for reference (since other suggestions seem to involve download speed), speedtest.net gave me 10.21/1.94 Mbps Edited December 2, 2009 by syockit (see edit history) Link to comment Share on other sites More sharing options...
kluelos Posted December 2, 2009 Share Posted December 2, 2009 BitComet's implementation of the Distributed Hash Table requires UDP. If you disable UDP, then DHT stops functioning. Since The Pirate Bay has abandoned their tracker, DHT is a main source of peers for them, and will become more widely used in the future. A router that cannot handle UDP is basically defective. Most activities do not have great numbers of connections in order to do what they do. Normal http transfers (web traffic), email, chatting, none of these require great numbers of connections. Bittorrent does, though. It's not just BitComet, it's any P2P client because they're not connecting via a single server -- they're connecting to thousands of peers directly, in a short amount of time. Link to comment Share on other sites More sharing options...
syockit Posted December 6, 2009 Author Share Posted December 6, 2009 (edited) Thanks for your answer. Even after disabling UDP, BitComets seems to still manage to connect to the DHT network. And interrupts my internet activity (Skype voice calls abruptly end, Yahoo Messenger logs out, etc). I understand about P2P and the many connections it makes, but all other torrent clients I've used so far never does so. And they usually set maximum number of connections to 200 or so, more than what I currently set. I suspect this problem has nothing to do with number of connections etc. Since disabling DHT seems to solve the problem, maybe the cause of problem lies there? Even so, other torrent clients don't seem to have problems connecting to a DHT network. The mystery deepens... By the way my router has problems with UPnP but I suppose that's nothing to do with this (I'll solve that port forwarding thing later... hint: other torrent clients work correctly) Edited December 7, 2009 by cassie Omitted entire full quote (see edit history) Link to comment Share on other sites More sharing options...
kluelos Posted December 6, 2009 Share Posted December 6, 2009 Depends on exactly how you went about disabling UDP. If you were following Sophia's advice, this disables UDP for use by LT seeding -- only. It does not disable all UDP and particularly not for DHT. If you want to disable UDP altogether, then block that protocol for your listen-port. (If you DO that, then please let us know that you did so.) This leaves the situation completely confused. You said, after disabling UDP, BitComets seems to still manage to connect to the DHT network which indicates that you did not disable DHT, but you also said,Since disabling DHT seems to solve the problem which suggests that you did do SOMEthing that solved the problem, though we now don't know what that was. So, is your problem solved, or isn't it? Does BitComet currently say that DHT is connected, or that it is disconnected? All Bittorrent clients make these same very large numbers of connections. They consist of you connecting to many other peers, and even more peers connecting to you. That's how bittorrent works. Instead of you connecting to a single server, you've got all these incoming and outgoing connections happening irrespective of which client you're using at the time. Contrary to your assertion, all clients do this. Connecting to the DHT network simply adds more connections (albeit UDP only) to this stew, it doesn't take any away. However, if other clients are now working correctly for you, then you should use them. Anecdotal evidence isn't of much use trying to resolve the issue and we're a long way from being able to rule out numbers of connections as an issue. In the meantime, you left us hanging. Did you try taking the router out of the loop? What happened when you did? A large number of routers have problems with the implementation of UPnP, which is why we don't recommend it: if there are problems, there's no way to diagnose them, let alone correct them. But yes, it's an entirely separate issue. At this point you're probably better off disabling UPnP on both ends for now. You certainly don't need it complicating matters. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now