Stack Proposal Review

General Details

Date: 12th October in irc [irc.oftc.net,#ros][4pm EST, 2pm San Frans time]

Proposer: Daniel Stonier

Present at the Review:

• Daniel Stonier (Yujin)
• Bill (ihr)

Interested Parties:

• Jack O'Quin
• Ken Conley

This review is to establish the direction and API for the zeroconf_implementations stack via common consensus from interested parties in the ros community.

The zeroconf_avahi and zeroconf_avahi_demos present a fairly complete, working example of the avahi implementation on linux. This is the currently planned direction for the zeroconf implementations.

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Topics:

• Implementations in both c++ and python for avahi [Daniel Stonier]

• Review of the ros api in zeroconf_comms [Daniel Stonier]

• Review of the ros avahi implementations (importantly, refer to the zeroconf_avahi dev notes about this)

• A ros based parallel of /usr/share/avahi/service-types? [Daniel Stonier]

• How do we want to handle network topology discovery here (i.e. up/downs of wireless connections)? [Daniel Stonier]

• Wide area domains? [Daniel Stonier]

Actions:

• Establish a roadmap [Daniel Stonier]

kwc

My high-level comment is that we need to establish use cases as there are chicken-and-egg problems in some of those cases. The current zeroconf stack layers on top of a running ROS system and uses ROS, which means that ROS itself cannot use zeroconf -- but this approach means you get some nice ROS APIs to manipulate zeroconf in a generic way.

I actually took care to separate it into two components to handle such use cases. zeroconf_avahi is currently a c++ library and a ros node. The c++ lib has scattered ROS_xxx's scattered around since I was debugging, but they'll come out, leaving it as a pure c++ library. If ros itself decides it wants to do zeroconf internally, its just a matter of moving the library itself to wherever it needs to be. [Daniel Stonier]

Meeting agenda

• lib and node separation

• ros api in zeroconf_comms

• zeroconf_avahi
• zeroconf_python_avahi

• A ros based parallel of /usr/share/avahi/service-types?

• How do we want to handle network topology discovery here
• We should submit an official service to avahi?
• android jmdns

Conclusion

Immediate:

• Submit an official service to avahi (_ros_master._tcp and _ros_master._udp).

• zeroconf_avahi -> clean separation of c++ lib and ros node

• zeroconf_avahi -> feasibility for api to remove_listener

• zeroconf_python_avahi -> start off with a simple non-ros python module

• android_jmdns -> pure library for now (no ros api as we're not running full systems yet)

• a suite of tutorials for common use cases

Later:

• c++/python robot/topics discovery utility (for use in programs similar to rind)

• handling what happens when robots go out of range and leave zeroconf ghosts

The last one needs some testing to see just how avahi behaves. It is also perhaps a bit non-trivial as to when and how we should remove a ghost service.

• If a keepalive is used, have to be careful it doesn't flood the network.
• Better error handling for the user when an ip doesn't get resolved.
• Handle it inside the zeroconf node or outside (in a node doing wireless monitoring like that getting talked about in multimaster)

---