Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About drizzle

  • Rank
    Advanced Member
  1. re: PEX flood bans Just tried two more torrents, one with ~800 peers, one with ~250; yielding 15 and 8 bans respectively. I would say the changes have helped. (but hope you eventually find the real bug).
  2. re: PEX flood bans Tried the 23908 build with the PEX flood updates. Loaded three torrents, approx 250, 30, and 10 peers. Ended up with 8, 1, and 0 bans (below). Perhaps some marginal improvement, but still occuring. Torrents started at 16:39; logging stopped when DLing done.
  3. re: PEX flood bans Until you can figure out the 'flood detection' issue, could you disconnect but NOT ban the peers, or perhaps impliment a three-strikes limit before doing the ban?
  4. more info - started up two torrents, with logging to a file. bans extracted from log (edited to remove torrent names) for torrent1, peer list has 93 entries, 15 banned for torrent2, peer list has 21 entries, 3 banned My gut tells me this is a 'flood detection' issue, not a 'faulty client' issue. [2010-12-12 09:24:36] [uTP](torrent1): [µTorrent 2.2 (80.2)]: Disconnect: PEX message flood [2010-12-12 09:26:14] [uTP](torrent2): [µTorrent 2.0.2 (100.0)]: Disconnect: PEX message flood [2010-12-12 09:26:43] [uTP](torrent1): [µTorrent 2.0.2 (62.1)]: Disconnect: PEX message flood [2010-12-12 09:26:44] [uTP](torrent1): [µTorrent 2.2 (3.5)]: Disconnect: PEX message flood [2010-12-12 09:26:51] [uTP](torrent1): [µTorrent 2.0.4 (100.0)]: Disconnect: PEX message flood [2010-12-12 09:27:16] [uTP](torrent2): [µTorrent 2.2 (67.9)]: Disconnect: PEX message flood [2010-12-12 09:27:22] [uTP](torrent1): [µTorrent 2.2.1 (46.4)]: Disconnect: PEX message flood [2010-12-12 09:32:59] [uTP](torrent1): [µTorrent 2.0.1 (100.0)]: Disconnect: PEX message flood [2010-12-12 09:38:31] [uTP](torrent1): [µTorrent 2.2 (3.8)]: Disconnect: PEX message flood [2010-12-12 09:44:03] [uTP](torrent1): [µTorrent 2.0.4 (0.6)]: Disconnect: PEX message flood [2010-12-12 09:44:44] [uTP](torrent1): [µTorrent 2.2 (3.8)]: Disconnect: PEX message flood [2010-12-12 09:46:06] [uTP](torrent1): [µTorrent 2.0.1 (100.0)]: Disconnect: PEX message flood [2010-12-12 09:48:43] [uTP](torrent1): [µTorrent 2.0.4 (12.5)]: Disconnect: PEX message flood [2010-12-12 09:51:40] [uTP](torrent1): [µTorrent 2.2.1 (8.2)]: Disconnect: PEX message flood [2010-12-12 10:08:25] [uTP](torrent1): [µTorrent 2.0.4 (87.6)]: Disconnect: PEX message flood [2010-12-12 10:23:01] [uTP](torrent1): [BitTorrent 7.2 (77.4)]: Disconnect: PEX message flood [2010-12-12 10:24:24] [uTP](torrent1): [µTorrent 2.2 (61.5)]: Disconnect: PEX message flood [2010-12-12 10:30:27] [Transmission 2.04 (100.0)]: Disconnect: PEX message flood [2010-12-12 10:33:54] [Azureus (100.0)]: Disconnect: PEX message flood [2010-12-12 10:40:13] [uTP](torrent1): [µTorrent 2.2 (5.5)]: Disconnect: PEX message flood [2010-12-12 10:56:49] [Azureus (100.0)]: Disconnect: PEX message flood [2010-12-12 11:19:54] [uTP](torrent1): [µTorrent 2.0.2 (100.0)]: Disconnect: PEX message flood [2010-12-12 11:25:20] [µTorrent 1.8.3 (100.0)]: Disconnect: PEX message flood [2010-12-12 11:35:47] [Azureus (100.0)]: Disconnect: PEX message flood [2010-12-12 11:47:39] [uTP](torrent1): [BitTorrent 7.2 (100.0)]: Disconnect: PEX message flood
  5. Not sure how you define 'often', but it seems some number get banned with nearly every public torrent I start. Disabling PEX (and resetting the bans) picks up the peers. As anecdotal (not statistical) observations - saw 'BitTorrent 7.2' getting banned a lot in one swarm, and 'Transmission 1.2' was the banned client in the small swarm mentioned above. I'd have to collect log files to see if that was a fluke or a pattern, but the bans I'm seeing "feel" excessive.
  6. I, also, would like some news/status on the PEX flood ban issue. BTW, it isn't just large swarms: 1 seed, 13 peers, and 2.0.4 banned a peer.
  7. YEAH! http://forum.utorrent.com/viewtopic.php?id=61934
  8. In the current beta, when both TCP and uTP are enabled for outgoing connections, which has precedence? (i.e. which is attempted first)? Or does it depend upon how the peer is discovered (tracker, peer exchange, dht)?
  9. drizzle

    BEncode Editor

    "bad shutdown" - hmmm... My recent experience (see bug report forum) is that utorrent accepted the resume.dat data even though the hash check failed. Yes, it renamed it .bad when it was done, but it still accepted the contents. (This was with 1.7.2 - don't know about other versions) Anyway, thanks for the clarification. I'll give that a whirl next time...
  10. drizzle

    BEncode Editor

    Thanks for the response. However, in looking over the replies to this thread, you might notice that most people are interested in using it for resume.dat editting. As such, and as a feature request for a future release, please consider adding logic along the lines of: If .fileguard present, then compute hash when saving the file. In any event, thanks again for creating this tool. PS - I'm still confused as to utorrent's use of the fileguard element, as it seems willing to accept the data in files that fail the hash check (or don't have the element at all? have not tried that yet). PPS - Just noticed your edit - which makes the fileguard element seem even less useful ??
  11. drizzle

    BEncode Editor

    I was under the impression that that was part of the feature set of this tool - ie that if you modified resume.dat that the tool recalculated the fileguard hash value so utorrent would be happy with it. And yes, thanks Ultima - but am I missing something? People in this thread talk about using it to modify resume.dat, but noone else has asked about the hash issue? IE - Am *I* doing something wrong? or am *I* misunderstanding what the tool does? And further, if the hash isn't right, is it expected that utorrent will go ahead and use it anyway ?! Oh and PS - I was using the 0.4.1 unicode version. FYI - It seemed to work on W2K except that the drop downs on the find/replace dialogue had no options (but I ended up doing the edits on an XP system) jewelisheaven - re: your other questions (wrt the bug report) - I've added the msg to it, and yes I'm sure the .old wasn't involved as I moved everything out the directory when experimenting.)
  12. drizzle

    BEncode Editor

    I'm a bit confused about this tool wrt resume.dat I have a resume.dat that utorrent doesn't like (after a system crash) ie - When starting, utorrent logs "Warning: file integrity check failed (hash doesn't match): ...\resume.dat", renames the file .bad and I loose ALL torrent info. I pulled this resume.dat up in this editor. The editor does NOT report any hash error. (huh?) I deleted the last torrent, then saved the file. The fileguard hash value did NOT change. I started utorrent using the modified resume.dat. Again, I got the SAME error in the utorrent log, BUT, utorrent went ahead and used the resume data anyway - ie I did NOT loose everything (just the one torrent I deleted with the editor). Is this the way everything is SUPPOSED to work? When does this editor recompute the hash? Why does utorrent say the hash fails (both orig and modified), but the editor doesn't? Why does utorrent go ahead and use the modified 'bad' file, but not the original? ???