Rosanswers logo


Note how the two sides are decoupled. All the hokuyo_node node does is publish scans, without knowledge of whether anyone is subscribed. All the rviz does is subscribe to scans, without knowledge of whether anyone is publishing them. The two nodes can be started, killed, and restarted, in any order, without inducing any error conditions.

We all know these statements that using topics, decouples ROS nodes. However reading the documentation on how the connection between the nodes established makes me question this statement. However in the transport section states the following:

Given a publisher URI, a subscribing node negotiates a connection, using the appropriate transport, with that publisher, via XMLRPC. The result of the negotiation is that the two nodes are connected, with messages streaming from publisher to subscriber.

Each transport has its own protocol for how the message data is exchanged. For example, using TCP, the negotiation would involve the publisher giving the subscriber the IP address and port on which to call connect. The subscriber then creates a TCP/IP socket to the specified address and port. The nodes exchange a Connection Header that includes information like the MD5 sum of the message type and the name of the topic, and then the publisher begins sending serialized message data directly over the socket.

So my question is, are the publisher and the subscriber really decoupled? After all in order the subscriber to get a message it has to open TCP/IP connection the the publisher port. And if the publishers are n the subscriber needs to open n connections. This means that it's not completely true that the subscriber won't be bothered if one of the publishers fails. So what exactly is meant by that statement that the nodes are decoupled?

Originally posted by Anton Belev on ROS Answers with karma: 15 on 2015-02-14

Post score: 1


1 Answer 1


Rosanswers logo

tl;dr: yes, there are direct connections between nodes (so they need to know each others 'names' (IP addresses)), but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware (and thus invisible to nodes at the application/user level of the API).

While you are correct that there are TCP connections between nodes, I don't think that that is what the decoupled in the first quote you included refers to.

The following is an excerpt from the paper The Many Faces Of Publish/Subscribe by Patrick Eugster, et al., which for me is the clearest description of decoupling I know (you can read event service here as being equivalent to a middleware):

The decoupling that the event service provides between publishers and subscribers can be decomposed along the following three dimensions (Figure 2):

  • Space decoupling: The interacting parties do not need to know each other. The publishers publish events through an event service and the subscribers get these events indirectly through the event service. The publishers do not usually hold references to the subscribers, neither do they know how many of these subscribers are participating in the interaction. Similarly, subscribers do not usually hold references to the publishers, neither do they know how many of these publishers are participating in the interaction.
  • Time decoupling: The interacting parties do not need to be actively participating in the interaction at the same time. In particular, the publisher might publish some events while the subscriber is disconnected, and conversely, the subscriber might get notified about the occurrence of some event while the original publisher of the event is disconnected.
  • Synchronization decoupling: Publishers are not blocked while producing events, and subscribers can get asynchronously notified (through a callback) of the occurrence of an event while performing some concurrent activity. The production and consumption of events do not happen in the main flow of control of the publishers and subscribers, and do not therefore happen in a synchronous manner.

It appears that the ROS middleware does not implement these aspects on all levels, as you mentioned. At the application level (where you interact with the ROS C++/Python/X API), nodes do not care about the names of other nodes, only about topics. There we have space decoupling.

But the data will have to get to subscribers in some way. ros_comm uses TCP for that (in the case where TCPROS is used) and for efficiency reasons does that by direct connections between nodes (otherwise data would have to be copied from publisher to intermediate entity, then to each subscriber). So at the message transport level in ROS, there is no space decoupling (with the default TCPROS).

ROS does not currently seem to support time decoupling, as subscribers and publishers need to be running for messages to be exchanged. This seems a consequence of the direct TCP connections between nodes: if one of the endpoints of those connections isn't "up", messages will not flow. For ROSv2.0 however, the DDS middleware could potentially fix this.

As to synchronization decoupling: the ros_comm middleware and roscpp use threading and multiple event queues to avoid blocking the publisher while his messages are being transmitted to subscribers, so nodes seem to be decoupled in this dimension.

Originally posted by gvdhoorn with karma: 86574 on 2015-02-14

This answer was ACCEPTED on the original site

Post score: 9

Original comments

Comment by Anton Belev on 2015-02-14:
Fabulous answer, much appreciated, @gvdhoorn!

Comment by Anton Belev on 2015-02-14:
The only question that arise in your answer is - since nodes are establishing TCP/IP Connection to each other to improve efficiency, this implies that a given subscriber has to open n TCP/IP connections in order to get messages from n publishers. Then the Space decoupling is also questionable.

Comment by gvdhoorn on 2015-02-15:
Well yes, it implies that you need n connections if you have n subscriptions to different publishers. But as I wrote: you need to get the data across somehow.

Comment by gvdhoorn on 2015-02-15:
There have been experiments with other message transports (ROS terminology), such as UDP multicast and shared memory (see ethzasl_message_transport fi), and although these don't use n connections, they have their own drawbacks (routability, etc).

Comment by alienmon on 2016-08-09:
@gvdhoorn If they need to make direct connection, it means that they will know about each other info/reference, so it is not space decoupling? Also, when making/opening connections, the publisher will know how many subscribers by the number of connections. Please explain , thanks

Comment by alienmon on 2016-08-09:
@gvdhoorn you wrote "Space decoupling: The interacting parties do not need to know each other", but if they make connection then they know each other. I'm new to ROS, so I'm a bit confused here. pls explain :)

Comment by gvdhoorn on 2016-08-10:
I believed I had explained that in my answer (did you click (more)?) but: yes, at some level, there is some space coupling in ROS, as the TCP/IP connections will need to be established somehow. At the abstraction level where it matters though (user code), there is none.

Comment by gvdhoorn on 2016-08-10:
And: the Eugster et al. article (that I only quoted from) is not specific to ROS, and the dimensions of decoupling proposed in it work for all (?) middlewares making use of the considered interaction styles. So you'll find (some of) the same 'problems' in OROCOS, YARP, etc. Also in DDS and OPC-UA.

Comment by alienmon on 2016-08-10:
@gvdhoorn Okay I think I understand more now. So as far as the concern is the high level coding (e.g. trough roscpp) they don't need to know each others' name, but at the lower level they actually know (do couple) to send info. right? Btw can u explain what does it mean by "publishers not blocked"?

Comment by gvdhoorn on 2016-08-10:\

the high level coding (e.g. trough roscpp) they don't need to know each others' name, but at the lower level they actually know (do couple) to send info


re: not blocked: Publisher::publish(..) returns immediately, and does not wait for all recipients to have received the msg.

Comment by aks on 2018-04-16:
Sorry for re-opening such an old post. On what factors is the communication protocol selected ? be it TCP or UDP. Are there some other protocols supported as well ?

Comment by gvdhoorn on 2018-04-16:
It would perhaps be better to open a new post. Your question is only tangentially related to this one.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.