Allow bidirectional traffic #4
Conversation
| @@ -114,6 +119,9 @@ TCPSender::TCPSender() | |||
| #endif | |||
| } | |||
|
|
|||
| if (m_nh.hasParam("ignored_publishers")) | |||
| } | ||
| } | ||
|
|
||
| this->send(topic, flags, event.getMessage()); |
There was a problem hiding this comment.
Did it in the new PR. Just curious, why is it better?
| void send(const std::string& topic, int flags, const topic_tools::ShapeShifter::ConstPtr& shifter); | ||
| void send(const std::string& topic, int flags, topic_tools::ShapeShifter::ConstPtr shifter, | ||
| const bool reconnect = true); | ||
| void messageCallback(const std::string& topic, int flags, |
|
Yes, of course. It's just gonna take some time, since now we're hurrying up on end-user evaluation meeting :) I hope to get back to it in a week or so. I had one more idea, but am not sure if I want to do that. It would be a kind of "autoconfiguration". There would be a local ros parameter, to which all receivers would store their nodename (in an array). The sender could then read this parameter and use it as the ignore list. I'm almost sure this is not the nicest solution (prone to concurrency issues), just the first one I came up with. If you have a better idea, please share it. |
No problem. I'm pretty busy with other stuff right now as well ;-)
I'm not sure about that. In our setups, we have many machines in a relay-like position (receiving from one machine, sending to another machine). In that case we need the receiver-sender connection. |
|
Well, it could be constrained only to publisher-receiver pairs communicating with the same host. But even then I'm not sure it's the way I'd take. I just want to simplify the config, because now it has several parameters that are not that easy to fill in (e.g. you can't use anonymous nodes for senders). |
|
Superseded by #5 . |
Added support for bidirectional topics.
I'm basing this on #3, but if you only want these changes, it should not be difficult to cherry-pick them.