the forums at degreez.net

It is currently Thu Mar 28, 2024 6:04 am

All times are UTC - 7 hours [ DST ]




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jan 31, 2007 8:02 am 
Offline

Joined: Thu May 20, 2004 11:57 am
Posts: 8
I was looking through the bitcomet forum, and I could only find one thread were the problem with bitcomets bad behaviour with super-seeds was discussed. The administrators of the forum are responding in a responsible way and are willing to discuss the issue.

But there is a problem - _nothing_ substantial against bitcomet have come up, no facts at all have been given. You really get the idea that it's all just evil rumors, and also that the issue possibly lies with the clients with super-seed implemented. If you read this, TheSHAD0W, couldn't you make a comment in the thread at the forum and simply put down some actual facts and the technical background of what you have seen bitcomet do, and your conclusion of that? I think many in the staff at the forum would be genuinely interested in getting a solid startpoint for a discussion about this.

The thread: http://forums.bitcomet.com/index.php?showtopic=6315

All the best!

edit: If you don't bother signing up and participating in that forum, you could just give a response to it here, and I'll quote you in the thread there.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 01, 2007 3:36 am 
Offline

Joined: Thu Mar 11, 2004 12:15 am
Posts: 534
Problems I've seen first-hand with BitComet

> Horrid to nonexistent upload slot management.
BitComet will continue to open upload slots until it's uploading at a trickle-pace to everyone it's connected to.
This is most pronounced watching from a real-world swarm connected to by a Shareaza client. A lot of the time with shareaza downloading, emule clients will upload to me faster.
> Horrid seeding queues.
BitComet will leave ALL completed torrents seeding until they are stopped, either by ratio rules or by the user. This, coupled with the upload slot management causes an even smaller trickle of data being sent per upload.

Problems I've seen reported:
> Optimistic Unchoke gaming
BitComet will reportedly abusively disconnect and reconnect from a peer in an attempt to bring its position in the optimistic unchoke queue closer to the top. It's hard to say if this works or not, depending on the queuing system used by a given client, but it still causes needless bandwidth waste with connection negotiation that simply doesn't need to be there. Optimistic unchoke cycles on a given peer can take up to 30 minutes to complete, depending on client and swarm conditions.

> Superseed gaming
This one is a tricky one, and I don't have as much technical information about it myself as others do. I'll see about getting such information.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 10, 2007 6:36 pm 
Offline

Joined: Thu May 20, 2004 11:57 am
Posts: 8
Ok, thanks. It's info about the super-seed gaming which is of interest, the other things are mostly annoyances.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 01, 2007 7:24 am 
Offline

Joined: Thu May 20, 2004 11:57 am
Posts: 8
So there's no one here that have any evidence what so ever for bitcomets super-seed gaming?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 03, 2007 1:59 pm 
Offline

Joined: Thu Mar 11, 2004 12:15 am
Posts: 534
I'm working on getting TheSHAD0W to get the evidence.

It's probably just that it needs to be sorted and such.

We're also going to triple-check the behavior in our testing environments.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 01, 2007 1:13 pm 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
naugas wrote:
So there's no one here that have any evidence what so ever for bitcomets super-seed gaming?


Just watch it in Azureus or uTorrent with logging enabled, it's plainly observable -- even up to the latest version of BitComet does this:

1. Super-Seeder sends HAVE message
2. BitComet sends INTERESTED
3. Super-Seeder sends UNCHOKED
4. BitComet sends REQUESTs (in a pipeline manner, as expected)
5. Super-Seeder sends PIECE DATA
6. #4 and #5 above repeats
7. Super-Seeder sends CHOKED
, and so far everything has been going as expected, until...
8. BitComet unexpectedly closes the connection as soon as the last of the seeder's cached data goes out over the wire
9. The same BitComet client connects to the Super-Seeder


#8 above happens about 2 out of 3 times, I'm still not sure what the algorithm is -- but my current suspicion is that it does not disconnect if BitComet did not collect a full piece before being choked by the Super-Seeder. If true, that makes sense because the Super-Seeder is not going to offer the same piece to BitComet if it reconnects.

#9 above gives BitComet an advantage, because newly connected clients are three times more likely to get an optimistic unchoke than the other peers in your list.

What is expected is:

