Ask Your Question

How do subscriber - publisher communicate each other?

asked 2016-06-15 00:46:36 -0500

Kay Park gravatar image

updated 2016-06-15 04:22:09 -0500

Hello folks,

I'm trying to connect a publisher node which is on Windows and a subscriber node on Ubuntu where a master node is on Raspbian; Windows PC(publisher) - Raspbian RaspberryPi(master) - Ubuntu PC(subscriber). (I just ported ros_comm and several core libraries to Visual Studio environment.)

The problem is, when I run a subscriber node on Windows PC and publisher node on Ubuntu PC, it worked. However, when the publisher-subscriber order is reversed (Windows PC has a publisher.. vice versa) it doesn't seem to work. The nodes are listed correctly through rostopic list command.

My question is, how the subscriber node and publisher node are connected in socket level? Does subscriber connect to publisher which is running as server? or both connect to each others?

Thanks a lot in advance. I've been helped so much from this gorgeous forum.


----------------------Resolved---------------------------------------------------------------------------------------------------------------- For people who would encounter problems like this I leave this message.

I found that I set the ROS_HOSTNAME in Windows which was ip-formatted string(ex. It was even wrong ip.

In ROS, host ip address is resolved in this order: ROS_HOSTNAME -> ROS_IP -> gethostname ...

So be aware using env variables. If you use multiple machines connected via ROS, you must set above variables correctly .

In addition to that, you should off the firewall! :)

Useful reference for understanding how connections are established: source code - ros_comm/ publication.cpp, subscription.cpp and related codes.

Below is technical overview doc in ROS wiki. This illustrates well how connections are made. image description

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-06-15 01:56:24 -0500

janindu gravatar image


So I went over the ROS Documentation and this is what I understood from it.

As the documentation says,

publish() in roscpp is asynchronous, and only does work if there are subscribers connected on that topic. publish() itself is meant to be very fast, so it does as little work as possible:

  1. Serialize the message to a buffer
  2. Pushes that buffer onto a queue for later processing

The queue it's pushed onto is then serviced as soon as possible by one of roscpp's internal threads, where it gets put onto a queue for each connected subscriber -- this second set of queues are the ones whose size is set with the queue_size parameter in advertise(). If one of these queues fills up the oldest message will be dropped before adding the next message to the queue.

It looks like the publisher and the subscriber do not directly interact. Instead, they use two queues. Publisher simply pushes data to q1 and the subscriber retrieves data from q2. Data transfer from q1->q2 is implicit and taken care of by the roscpp internals.

I'm not sure what you mean by the socket level connection between the subscriber and the publisher but I don't think there is such a connection between those two like client - server. Instead, both the subscriber and publisher will be connecting to the ROS master.

edit flag offensive delete link more


I surfed source codes in ros_comm and found that they(sub & pub) made connection .

The description you quoted seems right but based on code content the queues seem to be managed in nodes. (check out pendingConnectionDone method in subscription.cpp )

Thank you very much for investing your time!

Kay Park gravatar image Kay Park  ( 2016-06-15 02:36:54 -0500 )edit

Yes. Thank you. I'm reading more into this and learned a lot of new stuff. So apparently data does not go through the master. Master only provides names of publishers to subscribers so that the subscriber can directly connect to the publisher using TCP/UDP. I had a completely wrong understanding

janindu gravatar image janindu  ( 2016-06-16 00:24:22 -0500 )edit

Am I misunderstanding the quoted text from documentation, or does it really say that queue_size parameter in advertise() sets the size of q2. I expected that is would set the size of q1. I'd expect that q2 size would be set by subscribe()'s queue_size parameter. What am I missing?

chukcha2 gravatar image chukcha2  ( 2016-09-06 13:29:32 -0500 )edit

queue_size parameter in advertise() sets the size of q1 and in subscribe() sets q2.

janindu gravatar image janindu  ( 2016-09-06 19:32:55 -0500 )edit

Thanks @janindu. So the doc quoted above is wrong/misleading.

chukcha2 gravatar image chukcha2  ( 2016-09-07 13:32:36 -0500 )edit

Not really. I think there's a miscommunication here. q1, q2 are mentioned in my explanation of the document quote. Doc is right.

janindu gravatar image janindu  ( 2016-09-07 19:26:52 -0500 )edit

To me it sounds like the doc (wrongly) says that queue_size parameter in advertise() controls the "second set of queues" that you call q2 (the one the message is moved to by internal roscpp thread). I think it should say that the parameter controls the size of the queue that publish() pushes onto.

chukcha2 gravatar image chukcha2  ( 2016-09-08 11:48:22 -0500 )edit

FYI. I asked this question explicitly here

chukcha2 gravatar image chukcha2  ( 2016-09-12 15:55:52 -0500 )edit

answered 2016-06-15 01:35:01 -0500

asimay_y gravatar image

I think roscore's master node manage the activity of subscriber node and publisher node. your problem is not only the node, but also multi systems to communicate with each other. maybe you need to care about master and slave machines.

edit flag offensive delete link more


Yes I should check the system itself other than just checking out ROS.

Thank you very much for investing your time!

Kay Park gravatar image Kay Park  ( 2016-06-15 02:38:45 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-06-15 00:46:36 -0500

Seen: 1,407 times

Last updated: Jun 15 '16