summaryrefslogtreecommitdiff
path: root/ot_livesync.h
diff options
context:
space:
mode:
authorerdgeist <>2008-12-10 14:19:37 +0000
committererdgeist <>2008-12-10 14:19:37 +0000
commit6d4845149c9c2f96d038ba41fcad6fedd378ae4c (patch)
tree21c102d014569e3c865532ef4a74618bc05ac914 /ot_livesync.h
parenta9ab9b0c0dbd5de29d1aef9927cca92ac522d4cb (diff)
Propose a scrape sync protocol.
Diffstat (limited to 'ot_livesync.h')
-rw-r--r--ot_livesync.h72
1 files changed, 56 insertions, 16 deletions
diff --git a/ot_livesync.h b/ot_livesync.h
index 153dbac..97fe803 100644
--- a/ot_livesync.h
+++ b/ot_livesync.h
@@ -10,32 +10,72 @@
10#include "trackerlogic.h" 10#include "trackerlogic.h"
11 11
12/* 12/*
13 Syncing is done as udp packets in the multicast domain 224.0.42.N port 9696 13 Syncing is done as udp packets in the multicast domain 224.0.42.5 port 9696
14 14
15 Each tracker should join the multicast group and send its live sync packets 15 Each tracker should join the multicast group and send its live sync packets
16 to that group, using a ttl of 1 16 to that group, using a ttl of 1
17 17
18 Format of a live sync packet is straight forward and depends on N: 18 Format of all sync packets is straight forward, packet type determines
19 which kind of packet this is:
19 20
20 For N == 23: (simple tracker2tracker sync)
21 0x0000 0x04 id of tracker instance 21 0x0000 0x04 id of tracker instance
22 [ 0x0004 0x14 info_hash 22 0x0004 0x04 packet type
23 0x0018 0x04 peer's ipv4 address 23
24 0x001c 0x02 peer's port 24 ########
25 0x0020 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 ) 25 ######## PEER SYNC PROTOCOL ########
26 ########
27
28 Each tracker instance accumulates announce requests until its buffer is
29 full or a timeout is reached. Then it broadcasts its live sync packer:
30
31 packet type SYNC_LIVE
32 [ 0x0008 0x14 info_hash
33 0x001c 0x04 peer's ipv4 address
34 0x0020 0x02 peer's port
35 0x0024 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 )
26 ]* 36 ]*
27 37
28 For N == 24: (aggregator syncs) 38 ########
29 0x0000 0x04 id of tracker instance 39 ######## SCRAPE SYNC PROTOCOL ########
30 [ 0x0004 0x14 info_hash 40 ########
31 0x0018 0x01 number of peers 41
32 [ 0x0019 0x04 peer's ipv4 address 42 Each tracker instance SHOULD broadcast a beacon once in every 5 minutes after
33 0x001a 0x02 peer's port 43 running at least 30 minutes:
34 0x0021 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 ) 44
35 ]+ 45 packet type SYNC_SCRAPE_BEACON
46 [ 0x0008 0x08 amount of torrents served
47 ]
48
49 If a tracker instance receives a beacon from another instance that has more than
50 twice its torrent count, it asks for a scrape. It must wait for at least 5 + 1
51 minutes in order to inspect beacons from all tracker instances and chose the one
52 with most torrents.
53
54 If it sees a SYNC_SCRAPE_TELL within that time frame, it's likely, that another
55 scrape sync is going on. So one tracker instance MUST NOT react to beacons within
56 5 minutes of last seeing a SYNC_SCRAPE_TELL packet. After a scrape sync all
57 tracker instances have updated their torrents, so an instance in a "want inquire"
58 state should wait for the next round of beacons to chose the tracker with most
59 data again.
60
61 packet type SYNC_SCRAPE_INQUIRE
62 [ 0x0008 0x04 id of tracker instance to inquire
63 ]
64
65 The inquired tracker instance answers with as many scrape tell packets it needs
66 to deliver stats about all its torrents
67
68 packet type SYNC_SCRAPE_TELL
69 [ 0x0008 0x14 info_hash
70 0x001c 0x04 base offset (i.e. when was it last announced, in minutes)
71 0x0020 0x08 downloaded count
36 ]* 72 ]*
37 73
38 */ 74 Each tracker instance that receives a scrape tell, looks up each torrent and
75 compares downloaded count with its own counter. It can send out its own scrape
76 tell packets, if it knows more.
77
78*/
39 79
40#ifdef WANT_SYNC_LIVE 80#ifdef WANT_SYNC_LIVE
41 81