Pause torrents or exit uTorrent - any difference?

Whilst I was out a-pondering.........

A few questions for the wise and all-knowing.......

I'm wondering if any uTorrent connections are left more 'open' if you merely pause then unpause all activity, rather than exiting the application and restarting later (ie maybe there are some start-up procedures in uTorrent which necessitates torrent downloads/uploads having to 'warm up' each time the application is started.)

Also, what difference (if any) is there between pausing torrents and having the scheduler stop them?

I have noticed occasional up/download figures of 0.1 or 0.2 when all my torrents are on pause: is this some sort of 'drip feed' to keep the ports ready for higher-speed connections when torrents get un-paused, or is it merely a bit of data leakage somewhere?

I'd appreciate comments from the learned.

Connections are actually kept open when you pause. The 0.x bandwidth usage you see is from keeping the connections active.

The stopped mode in the scheduler STOPS the torrents rather than pauses them, closing all the connections.

I believe I may be seeing a few peers that are paused on the torrents I'm seeding...yet the weird thing is, they connect to me!

Why would uTorrent v1.7.7 be attempting new connections on a paused torrent?

They sit idle for 4+ hours straight sometimes.

Yet when I disconnect them, (using TCP view to break the TCP connection to their ip) they reconnect to me (as an incoming connection) often within 2 minutes.

They don't download anything from me...on one of the torrents I'm a true seed and the others I have any incomplete files in those torrents marked as "skip".

It doesn't make sense that they're skipping files in these multi-file torrents, because when I do that uTorrent v1.8r6 DOESN'T connect to seeds.

Are these "undead" peer connections possibly another of ComCast's tricks?

