** struct ot_workstruct gets ritcher (and will become even ritcher soon).

This is where we encapsulate all per-request data from peer to hash to peer_id, so that it is
available everywhere without passing hundreds of pointers down the stack. Most functions that
do work down the stack now accept an ot_workstruct and some flags. So it can end up in the
stats/event-handler where it will be the default parameter in the future.

** peer_id is now being copied by default and moved to ot_workstruct
So it is available in stats and subsequent functions.

** sync scrape madness is gone
SYNC_SCRAPE was intended to sync tracker state that would normally be lost on restarts i.e.
downloaded counts per torrent. The way was to push it in the tracker cloud after finding all
neighbouring trackers.
This is madness. It never was tested and can be done per tracker by fetching
stats/mode=statedump from time to time and starting opentracker with the -l option later.

** livesync thread has its own ot_workstruct now
So it can behave like ot_udp and ot_http against trackerlogic.c and get rid of the first half
of the embarrassing global variables. The sending half will be fixed soon [tm].

** stats can log completed events
The author recognizes the needs of original content distributors to keep track of the amount
of times a work has been downloaded. While not feasible and used on openbittorrent and other
open and anonymous tracker installations, a tracker user can now choose to send those events
to syslog.

1 files changed, 1 insertions, 39 deletions

diff --git a/ot_livesync.h b/ot_livesync.h
index fe9d122..1a3ed45 100644
--- a/ot_livesync.h
+++ b/ot_livesync.h
@@ -35,44 +35,6 @@
     0x0024 0x02 peer flags v1 ( SEEDING = 0x80, COMPLETE = 0x40, STOPPED = 0x20 )
   ]*
 
-                               ########
- ######## SCRAPE SYNC PROTOCOL ########
- ########
-
-  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
-  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. 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
-  ]
-
-  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 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. However to not interrupt a scrape tell, a tracker
-  should wait LIVESYNC_BEACON_INTERVAL after receiving a scrape tell.
-
 */
 
 #ifdef WANT_SYNC_LIVE
@@ -86,7 +48,7 @@ void livesync_deinit();
 void livesync_bind_mcast( char *ip, uint16_t port );
 
 /* Inform live sync about whats going on. */
-void livesync_tell( ot_hash const info_hash, const ot_peer * const peer );
+void livesync_tell( struct ot_workstruct *ws );
 
 /* Tickle the live sync module from time to time, so no events get
    stuck when there's not enough traffic to fill udp packets fast