ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I'm pretty sure those callbacks are in the end called here in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here and here. The callbacks are registered here.

Publication::addSubscriberLink(..) gets called here in TransportSubscriberLink::handleHeader(..), which ..

I'm pretty sure those callbacks are in the end called here in in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here (in Publication::addSubscriberLink(..)) and here. (in Publication::removeSubscriberLink(..)). The callbacks you pass to NodeHandle::advertise<>(..) are registered transferred to the actual Publisher object in herePublisher::Publisher(..).

Publication::addSubscriberLink(..) gets called in here in TransportSubscriberLink::handleHeader(..), which ..

is an event handler that gets invoked (via ConnectionManager::onConnectionHeaderReceived(..)) whenever a new connection is negotiated between a Subscriber and a Publisher (directly, so the master is already out of the picture here).

I've stopped there, you should be able to follow it from there yourself.

Assume I know about the existance of another node that will eventually/finally subscribe to the advertised topic. [..] Please, I don't want to discuss here that this may not be the idea of a decoupled communication concept, i.e., what pub/sub was designed for.)

you may not want to, but I'd still be interested to hear what application architecture necessitates using those callbacks. I've not seen them used very often. Nodes expecting other nodes to "be present" is certainly an anti-pattern (see “Runtime-configurable” Parameters in Autoware.ai on ROS Discourse for a good example of this in Autoware.ai).

Also note (but you may already be aware) that the connect_cb will be called for every new Subscriber. Not just the first.

So, publishing messages right after the advertise() can causes messages not being received by all "relevant nodes" at that time. (IIRC, this issue has been discussed frequently here on ros.answers.org and one nasty workaround is a delay after the advertise.)

Actually, using Publisher::getNumSubscribers() is best practice there, not a delay. State-based is always better than time-based.

I'm pretty sure those callbacks are in the end called in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here (in Publication::addSubscriberLink(..)) and here (in Publication::removeSubscriberLink(..)). The callbacks you pass to NodeHandle::advertise<>(..) are transferred to the actual Publisher object in Publisher::Publisher(..).

Publication::addSubscriberLink(..) gets called in TransportSubscriberLink::handleHeader(..), which is an event handler that gets invoked (via ConnectionManager::onConnectionHeaderReceived(..)) whenever a new connection is negotiated between a Subscriber and a Publisher (directly, so the master is already out of the picture here).

I've stopped there, you should be able to follow it from there yourself.

Assume I know about the existance of another node that will eventually/finally subscribe to the advertised topic. [..] Please, I don't want to discuss here that this may not be the idea of a decoupled communication concept, i.e., what pub/sub was designed for.)

you may not want to, but I'd still be interested to hear what application architecture necessitates using those callbacks. I've not seen them used very often. Nodes expecting other nodes to "be present" is certainly an anti-pattern (see “Runtime-configurable” Parameters in Autoware.ai on ROS Discourse for a good example of this in Autoware.ai).

Also note (but you may already be aware) that the connect_cb will be called for every new Subscriber. Not just the first.

So, publishing messages right after the advertise() can causes messages not being received by all "relevant nodes" at that time. (IIRC, this issue has been discussed frequently here on ros.answers.org and one nasty workaround is a delay after the advertise.)

Actually, using Publisher::getNumSubscribers() is best practice there, not a delay. State-based is always better than time-based.

Finally:

Is it safe to assume that once the above mentioned connect_cb is triggered, the underlying TCP connection _must_ have been established so that publishing messages using the returned ros::Publisher object will definitely deliver the message to the node denoted by ros::SingleSubscriberPublisher::getSubscriberName() (= argument of the callback)?

Seeing as the callbacks appear to be only called at the very end of TransportSubscriberLink::handleHeader(..), your assumption seems like one that could be true. The code suggests that after the connection is made and the connection header is exchanged, all registered connect_cb callbacks are called. I'm not sure whether this can fail sufficiently for the connection not to be considered "established".

I'm pretty sure those callbacks are in the end called in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here (in Publication::addSubscriberLink(..)) and here (in Publication::removeSubscriberLink(..)). The callbacks you pass to NodeHandle::advertise<>(..) are transferred to the actual Publisher object in Publisher::Publisher(..).

Publication::addSubscriberLink(..) gets called in TransportSubscriberLink::handleHeader(..), which is an event handler that gets invoked (via ConnectionManager::onConnectionHeaderReceived(..)) whenever a new connection is negotiated between a Subscriber and a Publisher (directly, so the master is already out of the picture here).

I've stopped there, you should be able to follow it from there yourself.

Assume I know about the existance of another node that will eventually/finally subscribe to the advertised topic. [..] Please, I don't want to discuss here that this may not be the idea of a decoupled communication concept, i.e., what pub/sub was designed for.)

you may not want to, but I'd still be interested to hear what application architecture necessitates using those callbacks. I've not seen them used very often. Nodes expecting other nodes to "be present" is certainly an anti-pattern (see “Runtime-configurable” Parameters in Autoware.ai on ROS Discourse for a good example of this in Autoware.ai).

Also note (but you may already be aware) that the connect_cb will be called for every new Subscriber. Not just the first.

So, publishing messages right after the advertise() can causes messages not being received by all "relevant nodes" at that time. (IIRC, this issue has been discussed frequently here on ros.answers.org and one nasty workaround is a delay after the advertise.)

