That DS flag

[Mitko]

This is really killing my speed ... whenever a local leecher comes up i start dling and after 10-20secs DS comes up.

[chaosblade]

Funny, I get snubbed almost immidietly with fake bitcomet clients.

[Animorc]

Same for me. I instantly get the flags UDS on the Fake Bitcomet peers. Even in swarms with 50% Fake Bitcomets.

[1c3d0g]

Yeah, I concur with that, I'm always getting snubbed by these fake scumbag leechers. If I could invent a device that could bitch-slap someone on the other end of the screen, I'd be a damn Billionaire by now... :/

[gilmoregirls]

Shouldn't it be possible to implement a function that bans clients you don't want to communicate with?

[daT]

These DS issues are still present and as yet, simply saying what they mean isn't enough.

For me this issue is still present, and ocurring more and more upon initially starting a torrent. It matters not what client the others are using... DS comes up within 200kb of the file being starting.

For the number of people this is happening too, clearly something is amiss.

[TheBear]

When dealing with clients that constantly send the DS flag (i.e. don't share actual data), one should consider the following.

BitComet, like many clients, allows a user to only download a single file in a multi-file torrent. There is no problem with that as many people do not wish to get .txt files, .nfo files and sample .avi's. However, it is claimed that BitComet will report itself as a seed for that torrent after only downloading those parts, even though it hasn't completed all the download.

If this is true, and my experiments have lead me to believe it to be, then it is possible that you are trying to download a part of the "share" that a BitComet user doesn't have.

Would it not be possible for someone who is trying to screw up P2P filesharing to use this technique and client to interfere with filesharing?

After all, your client is wasting time trying to get data from clients that don't have the data to share but claim that they do.

There are also said to exist hacks that are available for BitComet that allow it to identify itself as Azureus and µTorrent.

I've noticed that whenever I manually ban the IP address of any "completed" client which constantly displays the DS flag, my download speeds from the whole swarm increases, sometimes by two or three times.

[Firon]

well, the one thing I have to say here is that clients don't send the S flag (and it's S, not DS, D is downloading and unchoked). IT'S A LOCAL FLAG

It's D because you requested data from a peer, and the peer's client said "ok, I'll send you that data." Then, they don't, or send it too slowly, WITHOUT sending a choke message (common with BitComet), so your client snubs them and cuts off uploads to them.

[daT]

Well, as I said, this involves all clients, and, as I don't use public trackers, I don't see any versions of BC any longer either.

Let me say this, this occurs with users that have 100% of the torrent.

Again, let me say this, simply saying that D is for this, and S is for that does not speak to resolving what appears to be, a common and growing issue.

I'd thought I was perfectly clear on that each time I've posted here.

You have a number of users migrating to µtorrent, and its issues (all clients have - issues) are going to be more pronounced as the user base grows.

Right now, for µt, one main issue is the seeminly endless DS flags.

Now, can someone, anyone... speak to resolving the issue rather than simply posting what the flags mean?

[TheBear]

well, the one thing I have to say here is that clients don't send the S flag (and it's S, not DS, D is downloading and unchoked). IT'S A LOCAL FLAG

It's D because you requested data from a peer, and the peer's client said "ok, I'll send you that data." Then, they don't, or send it too slowly, WITHOUT sending a choke message (common with BitComet), so your client snubs them and cuts off uploads to them.

Thanks for clearing that up but as I noted in my comment, this is happening with "seeds" which would not get any uploads, only requests for data.

You have highlighted yet another way the BC doesn't comply to (what I understand to be) a BT specification though.

[TheBear]

Well, as I said, this involves all clients, and, as I don't use public trackers, I don't see any versions of BC any longer either.

Let me say this, this occurs with users that have 100% of the torrent.

Again, let me say this, simply saying that D is for this, and S is for that does not speak to resolving what appears to be, a common and growing issue.

I'd thought I was perfectly clear on that each time I've posted here.

You have a number of users migrating to µtorrent, and its issues (all clients have - issues) are going to be more pronounced as the user base grows.

Right now, for µt, one main issue is the seeminly endless DS flags.

Now, can someone, anyone... speak to resolving the issue rather than simply posting what the flags mean?

Have you changed any of the "Advanced Settings" options available at the bottom of the "Settings" page?

On one forum I use, we had a spate of users changing those settings willy-nilly and without understanding what they were really doing in an attempt to "get more download speed".

