From 2df09905f5540fee096d48a92cb0c42558498a12 Mon Sep 17 00:00:00 2001
From: erdgeist <>
Date: Fri, 2 Jan 2009 08:57:53 +0000
Subject: * opentracker now drops permissions in correct order and really
 chroots() if ran as root * lock passing between add_peer_to_torrent and
 return_peers_for_torrent is now avoided by providing a more general
 add_peer_to_torrent_and_return_peers function that can be used with NULL
 parameters to not return any peers (in sync case) * in order to keep a fast
 overview how many torrents opentracker maintains, every mutex_bucket_unlock
 operation expects an additional integer parameter that tells ot_mutex.c how
 many torrents have been added or removed. A function mutex_get_torrent_count
 has been introduced.

---
 ot_livesync.h | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

(limited to 'ot_livesync.h')

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 @@
                                ########
  ######## SCRAPE SYNC PROTOCOL ########
  ########
- 
-  Each tracker instance SHOULD broadcast a beacon once in every 5 minutes after
-  running at least 30 minutes:
+
+  Each tracker instance SHOULD broadcast a beacon every LIVESYNC_BEACON_INTERVAL
+  seconds after running at least LIVESYNC_FIRST_BEACON_DELAY seconds:
 
   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.
+  its torrent count plus a threshold, it inquires for a scrape. It must wait for at
+  least 2 * LIVESYNC_BEACON_INTERVAL seconds in order to inspect beacons from all
+  tracker instances and inquire only 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.
+  scrape sync is going on. It should reset its state to needs no inquiry. It should
+  be reenabled on the next beacon, if still needed.
 
   packet type SYNC_SCRAPE_INQUIRE
   [ 0x0008 0x04 id of tracker instance to inquire
@@ -64,16 +61,17 @@
 
   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
+  Each tracker instance that receives a SYNC_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.
+  tell packets, if it knows more. However to not interrupt a scrape tell, a tracker
+  should wait LIVESYNC_BEACON_INTERVAL after receiving a scrape tell.
 
 */
 
-- 
cgit v1.2.3