Give the total number of subscribers when a publisher advertises

[blaroche]

This is an enhancement issue based on the discussions about this question: http://answers.ros.org/question/11167/how-do-i-publish-exactly-one-message

The problem that my colleague and I experienced is that the first (few) messages published were "lost". In our case, we wanted to publish exactly one message and not more. The problem with ROS is that the publisher starts sending its messages as soon as it exists, without waiting for the subscribers to establish a connection. This is acceptable in some cases, but not in many others.

Here is my suggestion:

Calling NodeHandle::advertise eventually gets to line 403 of topic_manager.cpp: master::execute("registerPublisher", args, result, payload, true); Currently, the variable result is ignored, but it should contain the total number of subscribers for the given topic. I would also add an optional parameter in advertise() that would be a duration. Then, we a publisher would be created, it would wait for the subscribers to connect, up to the given duration. Any call to Publisher::publish before that would queue the message.

This solution is not fail-proof, but at least with a timeout option, it would increase the reliability when required and still allow not to wait (or not to wait too long) for other cases (by giving zero as a timeout duration).

[ahendrix]

Interesting. If a new publisher is notified of the number of subscribers that are registered with the master when it starts, the advertise call could block until all subscribers have connected.

If we don't see connections from all of the subscribers we expect within a given timeout, it's probably a sign that there's something wrong with the system, either a network configuration problem or a ROS client that isn't behaving properly. We could then give the user an early notification that there's something wrong with their system, rather than letting it fail silently later on.

This approach fails if a subscriber crashes and fails to deregister its subscriptions from the master.

[moesenle]

It also fails if the subscriber is shutting down (even cleanly) right after the publisher got the number of subscribers but before the subscriber actually establishes the connection. Not sure how likely this is to happen though.

[blaroche]

I like the idea of an early warning. advertise already takes AdvertiseOptions, but it could also give back AdvertiseResults, which would contain for example the total number of subscribers, the ones that have connected, status messages about pending connections, etc.

Like I said, it's not fail-proof, mainly for the two reasons that you mentioned. I would rather call this a best-effort method, which would be acceptable if described as such in the documentation. Users would then have to take this into account in their application logic.

[dirk-thomas]

The publish-subscribe paradigm implemented for ROS explicitly decouples both sides. It is intentional that the number of subscribers is not known. Adding such a feature bypassing this decoupling is currently not planned for the client libraries.

The initially described issue of "lost" messages during startup of the graph is inherent by the current design and could be only resolved by a major redesign.

[blaroche]

I like the fact that ROS has very low coupling between publishers and subscribers, but hiding information does not help with coupling. Coupling is the dependence of a module on another, and having more information wouldn't increase this dependence; it would just mean that there is more information available if necessary.

Having said that, while the ROS platform should continue to have low coupling, user applications themselves may require higher coupling. By receiving the number of subscribers, and even the IP or other information, the publisher node would be much more flexible in its behavior. It would open up the ROS platform to a much broader range of applications, without taking anything away from the original design.

Given that the question on answers.ros.org was viewed over 900 times and that the same question is asked on different forums, I think that this problem is not well understood (or desired) by the community. I would really suggest trying to find some kind of solution, rather than staying with the status quo.

[dirk-thomas]

I am not implying that ROS should stay with the status quo.

But the initially stated problem of being unable to reliably send a single message because during start-up of the ROS graph the subscribers are not yet connected is a very fundamental design problem. This can neither be resolved with a simple patch nor should it be worked around by i.e. waiting until a hard coded number of subscribers has connected.

The feature to provide a deterministic start-up behavior is a very important one for ROS in the future. We will work on this in the "next generation of ROS" SIG. But changes like this will alter ROS significantly and will not land in one of the next ROS releases.