Aseba HTTP Switch as mDNS broker

[davidjsherman]

As part of the convergence between switch, http bridge, hub, this issue tracks the possible role of Aseba HTTP Switch in sharing a global view of Aseba networks with HTTP clients.

Aseba HTTP Switch accepts connections on a known port, so is a logical place for Web clients to learn about the network. It is multi-client and allows nodes to be addressed by node id. By design (but not yet in practice) it may create several Aseba networks, or even singleton networks containing only one node. Furthermore, its API provides “network discovery” queries, that report on the known nodes.

Consequently, Aseba HTTP Switch could provide an mDNS brokering service, that informs Web clients of the available nodes and networks, whether or not the switch is the ultimate target. The JSON list returned by the /nodes endpoint could include a resolved Aseba target. The client would have the option of connecting directly to the node, or of associating the node to a network.

It is not clear to me how this should interact with auto connection #721.

[davidjsherman]

In https://github.com/aseba-community/aseba/issues/760#issuecomment-353132709 @davidjsherman said:

service discovery is properly the responsibility of the switch. I just remembered #721, which allows the switch to act as a broker.

In https://github.com/aseba-community/aseba/issues/760#issuecomment-353140751 @cor3ntin said:

shouldn't it be the other way around ? The switch should probably auto-connect to all local targets ( aka - on the same compuler ), and then have a setting to decide whether these targets should be exposed on the network ?

That's not what a switch does. It doesn't expose targets, it aggregates them into a single target. Since connection in Aseba is exclusive, once the target is aggregated, it can't be individually addressed using Aseba.