They didn't recognize that the often smaller user base of some private trackers required a rethink from the default settings for larger swarms.

So even if you haven't changed anything, others mucking around might be causing some of these problems as could the mental-midgets that would use a hack or plugin to spoof other clients too.

[daT]

Thanks...

Here's the options then...

Torrent - Global Max = 300

Max conected peers per torrent = 75

Upload slots per torrent = 10

Queue Settings - Max number of active = 50

Max number of active downloads = 50

(Note, I don't approach that, just keep it so)

Enable scraping

Advanced options...

and

[TheBear]

Thanks...

Here's the options then...

Torrent - Global Max = 300

Max conected peers per torrent = 75

Upload slots per torrent = 10

Queue Settings - Max number of active = 50

Max number of active downloads = 50

(Note, I don't approach that, just keep it so)

Enable scraping

Advanced options...

http://www.netservsolutions.net/files/pics/1.png

and

http://www.netservsolutions.net/files/pics/2.png

First start by changing peer.disconnect_inactive to false.

Restart µTorrent and try that for a bit, you should seem some improvement.

If no (or not enough) improvement, change peer.lazy_bitfield to true and again re-start the client.

Let me know what happens and if you can, run a speed test on your internet connection so that I can consider other possible changes.

[daT]

Done, will let you know how it works out.

Line is 6mb/800 btw.

[Switeck]

Torrent - Global Max = 300

Max conected peers per torrent = 75

Upload slots per torrent = 10

Queue Settings - Max number of active = 50

Max number of active downloads = 50

(Note, I don't approach that, just keep it so)

A possible problem is your upload speed PER upload slot (meaning upload speed PER person) falls below the critical threshold of about 3-5 KB/sec due to having 10 uploads PER torrent and running multiple torrents at once. Below that critical threshold, those you're uploading to decide you're uploading 'too slowly' and seek to share their upload bandwidth with faster links.

800 kilobit/sec upload speed works out to be only about 80 KB/sec useable upload in µTorrent, so with just 3 torrents running at once the average upload speed per upload slot would be 2.7 KB/sec at best.

Another even more likely possibility is packet loss, for whatever the reason. Your end is not receiving critical data packets, and is snubbing other BT clients because of it. ...or in BitComet's case because it says it will send something it never does.

BitComet also likes to disconnect and reconnect automatically at intervals in an attempt to co-opt µTorrent's "reward new peers with at least 1 file chunk so they have something to share"...that might somehow be aggrevating this problem. Do you ever see Optimistic Unchoke (the "O" in flags) on some of these peers that later turn "DS"?

[Firon]

It can still happen with a seed, because they promised to send data to you, but didn't, or sent it far far too slowly (like less than 16kb a minute). Your client would snub them in that case and try to find the data from another peer.

[daT]

Ammended number of slots per torrent.

Your end is not receiving critical data packets, and is snubbing other BT clients because of it.

- I just started a torrent that has only seeds. Connection is immediate with all 3 seeds (good speeds), and within 60 seconds all are down to 0kb.

- This ocurrs even when I'm not uploading the torrent at all (only sees and I in swarm)

- No, don't see any O flags.

==============

It can still happen with a seed...

- again, not the issue... speeds are good.

===============

Another even more likely possibility is packet loss,

- Packet loss isn't an issue, as the area had gone under a rebuild couple of months ago. Overall connection is rock solid stable.

===============

This happens with Az, µt and any other client. It is not restricted. It happens only (from what I've seen) immediately after starting the torrent.

=============

I want to thank you for staying with me on this, its appreciated.

[daftasbrush]

If someone's downloading from you and you see the S flag it means that you requested data from the client and the client said "ok I'll send it" but never did. When that happens, your client will cancel any requests it made, and stop uploading to him (might take a short while I guess)

Well something's not working quite right then.....

I had a peer connected to me which hadn't sent me what it had promised.... Waited 6000+

but uT was still uploading to it fine.... ended up 192kb Down, 118Mb Up.

Stopping and restarting the torrent seemed to fix it.... the peer started sending data fine...

I didn't check the flags at the time (duh)... but either

uT hadn't snubbed that peer

or

It had snubbed it, but was still uploading to it.

Either way... something wasn't working quite right....

I'll keep an eye on it... see if I can see it again.

[Firon]

BitComet peers are bastards and drop ALL your requests if you request too much data from them.

The betas should work somewhat better now that they have a workaround for this.