Gazebo | Ignition | Community
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Subscriber message order

Is there any expectation about the order that messages are sent or handled on receipt?

I have a gazebo transport subscription where I'm regularly getting out of order calls to my handler where the network traffic is never going off machine.

I don't quite understand the implications, but I've tried publishing with block=true in the hopes that would somehow improve the behavior. I'm looking around for parameters which might control message order behavior and finding nothing.

My publisher is not rate limited and running quite fast ~1000hz, but hoping there's a solution without mucking with this.

Subscriber message order

Is there any expectation about the order that messages are sent or handled on receipt?

I have a gazebo transport subscription where I'm regularly getting out of order calls to my handler where the network traffic is never going off machine.

I don't quite understand the implications, but I've tried publishing with block=true in the hopes that would somehow improve the behavior. I'm looking around for parameters which might control message order behavior and finding nothing.nothing. Even reading through the Gazebo source code for clues.

My publisher is not rate limited and running quite fast ~1000hz, but hoping there's a solution without mucking with this.

Subscriber message order

Is there any expectation about the order that messages are sent or handled on receipt?

I have a gazebo transport subscription where I'm regularly getting out of order calls to my handler where the network traffic is never going off machine.

I don't quite understand the implications, but I've tried publishing with block=true block=true in the hopes that would somehow improve the behavior. I'm looking around for parameters which might control message order behavior and finding nothing. Even reading through the Gazebo source code for clues.

My publisher is not rate limited and running quite fast ~1000hz, but hoping there's a solution without mucking with this.