Publisher and Sbuscriber queues and their sizes (roscpp)

Question

I read ROS Documentation:

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.

From the above I understand that the publisher pushes messages onto q1 and the subscriber retrieves data from q2. Data transfer from q1->q2 is taken care of by the roscpp internals. The documentation seems to suggest that advertise()'s queue_size option controls the size of q2 (not q1). Is that right? If that is really the case, then what controls the size of q1? And what queue does subscriber's queue_size control?

---

Originally posted by chukcha2 on ROS Answers with karma: 89 on 2016-09-06

Post score: 1

Answer 1

Yes, the publisher queue size is limiting the size of q2. q1 is not limited. A background thread continuously takes items from q1 and puts them into q2 (there is a separate q2 queue for each publication link and each drops the oldest message independently if the queue is full).

The subscriber has its own queue which buffers the messages after they have been read from the network interface and before they are being handled by a callback.

---

Originally posted by Dirk Thomas with karma: 16276 on 2016-09-08

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by chukcha2 on 2016-09-09:
Thank you. So is this roughly what happens then?:

msg --publish()--> q1 --roscpp--> q2  --unknown --> **tcp/ip stack**  --> q3 -- subscriber callback --> msg

q1 size is unlimited (dangerous?), q2 size is controlled by advertise()'s queue_size, q3 controlled by subscriber's queue_size.

Comment by Dirk Thomas on 2016-09-09:
Correct. I don't think the unlimited queue size is dangerous. Since it is "drained" continuously by a background thread I haven't seen it ever grow "unlimited". The limit for the q2 sizes is crucial since the "draining" of them might halt in some cases (e.g. network buffer full).