Gateway: Support Client/Server in GatewayGeneric

[jmyvalour]

Gateway: Support Client/Server in GatewayGeneric

[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.