8-expected. BitComet sends a HAVE message for that piece (and others it received from other peers) as soon as the seeder's cached data goes out over the wire
9-expected. BitComet waits and continues to send HAVE messages for pieces received from other peers until #1 above happens again.

After watching that cycle repeat with various versions of BitComet, now watch some of your other peers and see how they behave differently.

I'm a frequent uploader (first seeder) and I've tried a number of strategies. I'm here today because I'm checking out the latest BitTornado Experimental.

I have made a suggestion to the µTorrent developers on their forum, which you can read there. (post id #22417)

Using Azureus 2.5.0.4 with the Stuffer plug-in, if I ban BitComet and BitLord (same engine), I consistently get my first peers completed after uploading 105% of the file size (my uploads run about 700 MB).

Without the ban, but restricting my connected peers to a low number to foil reconnecting, it is 125% with some variance, increasing proportionately with the number of BitComet/BitLord clients that are in the swarm (each one "steals" a piece, and a good percentage of these never seem to show up later).

Without the ban or peer connections restriction, it can go to 150%-200% (I seldom run in this mode).


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 13, 2007 11:18 am 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
At the moment, I must retract my above message until I can do more testing. My ISP (Comcast) is responsible for some of these disconnects, using a filter known as Sandvine.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 21, 2007 8:41 pm 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
DWKnight wrote:
Problems I've seen first-hand with BitComet

> Horrid to nonexistent upload slot management.
BitComet will continue to open upload slots until it's uploading at a trickle-pace to everyone it's connected to.
This is most pronounced watching from a real-world swarm connected to by a Shareaza client. A lot of the time with shareaza downloading, emule clients will upload to me faster.
> Horrid seeding queues.
BitComet will leave ALL completed torrents seeding until they are stopped, either by ratio rules or by the user. This, coupled with the upload slot management causes an even smaller trickle of data being sent per upload.


Okay, I've had a few days to work on this.

Both still happen in BitComet v0.90 when BitComet is a seeder. I do not understand the rationale for this design.

The reason it's a bad choice for BitComet is because it takes BitComet an awfully long time to complete a piece. In a swarm, the peers are supposed to be requesting the rarest piece. In a swarm full of BitComet seeders, nobody is really ever choked -- so even though your client might accurately ask for a rarer piece, your client has no way of knowing that 18 other people have been downloading that same piece for the past half hour -- and another piece that nobody is downloading would be a better choice.

I still want to do more testing with BitComet as a non-seeding peer. The above only applies to BitComet as a seeder, at the moment.

DWKnight wrote:
Problems I've seen reported:
> Optimistic Unchoke gaming
BitComet will reportedly abusively disconnect and reconnect from a peer in an attempt to bring its position in the optimistic unchoke queue closer to the top. It's hard to say if this works or not, depending on the queuing system used by a given client, but it still causes needless bandwidth waste with connection negotiation that simply doesn't need to be there. Optimistic unchoke cycles on a given peer can take up to 30 minutes to complete, depending on client and swarm conditions.

> Superseed gaming
This one is a tricky one, and I don't have as much technical information about it myself as others do. I'll see about getting such information.
Both of these alleged behaviors are related. The report was that BitComet would disconnect without acknowledging the piece it just received from the sender. Upon reconnect, it would have 33% better chance in gaining an advantage due to the way optimistic unchoking handles newly-connected peers.

I was reproducing this disconnect behavior consistently -- but then later realized that it was being caused by P2P "management" by my ISP using a man-in-the-middle TCP/IP RST attack^H^H^H^H^H^H -erm- "method." This is not entirely my ISP's fault -- had I not been focusing entirely on BitComet, I should have noticed more quicly than I did that the disconnection was happening with every other client as well.

This problem, if it ever actually existed, does not exist in BitComet 0.90.


Top
 Profile  
 
PostPosted: Mon Jun 25, 2007 4:50 pm 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
The thread is at forums (dot) bitcomet (dot) com (slash) index.php?showtopic=12787870

... it confirms that BitComet does drop off from the Super-Seed, but it also explains why ...

Quote:
First and foremost, I'd like to say thumps up to the developers, for updating BitComet this frequently. Still it has some bugs, but it's pretty much stabile now. :)

