Comments (4)
@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
.
from iceoryx.
It is currently not planned for
v3.0
(which will land in the coming months)
There is a typo. You probably meant weeks ;)
from iceoryx.
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
from iceoryx.
@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.
from iceoryx.
Related Issues (20)
- POPO__CHUNK_LOCKING_ERROR on iox-roudi HOT 3
- Remove warning in toml gateway config parser
- how to run ice_access_control demo HOT 8
- Iceoryx RAW_SOCKET buffer usage HOT 7
- Update links to default branch
- Make iceoryx resource prefix a compile time option
- Fix new clang-tidy-18 warnings
- ICEORYX error! POPO__CHUNK_LOCKING_ERROR HOT 4
- Mark iox container operations which return bool as [[nodiscard]] HOT 1
- 'iox::string' tests can exceed the translation unit compilation timeout
- Prepare v2.0.6 release for ROS2
- Compiler warnings on latest macOS on release_2.0
- sendChunk, releaseChunk latencies HOT 6
- While setting the acquired shared memory to zero a fatal SIGBUS signal appeared caused by memset. HOT 5
- how to support string using zero-copy transport HOT 1
- Add 'iox' prefix to all functions and types in the platform abstraction
- SingleProcess example crashes on QNX HOT 4
- : backtrace: HOT 2
- Is `libatomic` still required to build Iceoryx? HOT 7
- Some questions about IndexQueue. HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iceoryx.