-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
70 lines (64 loc) · 3.22 KB
/
TODO
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
v1.0 TODO
This is the list
v1.0 TODO
======================
The following is a list of features that need to be implemented for v1.0.
Patches are welcome :-)
Any comments, questions, patches, please email them to
[_] Decouple IP:PORT and host-key
: The default AVMON host-key is the concatenation of IP address, :,
: and PORT. AVMON can support arbitrary host keys unrelated to IP and
: PORT, and implementing this feature is important for many reasons --
: the two most important reasons are:
:
: (1) Distributed applications and P2P systems usually have their own
: way to identify hosts/processes -- e.g., FreePastry creates an ID
: based on SHA1; another system might prefer to use the public part of a
: cryptographic key-pair as host/process ID. AVMON should
: allow such systems to monitor and query hosts/processes using their
: own keys/ids.
: (2) Read the following TODO...
[_] Implement NAT traversal, using STUN and TURN protocols, and tunneling
to unNATed hosts.
: This is required to support monitors and targets that are behind
: NATs and want to be part of an Internet-wide AVMON deployment.
[_] Allow applications to install their own monitors.
: How to actually monitor and store the monitoring results are
: orthogonal issues to AVMON. Currently AVMON implements a default
: raw-availability monitor -- monitors send a single ping
: periodically, and the replies are stored on disk, thus allowing
: querying of historical availability. Applications might have
: particular monitoring needs, such as a one-hour window availability,
: aged availability, etc. AVMON must allow installation of different
: availability algorithms.
:
[X] Implement callback system in avmon.c
[_] Add support in listener.c for user defined availability-monitoring
messages.
[_] Add support in messages.c for user defined availability-monitoring
messages.
[_] Add support in avmon.c for user defined availability-monitoring
messages.
[_] Implement a default mechanism to answer queries about offline AVMON
nodes.
: To answer an availability query, the target node is contacted, and
: it then supplies its list of monitors. These monitors can be contacted
: afterwards to learn the measured availability of the target node.
: Currently, the application using AVMON needs to cache the list of
: monitors, if it wants to learn the historical availability of a
: target node that is offline at the moment. It would be nice to
: offload this responsibility from the application, and provide a
: default mechanism to learn the monitors of an offline target.
[_] Decide between the following approaches and implement one:
[_] Use a DHT to store monitor sets.
: Pros: fully distributed solution. Instant replies.
: Cons: lack of a robust DHT implemented in C language.
[_] Use a gossiping protocol to ask online nodes to discover the
monitors of a target node.
: This approach would take advantage of AVMON's shuffling
: mechanism that discovers monitor-target relations.
: Pros: fully distributed solution. Does not require an
: additional system.
: Cons: learning the set of monitors won't be as fast as with
: the DHT approach.