Propose a scrape sync protocol.

dynamic-accesslists
erdgeist 16 years ago
parent a9ab9b0c0d
commit 6d4845149c

@ -10,31 +10,71 @@
#include "trackerlogic.h" #include "trackerlogic.h"
/* /*
Syncing is done as udp packets in the multicast domain 224.0.42.N port 9696 Syncing is done as udp packets in the multicast domain 224.0.42.5 port 9696
Each tracker should join the multicast group and send its live sync packets Each tracker should join the multicast group and send its live sync packets
to that group, using a ttl of 1 to that group, using a ttl of 1
Format of a live sync packet is straight forward and depends on N: Format of all sync packets is straight forward, packet type determines
which kind of packet this is:
For N == 23: (simple tracker2tracker sync)
0x0000 0x04 id of tracker instance 0x0000 0x04 id of tracker instance
[ 0x0004 0x14 info_hash 0x0004 0x04 packet type
0x0018 0x04 peer's ipv4 address
0x001c 0x02 peer's port ########
0x0020 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 ) ######## PEER SYNC PROTOCOL ########
########
Each tracker instance accumulates announce requests until its buffer is
full or a timeout is reached. Then it broadcasts its live sync packer:
packet type SYNC_LIVE
[ 0x0008 0x14 info_hash
0x001c 0x04 peer's ipv4 address
0x0020 0x02 peer's port
0x0024 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 )
]* ]*
For N == 24: (aggregator syncs) ########
0x0000 0x04 id of tracker instance ######## SCRAPE SYNC PROTOCOL ########
[ 0x0004 0x14 info_hash ########
0x0018 0x01 number of peers
[ 0x0019 0x04 peer's ipv4 address Each tracker instance SHOULD broadcast a beacon once in every 5 minutes after
0x001a 0x02 peer's port running at least 30 minutes:
0x0021 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 )
]+ packet type SYNC_SCRAPE_BEACON
[ 0x0008 0x08 amount of torrents served
]
If a tracker instance receives a beacon from another instance that has more than
twice its torrent count, it asks for a scrape. It must wait for at least 5 + 1
minutes in order to inspect beacons from all tracker instances and chose the one
with most torrents.
If it sees a SYNC_SCRAPE_TELL within that time frame, it's likely, that another
scrape sync is going on. So one tracker instance MUST NOT react to beacons within
5 minutes of last seeing a SYNC_SCRAPE_TELL packet. After a scrape sync all
tracker instances have updated their torrents, so an instance in a "want inquire"
state should wait for the next round of beacons to chose the tracker with most
data again.
packet type SYNC_SCRAPE_INQUIRE
[ 0x0008 0x04 id of tracker instance to inquire
]
The inquired tracker instance answers with as many scrape tell packets it needs
to deliver stats about all its torrents
packet type SYNC_SCRAPE_TELL
[ 0x0008 0x14 info_hash
0x001c 0x04 base offset (i.e. when was it last announced, in minutes)
0x0020 0x08 downloaded count
]* ]*
Each tracker instance that receives a scrape tell, looks up each torrent and
compares downloaded count with its own counter. It can send out its own scrape
tell packets, if it knows more.
*/ */
#ifdef WANT_SYNC_LIVE #ifdef WANT_SYNC_LIVE

Loading…
Cancel
Save