summaryrefslogtreecommitdiff
path: root/ot_livesync.h
blob: fe9d122e80f780d3491d952cbd305f77040f33b2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
/* This software was written by Dirk Engling <erdgeist@erdgeist.org>
 It is considered beerware. Prost. Skol. Cheers or whatever.

 $id$ */

#ifndef __OT_LIVESYNC_H__
#define __OT_LIVESYNC_H__

#include "io.h"
#include "trackerlogic.h"

/*
  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
  to that group, using a ttl of 1

  Format of all sync packets is straight forward, packet type determines
  which kind of packet this is:

    0x0000 0x04 id of tracker instance
    0x0004 0x04 packet type

                             ########
 ######## 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 )
  ]*

                               ########
 ######## 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

#define LIVESYNC_PORT 9696

void livesync_init();
void livesync_deinit();

/* Join multicast group for listening and create sending socket */
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 );

/* 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
   enough */
void livesync_ticker( );

/* Handle an incoming live sync packet */
void handle_livesync( const int64 sock );

#else

/* If no syncing is required, save calling code from #ifdef
   constructions */
#define livesync_deinit()
#define livesync_init()
#define livesync_ticker()
#define handle_livesync(a)

#endif

#endif