These aren't connections that should have timed out, as would be the case if my side failed to receive ComCast's infamous "kill the connection" RST packets. (I'm VERY familiar with those!)

The peer connections are "live" in the sense they send keep alive packets in a timely manner to avoid timeout death. But they don't DO anything.

So Switeck, a moderator no less, has experienced strange things as well. Is this a bug??

uTorrent will always accept connections. The clients most likely to send data to "paused" torrents are Transmission.

These were uTorrent v1.7.7 clients, or at least they say they are!

But I thought uTorrent would not be attempting to make new connections while paused AND would not stay connected to seeds while in seed-only mode ...or skipping undownloaded files.

Paused torrents were changed recently weren't they in 1.8 ... something about tracker communication. I don't know about NEW connections, but I remember once leaving a full 600 peers connected to me overnight one time I forgot to UN-pause ALL

Seed-only mode or not, once you're a seed, seed connections are broken. If the client is/staying connected it didn't send those last messages to your client. (whatever comes last... that FAST "complete" message or "HAVE all", I don't know how many messages there are).

As far as skipped content and then changing TO download, was that in your first explanation and I missed it? I just re-read it, and it only assumes something like that could keep these connections live in your case. If you're using 1.8 and it doesn't behave this way I would just assume you've got the benefit of not keeping connections with peers which have 0.0 Relevance to you.

Some of my multi-file torrents are 100% complete seeds, others contain skipped files.

I'm seeing peers doing nothing (even with the U flag sometimes!) on all of them.

Well, if you're PAUSED, I didn't think you had any U or D to do... it relies on the remote client wanting to send you data in the times I've experienced. I'm not sure why 100% peers would stay connected to you... but certainly in the event of a non-paused state, if you could capture some information (is this a transient behavior) via Wireshark I'd hope when available the people who look over network stuff like that would see if something funky is going on. Have you looked through any traffic during those times to see what messages are being passed? Or made a logfile with all the (more verbose and specific message) flags 1.8 provides?

I'm not having any 100% peers (seeds) remaining connected to ME. I'm seeing peers with anywhere from 0.3% to ~80% remain connected to me. But since they're uTorrent v1.7.7 and I haven't uploaded anything to them for hours...sometimes days...there's gotta be something wrong somewhere!

I know some people attempt to cheat on trackers that insist on a seeding time of (for example) 72 hours after completion of a .torrent by pausing there finished .torrent for 72 hours so the tracker will still see them as seeding and then they don't have to worry about auto hit and run detection from being triggered.A lot of trackers are now aware of this and the staff have to look out for it and deal with it by way of P/M and warnings to potential cheaters.

Version 1.8 sends a stop event if a torrent is still paused on the third announce interval.

Switeck knows his stuff, so I wouldn't ask something silly like check the Advanced screen... perhap checking the Queued or Waited columns in the Peers tab would show whatever action is not making them "time out".. personally I don't use disconnect_inactive because I have 20 peers per torrent... but I've heard those two columns specifically mentioned as the reason(s) disconnects happen, or don't. Maybe that helps.

Version 1.8 sends a stop event if a torrent is still paused on the third announce interval.

...Won't do me any good immediately. I'm not the one that's paused. I'm often running with half open limit in uTorrent set to 0. I'm not even sure if the ones I'm seeing are paused or just using skip files or running in seed-only mode.

Most of the clients I'm seeing doing this are BitTorrent v6 something, uTorrent v1.7.7, or various others (BitComet, Azureus).

It's only the uTorrent v1.7.7 ones that I don't understand why they're doing it because I thought it had smarter behavior while paused.

I only brought it up because of scruffs comment.

Ok, I got a screenshot of 3 "pasued" rascals at once:

http://rapidshare.com/files/135101108/uTorrent_v1-8_Inactive_Peers.png

I tried to cram quite a bit of extra details on the screenshot...such as my speed graph, complete with the dip about 9 hours ago when ComCast managed to kill off almost all my connections. I was probably down to 2 or 3 connections at that moment. Even right now, I should have 2-20 more connections than I do, but ComCast is killing them off too quickly.

ComCast seems to be allowing a couple connections at once, or they'd probably have little trouble killing every connection I have. The paused peers are counting against that limit.

The bottom three appear to simply not be broadcasting any pieces.. if you have disconnect_inactive TRUE though it shouldn't keep them connected :/

If it's a reproducible thing you should try to limit the network traffic by only running one torrent and then identify likely peers to filter while keeping Wireshark output.... And then get someone who knows about the protocol to figure out the messages whether it's exploiting something (i.e. fake Bittorrent/DNA peers)

peer.disconnect_inactive *IS* TRUE.

peer.disconnect_inactive_interval is set to 300 seconds.

However my max connections per torrent (60) has not been reached, so even inactive peers aren't disconnected.

Just fyi, the global connection cap is also taken into account. So idle peers will also be dropped if you hit the global cap before the individual cap.

Not a problem...I'm on ComCast. I don't hit my global cap of 90 while seeding...EVER!

Paused peers or no, SOMETHING seems seriously amiss!

Here's my latest example, with 'bad' peers outnumbering good ones on this torrent 5 to 2:

http://rapidshare.com/files/135531299/uTorrent_v1-8_Inactive_Peers_10.png

...It's not time to call ComCast yet, as I still am not sure exactly what's going on here!

...Ok, I've called ComCast. But not concerning this, instead just the disruptions in general now that the FCC has made a statement about it. I am getting disrupted so badly now, that it is VERY hard to seed. The technician on the phone denied ComCast was disrupting my connections. No help there.

what lots of people do, even on single file torrents as well as multi file torrents, to build their ratio is

start a torrent file and as soon as some of the parts go green and start to download they select all files in the

files field on the bottom screen and select "Don't Download"

The torrent will continue to download 'till the parts that had turned green are completed, but not necessarily complete any downloads.

This stops their client from connecting fully to any seeds but still uploads the completed parts to other people

in the swarm. The tracker will still see these peers as leechers

Therefor using this theory (which happens commonly) users could have any amount completed, not be paused

and still connect to peers in the swarm but not accept any parts from your client and they will just upload

the parts they have although they are not finished.

I have uploaded 3 pictures of how you can use uTorrent to seed data to a swarm without having to download much at all.

This is the perfect way to build a good ratio when you join a new site

I think this is what you were getting at from the other peers point of view

Click Here To See Full Sized Picture Of Utorrent Screenshots

Click Here To See Full Sized Picture Of Utorrent Screenshots

Click Here To See Full Sized Picture Of Utorrent Screenshots

Click Here To See Full Sized Picture Of Utorrent Screenshots

all the best scruff

In my case, these were public torrents on public trackers that don't care about ratio.

uTorrent simply is unable to tell those "peers" are in seed-only mode, and since I am too...they stay connected indefinitely.