ROS Nodes and topics - are nodes really decoupled?

edit

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 ...