Gateway: Support Client/Server in GatewayGeneric

[jmyvalour]

Hello,

We are looking to add a network gateway support for our iceoryx Publisher / Server services, in order to do so we are using the GatewayGeneric base class (with its discover, forward, *channels api helpers...). Everything is working fine for Publisher/Subscriber pattern, but GatewayGeneric does not provides support for Server/Client,

The addChannel is using the capro::ServiceDescription and a IceoryxPubSubOptions template type. Main problem is that in case I am using the same topic for a Server / Publisher, we are not able to detect if this is coming from a Publisher or a Server and the AddChannel will already find the previous one. More generally, it does not look like Server/Client is suppose to be supported in the current implementation, maybe I am missing something here ?

I was wondering the following:

1. Is there any plan to support Server / Client in the future in the Gateway ?
2. Is the current solution for now would be to have two gateway instances, (one for the Servers and another for Publishers),

Thank you for your help,

[mossmaurice]

@jmyvalour Thanks for opening this issue.

More generally, it does not look like Server/Client is suppose to be supported in the current implementation, maybe I am missing something here ?

That is correct. The Gateway was developed before Client/Server communication was available in iceoryx v2.0.

Is there any plan to support Server / Client in the future in the Gateway ?

It is currently not planned for v3.0 (which will land in the coming months) and AFAIK neither for v4.0. Would you be interesting to contribute this feature and extend the GatewayGeneric?

Maybe you are already aware, here's the link to the DDS gateway using the GatewayGeneric.

[elBoberido]

It is currently not planned for v3.0 (which will land in the coming months)

There is a typo. You probably meant weeks ;)

[jmyvalour]

Hello,

Thank you for your support and help,

I would be interested to add this feature but no clear timetable on my side regarding the when,

One simple solution I have for now (that would avoid rewriting anything in the gateway) would be to use the ClassHash of the ServiceDescription and update the internal ServiceDescription::operator== to use it on top of its Service, Instance and Event. That would allow to accept duplicated names in the GatewayGeneric as long as the ClassHash differs, (I did not extend my research regarding the impact it will have on the overall project) Will update the ticket when I push this topic further, but any input / idea / comment from you will be helpful.

Current state I have for now is working (as long as server / publisher have different service description) and instanciating a client / subscriber based on the m_serviceType we are discovering from the Gateway::Discover API, As the Options passed to addChannel are templated, I can detect if this is related to a client or a subscriber. That does the trick nicely on that part. Here is the IceoryxTerminal type:

struct IceoryxReceiver
{
using Type = std::variant<std::monostate, std::shared_ptriox::popo::UntypedSubscriber, std::shared_ptriox::popo::UntypedClient>;

explicit IceoryxReceiver(const iox::capro::ServiceDescription& description, const iox::popo::SubscriberOptions& option)
{
auto& sub = m_iceoryxReceiver.emplace<std::shared_ptriox::popo::UntypedSubscriber>(new iox::popo::UntypedSubscriber(description, option));
}

explicit IceoryxReceiver(const iox::capro::ServiceDescription& description, const iox::popo::ClientOptions& option)
{
auto& client = m_iceoryxReceiver.emplace<std::shared_ptriox::popo::UntypedClient>(new iox::popo::UntypedClient(description, option));
}

Type& Value() {
return m_iceoryxReceiver;
}

private:
Type m_iceoryxReceiver;
};

Jeremy

[elBoberido]

@jmyvalour I don't think that using the ClassHash is the way forward. At some point we even wanted to remove it. Not sure why we didn't in the end, maybe we just forgot about it.

I'm not that familiar with the gateway but without digging deeper, I would think that the current addChannel should be renamend to addUnidirectionalChannel (maybe with a deprecation period) and a new addBidirectionalChannel should be added to the gateway. I think this makes it easier to separate between pub-sub and req-res.