Actually, using Publisher::getNumSubscribers() is best practice there, not a delay. State-based is always better than time-based.

Finally:

Is it safe to assume that once the above mentioned connect_cb is triggered, the underlying TCP connection _must_ have been established so that publishing messages using the returned ros::Publisher object will definitely deliver the message to the node denoted by ros::SingleSubscriberPublisher::getSubscriberName() (= argument of the callback)?

Seeing as the callbacks appear to be only called at the very end of TransportSubscriberLink::handleHeader(..), your assumption seems like one that could be true. The code suggests that after the connection is made and the connection header is exchanged, all registered connect_cb callbacks are called. I'm not sure whether this can fail sufficiently for the connection not to be considered "established".

"established" though.

I'm pretty sure those callbacks are in the end called in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here (in Publication::addSubscriberLink(..)) and here (in Publication::removeSubscriberLink(..)). The callbacks you pass to NodeHandle::advertise<>(..) are transferred to the actual Publisher object in Publisher::Publisher(..).

Publication::addSubscriberLink(..) gets called in TransportSubscriberLink::handleHeader(..), which is an event handler that gets invoked (via ConnectionManager::onConnectionHeaderReceived(..)) whenever a new connection is negotiated between a Subscriber and a Publisher (directly, so the master is already out of the picture here).

I've stopped there, you should be able to follow it from there yourself.

Assume I know about the existance of another node that will eventually/finally subscribe to the advertised topic. [..] Please, I don't want to discuss here that this may not be the idea of a decoupled communication concept, i.e., what pub/sub was designed for.)

you may not want to, but I'd still be interested to hear what application architecture necessitates using those callbacks. I've not seen them used very often. Nodes expecting other nodes to "be present" is certainly an anti-pattern (see “Runtime-configurable” Parameters in Autoware.ai on ROS Discourse for a good example of this in Autoware.ai). (and see @gbiggs response here)).

Also note (but you may already be aware) that the connect_cb will be called for every new Subscriber. Not just the first.

So, publishing messages right after the advertise() can causes messages not being received by all "relevant nodes" at that time. (IIRC, this issue has been discussed frequently here on ros.answers.org and one nasty workaround is a delay after the advertise.)

Actually, using Publisher::getNumSubscribers() is best practice there, not a delay. State-based is always better than time-based.

Finally:

Is it safe to assume that once the above mentioned connect_cb is triggered, the underlying TCP connection _must_ have been established so that publishing messages using the returned ros::Publisher object will definitely deliver the message to the node denoted by ros::SingleSubscriberPublisher::getSubscriberName() (= argument of the callback)?

Seeing as the callbacks appear to be only called at the very end of TransportSubscriberLink::handleHeader(..), your assumption seems like one that could be true. The code suggests that after the connection is made and the connection header is exchanged, all registered connect_cb callbacks are called. I'm not sure whether this can fail sufficiently for the connection not to be considered "established" though.

I'm pretty sure those callbacks are in the end called in Publication::peerConnect(..) and Publication::peerDisconnect(..). Those are in turn called here (in Publication::addSubscriberLink(..)) and here (in Publication::removeSubscriberLink(..)). The callbacks you pass to NodeHandle::advertise<>(..) are transferred to the actual Publisher object in Publisher::Publisher(..).

Publication::addSubscriberLink(..) gets called in TransportSubscriberLink::handleHeader(..), which is an event handler that gets invoked (via ConnectionManager::onConnectionHeaderReceived(..)) whenever a new connection is negotiated between a Subscriber and a Publisher (directly, so the master is already out of the picture here).

I've stopped there, you should be able to follow it from there yourself.

Assume I know about the existance of another node that will eventually/finally subscribe to the advertised topic. [..] Please, I don't want to discuss here that this may not be the idea of a decoupled communication concept, i.e., what pub/sub was designed for.)

you may not want to, but I'd still be interested to hear what application architecture necessitates using those callbacks. I've not seen them used very often. Nodes expecting other nodes to "be present" is certainly an anti-pattern (see “Runtime-configurable” Parameters in Autoware.ai on ROS Discourse for a good example of this in Autoware.ai (and see @gbiggs @Geoff's response here)).

Also note (but you may already be aware) that the connect_cb will be called for every new Subscriber. Not just the first.

So, publishing messages right after the advertise() can causes messages not being received by all "relevant nodes" at that time. (IIRC, this issue has been discussed frequently here on ros.answers.org and one nasty workaround is a delay after the advertise.)

Actually, using Publisher::getNumSubscribers() is best practice there, not a delay. State-based is always better than time-based.

Finally:

Is it safe to assume that once the above mentioned connect_cb is triggered, the underlying TCP connection _must_ have been established so that publishing messages using the returned ros::Publisher object will definitely deliver the message to the node denoted by ros::SingleSubscriberPublisher::getSubscriberName() (= argument of the callback)?

Seeing as the callbacks appear to be only called at the very end of TransportSubscriberLink::handleHeader(..), your assumption seems like one that could be true. The code suggests that after the connection is made and the connection header is exchanged, all registered connect_cb callbacks are called. I'm not sure whether this can fail sufficiently for the connection not to be considered "established" though.