Meshes are not built through collusion, i.e., each person setting up a node does not do so knowing that others are as well.
Mesh nodes are able to broadcast the existence of services they run ("I run a microblog!")
Services can be activated on a node (implying that their presence will be announced) or deactivated (implying that their presence will not be announced)
Mesh nodes continually listen for announcements of services from neighboring mesh nodeds
Mesh nodes maintain directories of services running on neighboring mesh nodes
...except when a service is designed to automatically federate with others of a like type (i.e., announcements of content from one will automatically be incorporated into cached announcements on the node)
Clients neither broadcast nor listen for service announcements
Computers not running Byzantium
Included in Porteus Linux
Host can publish running services
Host can be informed of services running on other hosts
User does not have to specifically configure any of this
Host admins may have to configure this
Bindings for multiple languages are available
Protocol in a nutshell:
Ad-hoc DHS over IP multicast (18.104.22.168, port 5353/UDP)
Each node has a resource record for each service
Types documented in /usr/share/avahi/service-types on Windbringer. File is part of Avahi on all systems.
HAS NOTHING TO DO WITH dnsmasq!
Resolution is done by the host running an Avahi implementation - broadcast a resolution request to the multicast domain and listen for a response
Node needs to have its hostname set (machinename.local)
Ignores point-to-point links by default. Add "allow-point-to-point=yes" in avahi-daemon.conf
Do mesh interfaces have the POINTTOPOINT flag?
wide-area functionality seems relevant to a mesh.
deny-interfaces=eth0 in avahi-daemon.conf may be necessary to prevent mDNS traffic from going over gateways.
avahi-daemon implements service announcement and listening, and interfaces with Avahi-enabled client apps.
avahi-dnsconfd connects to avahi-daemon and keeps track of unicast DNSes detected.
Read manage for avahi-daemon.conf!
Will need an /etc/avahi/services/foo.service XML file for each service offered by a node.
Manpage avahi.service(5) documents all required XML tags.
Each mesh node will have a list of all mesh nodes it's heard from in recent memory. This can be used to build the directory of neighboring services.