diff options
Diffstat (limited to 'ot_livesync.h')
| -rw-r--r-- | ot_livesync.h | 26 |
1 files changed, 12 insertions, 14 deletions
diff --git a/ot_livesync.h b/ot_livesync.h index 97fe803..ae9ab55 100644 --- a/ot_livesync.h +++ b/ot_livesync.h | |||
| @@ -38,25 +38,22 @@ | |||
| 38 | ######## | 38 | ######## |
| 39 | ######## SCRAPE SYNC PROTOCOL ######## | 39 | ######## SCRAPE SYNC PROTOCOL ######## |
| 40 | ######## | 40 | ######## |
| 41 | 41 | ||
| 42 | Each tracker instance SHOULD broadcast a beacon once in every 5 minutes after | 42 | Each tracker instance SHOULD broadcast a beacon every LIVESYNC_BEACON_INTERVAL |
| 43 | running at least 30 minutes: | 43 | seconds after running at least LIVESYNC_FIRST_BEACON_DELAY seconds: |
| 44 | 44 | ||
| 45 | packet type SYNC_SCRAPE_BEACON | 45 | packet type SYNC_SCRAPE_BEACON |
| 46 | [ 0x0008 0x08 amount of torrents served | 46 | [ 0x0008 0x08 amount of torrents served |
| 47 | ] | 47 | ] |
| 48 | 48 | ||
| 49 | If a tracker instance receives a beacon from another instance that has more than | 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 | 50 | its torrent count plus a threshold, it inquires for a scrape. It must wait for at |
| 51 | minutes in order to inspect beacons from all tracker instances and chose the one | 51 | least 2 * LIVESYNC_BEACON_INTERVAL seconds in order to inspect beacons from all |
| 52 | with most torrents. | 52 | tracker instances and inquire only the one with most torrents. |
| 53 | 53 | ||
| 54 | If it sees a SYNC_SCRAPE_TELL within that time frame, it's likely, that another | 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 | 55 | scrape sync is going on. It should reset its state to needs no inquiry. It should |
| 56 | 5 minutes of last seeing a SYNC_SCRAPE_TELL packet. After a scrape sync all | 56 | be reenabled on the next beacon, if still needed. |
| 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 | 57 | ||
| 61 | packet type SYNC_SCRAPE_INQUIRE | 58 | packet type SYNC_SCRAPE_INQUIRE |
| 62 | [ 0x0008 0x04 id of tracker instance to inquire | 59 | [ 0x0008 0x04 id of tracker instance to inquire |
| @@ -64,16 +61,17 @@ | |||
| 64 | 61 | ||
| 65 | The inquired tracker instance answers with as many scrape tell packets it needs | 62 | The inquired tracker instance answers with as many scrape tell packets it needs |
| 66 | to deliver stats about all its torrents | 63 | to deliver stats about all its torrents |
| 67 | 64 | ||
| 68 | packet type SYNC_SCRAPE_TELL | 65 | packet type SYNC_SCRAPE_TELL |
| 69 | [ 0x0008 0x14 info_hash | 66 | [ 0x0008 0x14 info_hash |
| 70 | 0x001c 0x04 base offset (i.e. when was it last announced, in minutes) | 67 | 0x001c 0x04 base offset (i.e. when was it last announced, in minutes) |
| 71 | 0x0020 0x08 downloaded count | 68 | 0x0020 0x08 downloaded count |
| 72 | ]* | 69 | ]* |
| 73 | 70 | ||
| 74 | Each tracker instance that receives a scrape tell, looks up each torrent and | 71 | Each tracker instance that receives a SYNC_SCRAPE_TELL, looks up each torrent and |
| 75 | compares downloaded count with its own counter. It can send out its own scrape | 72 | compares downloaded count with its own counter. It can send out its own scrape |
| 76 | tell packets, if it knows more. | 73 | tell packets, if it knows more. However to not interrupt a scrape tell, a tracker |
| 74 | should wait LIVESYNC_BEACON_INTERVAL after receiving a scrape tell. | ||
| 77 | 75 | ||
| 78 | */ | 76 | */ |
| 79 | 77 | ||