Revision history [back]

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 of the paper The Many Faces Of Publish/Subscribe by Patrick Eugster, et al., which for me is the clearest description of decoupling I know:

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 principles on all levels, as you discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher to intermediate entity, then to each subscriber).

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.

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 of the paper The Many Faces Of Publish/Subscribe by Patrick Eugster, et al., which for me is the clearest description of decoupling I know:

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

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

It appears that the ROS middleware does not implement these principles on all levels, as you discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher to intermediate entity, then to each subscriber).

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.

tl;dr: yes, there are direct connections between nodes, but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware.

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 of 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:

The decoupling that the event service (or middleware, ed.) 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 principles on all levels, as you discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher to intermediate entity, then to each subscriber).

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.

tl;dr: yes, there are direct connections between nodes, but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware.

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:know (you can read event service here as being equivalent to a middleware):

The decoupling that the event service (or middleware, ed.) provides between publishers and and subscribers can be decomposed along along the following three dimensions (Figure (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 principles on all levels, as you discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher to intermediate entity, then to each subscriber).

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.

tl;dr: yes, there are direct connections between nodes, but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware.

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 principles aspects on all levels, as you discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher to intermediate entity, then to each subscriber).

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.

tl;dr: yes, there are direct connections between nodes, but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware.

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 discovered: at the application level, nodes do not care about the names of other nodes (so 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 publusher publisher to intermediate entity, then to each subscriber).

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.

tl;dr: yes, there are direct connections between nodes, 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.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 discovered: at the application level, nodes do not care about the names of other nodes (so there nodes, only about topics. There we have space decoupling), but .

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), 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).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 ROSv2.0 however, the DDS middleware 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.

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 discovered: at mentioned.

At the application level, 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.

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.

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.