I've been gone for quite a while, but well, I stumbled across this thread from the developer of "BitTornado", i.e "theSHADOW".

This: forums (dot) degreez (dot net (slash)viewtopic.php?t=7078

And then This: forums (dot) degreez (dot net (slash)viewtopic.php?t=7079

IS THIS CONFIRMED?
If it's not true, why does he claim this? He sounds pretty pissed off and I understand him, if he has put a lot of work and time into developing the superb function "SuperSeeding", and then it gets exploited by BitComet.
Furthermore, if it's true that BitComet counterattacks BitTornado when theSHADOW tries to close the bug, then I clealy understand why trackers still ban BitComet.

BitComet is still my absolute favorite client, but I'm getting distrustful, when I read stuff like this over and over again.

Please, can someone explain to me, what's going on between theSHADOW, BitComet's dev. and SuperSeeding (aka. Initial Seed)?

Regards
XSTREM.



Quote:
name='kluelos' date='Jun 25 2007, 10:04 AM' post='30032'
No, it isn't true. Basically, Shadow's an idiot and owes BitComet a huge, groveling apology for screwing up. Instead, he decided to blame BC for his own error. He decided that all clients ought to behave in a certain way that wasn't required by the spec. BitComet was already out there, and already behaved differently, but Shadow couldn't be bothered to actually test his modifications, or to learn that all clients did not behave the way he thought they did.

Understand, BitComet was already out there, had been for quite a while, so this was entirely Shadow's fuckup. He knew or should have known better, and elementary testing would have demonstrated that. He didn't bother to do that, and now blames BC for it rather than admitting his mistake and fixing it. Worse, he's decided to Balkanize the bittorrent community by his actions. People should generally avoid using later versions of his client for that reason.

Super-seeding makes a client look like just another peer instead of a seed. From time to time it "discovers" a new piece to share. The rest of the time it looks like another peer, and not a particularly good one. So BitComet very properly elects to drop that connection in search of a better one. BitTornado wasn't expecting that and doesn't persist the information about that connection - so when the connection's dropped, instead of remembering, BitTornado forgets all about it. Shadow blames BitComet for dropping the connection, instead of himself for not persisting the information. Nothing in the spec required BitComet to keep the connection, and Shadow was a fool for relying on something not required by the spec. He claims this is deliberate malice, even though BC already behaved this way when he released the first version of his client. So we know it's because he didn't bother to test it in the real world before tossing it out there.

BTW, "super-seeding" doesn't. People should avoid using it unless they're in the very specific situation it was actually made for, namely those who pay for their internet connection by the uploaded kilobyte. It's designed to minimize their expense. Everyone else should avoid using it.



Quote:
name='XSTREM' date='Jun 25 2007, 01:20 PM' post='30049'
I see!
Then it's Shadow's fault all along. God dammit, I really hope this is read by tracker owners, that think that Shadow is the "hero" in this "game". Thank you very much for your great explanation!
Do you mind, if I copy/paste this, if I get into another discussion by some ignorant persons?

But I don't understand why he claims that BitComet sortof counterattacks his bugfixes? Is this more junk?
Super-seeding is actually a great feature, and I've been using it with µTorrent before. My torrents actually get healthy faster, than if I dosn't use Super-seed. Does Bitcomet ever get that option?

Thanks again.

Regards.
XSTREM.



Quote:
name='the5cardstud' date='Jun 25 2007, 02:19 PM' post='30059'
Kluelos, three questions --

#1 --
Thank you for this. This is the first time I've read that this behavior is intentional. Here is the real question: Does BitComet persist the information that "Super-Seeder" is a poor peer? Or does it, as alleged, immediately reconnect to the peer in order to get that 33% Optimistic Unchoke advantage that newly connected peers are supposed to get?

#2 -- Can you also address the issues raised by TheShadow in forums (dot) degreez (dot net (slash)viewtopic.php?t=7079 -- specifically:

Quote:
That's fine, but what if there are two BitComet peers sapping data off the super-seed? The seed has to duplicate the effort to send a piece to each BitComet peer, since the BitComet peers typically don't share very well and won't trade much with each other. Each piece one of the peers downloads from the super-seed is a piece that could have been sent to a peer with a fast upload rate which could have, directly or indirectly, sent that data to BOTH BitComet peers soon after it received the data.

This means that, while the bandwidth leeching gives BitComet users more bandwidth from a single, bandwidth-limited seed, when more than one BitComet peer is on a super-seeded torrent it makes their download time LONGER. This is especially true of their new cooperative gaming mode which REQUIRES more than one of their peers to be on that torrent.

So not only is BitComet damaging torrent performance for other downloaders, but they're also doing a disservice to their own users by sapping super-seed bandwidth.

I don't know what he's talking about here, Kluelos, so a technical answer would be helpful. (I know that TheShadow called BitComet's developers "stupid," but I think the high road would be to avoid namecalling and other distractions -- let's just speak with facts and work toward understanding.)

#3 -- As for Super-Seeding, my testing completely disagrees with your assessment. With Super-Seeding, I can seed a torrent with only 10% overhead. (Meaning: if I'm seeding a 100 MB torrent, I upload 110 MB of data in order to get the torrent well seeded, then I can disconnect.) Without Super-Seeding, I consume 30% to 50% overhead. I have 16 KB/s reserved for uploads, but these results are consistent, even up to 48 KB/s. I don't understand TheShadow's caution that Super-Seeding is for low-bandwidth connections -- it does very well at moderately fast speeds, too.

What am I missing here? Why is Super-Seeding anything but a good thing?

Rather than disconnect, why not detect Super-Seeders: they always connect with 0 pieces and they only offer unique pieces. That seems detectable -- mark clients as possible super-seeders and do not drop them until they offer a non-unique piece.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 25, 2007 9:51 pm 
Offline

Joined: Sun Mar 07, 2004 10:05 am
Posts: 1212
Very interesting. Yes, I understand the explanation. I do have some comments, however.

(1) Disconnecting from peers which you consider "poor" is not good behavior. I've monitored many torrents diagnostically and have discovered peers which don't have data you desire can suddenly make a "trading" arrangement with a third peer and be able to give you good working data. Considering the dozens of peer connections you have, maintaining a few "poor" ones isn't a serious hardship.

(2) If these peers are so "poor", why does BitComet immediately turn around and reconnect to them?

(3) This still doesn't explain the cooperative gaming, where peers will connect, download pieces, disconnect and then reconnect with fewer haves on their list.

I'd appreciate if someone would re-post this on the BitComet forum, I'd rather not have to maintain yet another forum login.

And thank you, funchords, for bringing this to my attention.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2007 1:53 am 
Offline

Joined: Thu Mar 23, 2006 6:40 pm
Posts: 67
bitcomet does have it use but is not a very good client.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2007 5:18 pm 
Offline

Joined: Thu Mar 23, 2006 6:40 pm
Posts: 67
bc use to be better now it is worse. super seeding never implemented the stupid author just doesn't see any use for it. actually this is good :) bittornado will alway shine in this area whether they implement it or not
not to mention that u use to be able to change the number of slot in bc in the previous version now you can't and on automatic it's always 31 regardless of your connection
bc IMHO is not a good leech or seeding client
it's main use is to index torrent for you and check the numbers of peers or seeds
it is now heavily spammed with stupid banner that rival that of bitlord
i guess they were related to begin with :lol:


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 07, 2007 1:15 am 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
You and I are in sync with point #1. But, AFAICT, that poor/bad behavior is at the disadvantage of the BitComet client. (And, I think you'll agree with me, that since BitComet's slot management currently will spread a unique piece more slowly than any other client, that it benefits the Super-Seeder).

Quote:
(2) If these peers are so "poor", why does BitComet immediately turn around and reconnect to them?


I cannot reproduce this with BitComet 0.90. Like I said before, I was seeing it all over the place -- but then I found out that my ISP's P2P management (abuse of the RST flag), coupled with my "looking" for that activity on BitComet connections, invalidated everything I had done. I'm now doing my testing through a VPN tunnel.

But what 0.90 is doing is dropping the connection after 60-90 seconds from being choked by a peer (just as you said in point #1) , but it is not immediately attempting to reconnect. Even though we both may believe that disconnecting as it does is a surprising thing to do, the behavior is consistent with the "BitComet thinks it's a poor peer" explanation. There is that 60-90 second delay before disconnecting and there is no immediate attempt to reconnect.

Quote:
(3) This still doesn't explain the cooperative gaming, where peers will connect, download pieces, disconnect and then reconnect with fewer haves on their list.
This is the first time I have heard of this. I'll check it out. What advantage would that give BitComet? Is there a particular situation that brings this behavior, or does BC do it all the time? What is "Cooperative" or "Gaming" about it?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 07, 2007 3:12 am 
Offline

Joined: Sat Jul 07, 2007 2:57 am
Posts: 3
Mr Hoffman,

I personally welcome you to visit forums(dot)bitcomet(dot)com to discuss issues related to this.

I think if you take the time to get to know our staff and members, your opinion of our client and its users will change. I was offended at some of your statements regarding bitcomets users, and I'm sure you know we do get alot of "noobs" who don't understand the principals of uploading and ratios, but thats my job to help them regarding this.

I can however tell you that on the torrents I've tested, bitcomet peers are among the best uploaders (testing with utorrent and bitcomet clients).

I have also stated in our forum that I first heard about your claim of problems between our client and your superseeding in the "torrentfreak" forum. At that time, I brought it to the attention of our developers, who to my surprise had not heard from you about it.


So, if you are interested in working together, I will bring any facts you can offer to the attention of our developers, and I will make sure you are treated with respect in my forum.


The UnUsual Suspect (admin forums bitcomet com)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 08, 2007 2:45 pm 
Offline

Joined: Tue May 01, 2007 12:38 pm
Posts: 8
funchords wrote:
Quote:
(3) This still doesn't explain the cooperative gaming, where peers will connect, download pieces, disconnect and then reconnect with fewer haves on their list.
This is the first time I have heard of this. I'll check it out. What advantage would that give BitComet? Is there a particular situation that brings this behavior, or does BC do it all the time? What is "Cooperative" or "Gaming" about it?


Today, I watched a super-seeding swarm for 30 minutes, and tracked the activity of 7 different BitComet clients. Four were BC070 (BitComet 0.70), the remaining three were BC086, BC088, and BC090 (BitComet 0.90, the current version).

This swarm was a good test case because the Super-Seeder is seeding a 6 GB file with 3 KB/s of bandwidth, and nearly everyone was at 51.6% complete when I joined at 45% complete. It would be easy to spot someone who was reconnecting and underreporting their HAVEs in their BITFIELD as they would appear at something less than 51.6%. I was also a "poor" peer as I already had all the pieces that the BC clients had, so I had nothing to offer them (at the start of the test). Later, I would accumulate unique data and offer it to the BC clients, which would allow me to observe their behavior when my peer was more desired.

During the test, all seven dropped off (of their own volition) and reappeared at some point. The BC070 clients noticeably seemed to have a longer disconnect timeout than the later clients, as the BC086 and later clients dropped off faster and more frequently than the BC070 clients. Most times, they would reappear a minute or two later -- reporting the same HAVEs as before. At about 10 minutes into the test, I disconnected one of the BC070 clients. It did not reconnect to me at that IP. Shortly after that (at 15 minutes into my observations), I changed my IP address and reconnected to the swarm. Up to that point, I was tracking 5 clients, but on this reconnect, I was able to find 7. The seven included the previous five, and all seven continued to behave as noted before - all becoming disinterested in my poor peer and disconnecting at some point, only to reconnect between 1-3 minutes later. During my 30 minute test, I did gain a unique piece and all seven clients responded as INTERESTED (as expected), however when UNCHOKED, 5 out of 7 failed to make any request (which may be okay, if the peer had already full requests for that piece elsewhere). What was disturbing is that I always made requests of the BC070 peers, and all four of them were snubbed at different points during the period for failing to send the data requested (none of the BC086 or later peers were ever snubbed).

KEY CONCLUSIONS: During the entire period, across the two different IP addresses I presented, the seven clients disconnected a combined total of 16 times. None of the reconnects occurred immediately, only one occurred between 30-60 seconds later, the other 15 occurring more than 60 seconds later. None of the clients reconnected with fewer HAVEs in their BITFIELD than previously reported (they all behaved as expected).

ADDITIONAL NOTES: BC070 sometimes thinks it is okay to ignore a valid REQUEST. (However, this behavior no longer exists in the current version).


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours [ DST ]


Who is online

Users browsing this forum: Google [Bot] and 29 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group