Skip to content
This repository was archived by the owner on May 31, 2025. It is now read-only.

fix getNumPublishers() to only count fully connected#2107

Merged
jacobperron merged 1 commit intoros:noetic-develfrom
BadgerTechnologies:fix-get-num-publishers-noetic
Dec 28, 2020
Merged

fix getNumPublishers() to only count fully connected#2107
jacobperron merged 1 commit intoros:noetic-develfrom
BadgerTechnologies:fix-get-num-publishers-noetic

Conversation

@c-andy-martin
Copy link
Copy Markdown
Contributor

There is code which uses getNumPublishers() being positive as a
guarantee that a call to the remote publisher's publish() is
guaranteed to send a message to the subscriber. However, because
connections which have not yet received their header are counted,
this is not true. One such user of getNumPublishers() is actionlib.
It relies on getNumPublishers() only returning postive when a publish
on the result topic would succeed.

Fix this by only counting connections with received headers. If we
have received the header, we know the remote publisher is tracking a
connection back to us and has accepted the connection and that a
call to publish() on its end will send the message.

Note that this issue is only relevant for the TCP transport, as the
UDP transport and intraprocess link have already setup their header
by the time they are added to the publication links. Since all
publisher link types update the header, including the caller ID,
counting those with caller IDs set to non-empty is sufficient to
solve the issue.

There is code which uses getNumPublishers() being positive as a
guarantee that a call to the remote publisher's publish() is
guaranteed to send a message to the subscriber. However, because
connections which have not yet received their header are counted,
this is not true. One such user of getNumPublishers() is actionlib.
It relies on getNumPublishers() only returning postive when a publish
on the result topic would succeed.

Fix this by only counting connections with received headers. If we
have received the header, we know the remote publisher is tracking a
connection back to us and has accepted the connection and that a
call to publish() on its end will send the message.

Note that this issue is only relevant for the TCP transport, as the
UDP transport and intraprocess link have already setup their header
by the time they are added to the publication links. Since all
publisher link types update the header, including the caller ID,
counting those with caller IDs set to non-empty is sufficient to
solve the issue.
@c-andy-martin c-andy-martin force-pushed the fix-get-num-publishers-noetic branch from 873f275 to b577505 Compare December 16, 2020 21:41
Copy link
Copy Markdown
Contributor

@fujitatomoya fujitatomoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes sense to me. only happens with TCPROS but there is a possibility that header is not registered via Connection::onHeaderLengthRead. keeping the behavior consistent for Subscription::getNumPublishers makes sense.

Copy link
Copy Markdown
Contributor

@jacobperron jacobperron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the fix!

@jacobperron jacobperron merged commit 30d8e9d into ros:noetic-devel Dec 28, 2020
jacobperron pushed a commit that referenced this pull request Apr 6, 2021
There is code which uses getNumPublishers() being positive as a
guarantee that a call to the remote publisher's publish() is
guaranteed to send a message to the subscriber. However, because
connections which have not yet received their header are counted,
this is not true. One such user of getNumPublishers() is actionlib.
It relies on getNumPublishers() only returning postive when a publish
on the result topic would succeed.

Fix this by only counting connections with received headers. If we
have received the header, we know the remote publisher is tracking a
connection back to us and has accepted the connection and that a
call to publish() on its end will send the message.

Note that this issue is only relevant for the TCP transport, as the
UDP transport and intraprocess link have already setup their header
by the time they are added to the publication links. Since all
publisher link types update the header, including the caller ID,
counting those with caller IDs set to non-empty is sufficient to
solve the issue.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants