Gluon: Services Discovery in the Mesh Network

[rubo77]

it would be cool to have a clickable list of all content in the mesh, visible in the status page of each node.

The node could for example scan on port 80 and 443 and cache all IP addressed that offer HTML pages. This would make the "hidden web" in the Freifunk mesh visible.

The same on some other frequently used services

[jplitza]

Actively scanning the mesh is totally out of the question. In your specific proposition, scanning would even require unicast probes to all IP addresses and couldn't be done with multicast.

Yes, the services could be more visible. But this should rather happen via respondd or Bonjour announces by the servers. Accumulating them on the status page might be a good idea, but only after _passively_ collecting them.

[rubo77]

Sure a Cronjob scanning the whole net all the time is out of question.

why not actively collecting them once, when you visit the status page the first time, and then cache the result?

[waschmi]

I feel like there is a need of some publishing system for mesh networks. Right now I have no Idea what services are available in Freifunk. Well, someone might have made a wiki page and if it exists it's also most likely outdated and/or incomplete (I assume).

To have some kind of snapshot/ live Index of available services, a telephone book might be nice. It must be very easy for "publishers" to announce their services to the network or nobodly will do it or have someone do it for a price. Of course that Index must have a decentral design to prevent a single (domain) registry authority.

Personaly I'd like to have a gluon mesh node + server + content management software I can run on my laptop. It should have a map to see all mesh nodes and give the option to configure (ssh + gui?) those I own. It should show the status of my server/ services connected to the mesh net and should should show the service type I make avaible. It really shouldn't be another in Browser something, those are anoying.

I have to say I know nothing about respondd or Bonjour (at least there isn't much about it in readthedocs), sorry if I said something unnecessary.

[peki75]

Huhu,

für sowas wurde doch Alfred entwickelt. Man-Page:

https://downloads.open-mesh.org/batman/manpages/alfred.8.html

Ein Service macht gegenüber einem Alfred-Master seine {IP:Port, Name, Beschreibung} bekannt. Und dann kann man im gesamten Mesh diese Information unter dem entsprechenden Alfred Data-Type abfragen.

Keine Ahnung, ob so ein "Anmeldeservice" irgendwo existiert. Aber vom Prinzip her ist es genau der Use-Case von Alfred.

Grüße
Micha

[rubo77]

Leider ist alfred iin grösseren Communities (300+ clients) schon so stark ausgelastet, dass die grundinfos die rumgesendet werden oft schon nicht mehr in ein UDP-Paket passen und dadurch Daten verloren gehen.

Deshalb wollen wir ja Alfred ablösen durch einen zuverlässigeren Service.

[NeoRaider]

alfred doesn't really work very well for this usecase. Bonjour (called avahi on Linux) is pretty much the right tool for this job, but it causes too much traffic in batman-adv networks.

Let's get rid of batman-adv first before adding more services which cause additional traffic. I think there's something like a avahi proxy for OLSR, which might be a good starting point to develop avahi support for a Gluon-based Layer 3 mesh.

[Moorviper]

i did some test with bonjour to announce the codename
but it it uses to much CPU :-/

@fulda we managed it via the alias.json
and modded the meshviewer
http://picpaste.com/pics/Bildschirmfoto_2016-02-22_um_21.28.36-V2KChUDQ.1456172999.png

With the node filter you then can search .fffd and you get all the announced services ;-)

but it is not online (official) ;-)

[rubo77]

@Moorviper: your image is gone. is it online somewhere already by now?

I also created a packet, to share media via usb-automount and if we could find a consense, how to announce such services, I would add this to the config mode menu there

[MoritzFago]

Currently the IETF is working on a draft that aims to reduce the amount of traffic for multicast-dns. The rough idea is, that the mobile devices offer their service to the area around them, and the next router filters their packets and adds their offer to its own dns-sd server. Ohybridproxy is a early implementation, maybe it could be integraded?