blob: e5e6d7dd649e730031a8600d72386380cfbc8e3f (
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
|
Services offered by users are to be discovered automatically and
offered to all users of the mesh. For vendor independence several
means of discovery and announcement are required. They are connected
by the unified information storage.
* Service information storage
Every mesh node holds a p2ptl (see overview.org) of all currently
available services. It is synchronized over the mesh interface.
It has the following columns (in-order):
* location (unique primary key) :: protocol-specific identifier
how to reach the resource (e.g. "1.2.3.4:22" for SSH,
"https://1.2.3.4/pron" for HTTP, "//lame/os" for SMB, ...)
* expiry time :: unix time after which the entry shall be deleted
* source :: how the service has been discovered: manual, portscan,
dnssd, ssdp
* class :: one of storage, internet, game, stream, search, ... to
be extended and refined
* description :: a human-readable (and typically human-written)
description of the service, e.g. "Toms pr0n archive"
Additional class-specific columns may follow that give
machine-readable information about the service:
** storage
* capacity :: no. of bytes or empty if unknown
* used_capacity :: no. of bytes or empty if unknown
* writable :: true|false
** internet
* external ip ::
* upstream :: no. of bytes/second or empty if unknown
* downstream :: no. of bytes/second or empty if unknown
** game
* active players :: no. of players or empty if unknown
** stream
none
** search
none
* Service discovery
** manual Webif entry
** Port scanning
** DNS-SD (Zeroconf)
** SSDP (UPNP)
* Service announcement
** Web interface
** DNS
Zeroconf uses the domain advertised via DHCP to lookup local
services via DNS in the same way it uses mDNS (see [[http://www.dns-sd.org/ServerStaticSetup.html][HowTo]]). Our
service database could thus be announced via DNS for these clients.
|
