#5 Tuning of tracker update interval

[Andrew]

Sometimes it is useful to update tracker info more often than usual.

In some cases, especially when working behind NAT, after latest tracker update upload/download rates tend to zero and eventually stale until next tracker update and peers get. Manually enforced early tracker update helps in this case.

It should be easy to implement this option: just create new CLI key for corresponding internal variable, so, please ;-)).

[dholmes999]

Logged In: YES
user_id=1313842
Originator: NO

A one-shot manual update is already available on the operator menu (currently option 11) or via CTCS. A manual specification of the tracker interval won't be planned, as the interval given by the tracker needs to be respected in routine operation. You really should set up NAT mappings and make yourself connectable.

However, there is room to consider extra automatic tracker updates based on current conditions, along the lines of how the minimum peers setting is handled. This would allow the client to determine whether immediately contacting the tracker might improve its current situation and do so without user intervention.

[Andrew]

Logged In: YES
user_id=1813654
Originator: YES

> You really should set up NAT mappings and make yourself connectable.

This is impossible: I can't control NAT of my ISP. All NEW incoming inet packets are dropped, only RELATED and ESTABLISHED traffic is allowed.

> along the lines of how the minimum peers setting is handled.
Thanks, this helps.

But why tracker given interval should be respected? Just for civility (and -m >1 already brokes it) or are there some protocol implications?

[dholmes999]

Logged In: YES
user_id=1313842
Originator: NO

To clarify, what you are describing is packet filtering (a firewall), which could be used with or without NAT. While an ISP could use NAT I don't think it's very common, and these are two independent features.

The tracker admin can adjust the interval in order to manage the load on the tracker. While [if set properly] it won't break the tracker to take on one more peer or for a peer to contact it an extra time occasionally when necessary or appropriate, if many peers connect more frequently than specified it could cause a problem.

An occasional contact prior to the specified interval is not prohibited, but it is not something that should be disregarded continuously. Note that a client is supposed to contact the tracker upon download completion even if a full interval has not passed since the last contact; a contact is also specified when stopping. Note that even when this client contacts the tracker because it has too few peers (the "-m" trigger), it does so once--as an event--not continuously until more peers are obtained.

If it is causing a major problem for you, I might suggest some other actions as well. One may be to contact the tracker admin. Thirty minutes seems to be a somewhat common reasonable update interval; in my opinion if the interval is an hour or more then the admin needs to evaluate this and perhaps make some capacity improvements.

Another is to contact your ISP about options to control filtering, or a different service package, or to consider a different ISP that is more willing to work with its customers.

[Andrew]

Concerning NAT: perhaps I explained bad what I mean. My host is beyond NAT, no torrent-usable ports are mapped from gateway to my host, so it is impossible to init new connection with my host from the outside regardless of packet filtering state.

Thanks for explanation of torrent behavior, now I see that you do not want to overload tracker: this may lead to simple client-based ban.

Interesting, but with -m trigger if there are not enough peers available, ctorrent sometimes freezes for a while: ticker stops for some seconds, dozens of seconds or even minutes, but eventually continues to work (and download data), until next freeze...

Contacting the tracker admin will do a little help: I do not stick to fixed tracker, just use an occasional one which tracks torrent I want.

Concerning my ISP. It has only one extern IP and hundreds of clients, there is no enough IPv4 addresses for all interested in... And this is the root of all problems )).

Anyway, thanks for the help.