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.