57 lines
No EOL
4 KiB
Text
57 lines
No EOL
4 KiB
Text
The purpose of retracker is to be tracker and an announce proxy at the same time.
|
|
|
|
retracker shall expose it's internal tracker cache as standalone tracker,
|
|
implementing HTTP and UDP announces. Available for non-proxied peers, serving as regular tracker.
|
|
|
|
Then, server another HTTP and UDP endpoints as announce proxy. Local peer requesting announce
|
|
to proxied tracker shall be matched by announce URL and tracker key (if there is), or another identifier
|
|
like peer_id. Proxy endpoint is available only for requests that match forementioned tracker key.
|
|
When request is made to proxy endpoint and it matches key - re-announce to destination trackers should be made and
|
|
on successful peer list retrieval - local tracker cache updated. If not, peers from cache should be returned.
|
|
|
|
On re-announce to destination trackers, proxied peer's real IP must be injected into announce request and
|
|
other parameters should remain same as in original request.
|
|
|
|
Whether retracker exposes its cache as tracker or not, the local tracker data shall be present all time.
|
|
When there is need to expose local tracker a tracker endpoint should be declare in config. Tracker endpoint
|
|
is HTTP or UDP server responsing to BitTorrent announces just like if it was any other regular torrent tracker.
|
|
|
|
|
|
Announce request coming from local peer contains local (peer) data: ID, uploaded, downloaded, and so on.
|
|
Announce response contains peer set.
|
|
|
|
Proposal 2 to retracker scheme:
|
|
Local peers will announce to tracker of retracker. Retracker job will find peer that are eligible for re-announce,
|
|
and announce them to destination trackers, with all local data like downloaded/uploaded, BUT IPs rewritten
|
|
with rules, that will be specified in config to translate proxied peer's IP.
|
|
Apart from re-announces, tracker will act like regulat BitTorrent tracker: serving peer lists and keeping track
|
|
of torrents.
|
|
|
|
Local peers and destination tracker's peers conflict:
|
|
When local peer 69.69.69.69:1337 announces to local tracker (aka retracker), he is recorded into peer set of local tracker.
|
|
Then, if being matched by specific properties, being re-announced to destination tracker; designation of re-announce is to gather
|
|
peer list from destination tracker and, of course, announce about local peer (with re-written, proxied IP).
|
|
This creates situation, when re-announce job updates his cache, which is local tracker, and puts 69.69.69.69:1337
|
|
into peer list, overwriting local peer record, which is IMPORTANT because it holds local data.
|
|
To avoid this conflict, a Set must be used guaranteeing unique list of peers, on conflicting peers - always PREFER LOCAL record.
|
|
|
|
Local tracker cache and destination tracker peers:
|
|
On each re-announce job retracker shall add peers to its local tracker, but what to do if peer is not present in returned
|
|
destination tracker's announce response? If we flush all peers and override them with destination tracker peer list,
|
|
this would delete peers that are local announced. Therefore, a grace period should be added to each REMOTE peer, and vanish only
|
|
after absence in N announce responses from destination tracker.
|
|
If we don't flush peer list - it will indefinitely grow bigger and bigger.
|
|
|
|
Server architecture 1:
|
|
Tracker class has synchronized methods for access by running threads. Also Tracker has list of running threads, that are either
|
|
TrackerServer or TrackerJob. Tracker is responsible for starting and stopping them.
|
|
|
|
Server architecture 2:
|
|
There is some other entity like Application class that handles running threads, making Tracker responsible for only one thing
|
|
and that thing is tracking peers of torrents. This is preferred design choice since we can then export tracking and scraping
|
|
functionality in separate interfaces, since UDP announce protocol has scrape method, whilst HTTP doesn't. As for now, current Tracker
|
|
class implementation doesn't provide any other information for Torrent besides its InfoHash and PeerSet, which is built from local announces
|
|
and announces to destination trackers.
|
|
|
|
Maven exec with args:
|
|
mvn exec:java -Dexec.args='' |