Communication between two components with static service discovery

[hemalbavishi]

Brief feature description

Usage of IPC Communication without Service Discovery or Static Service Discovery

Detailed information

I am just wondering whether iceoryx supports a use case with static service discovery. For an example, I've two AUTOSAR components and these two components communicate with each other using IPC Shared memory mechanism and exchange huge amount of data without any discovery mechanism (offerservice and findservice). Ofcourse, I can use it with service discovery but wouldn't be an overhead during start-up?

Context: I am just wondering whether it makes sense to use iceoryx for IFC in Adaptive Platform or any optimization is required to make it better?

[mossmaurice]

I know that @prasannabhat worked on this topic. He might be able to answer questions around that topic.

[budrus]

Indeed we are also thinking about static discovery. The question is why you want to have it. Is it about startup time or about a leaner API?

In protocols like SOME/IP you need discovery to resolve things like IP addresses and ports. With a static discovery you can save the discovery network traffic and some time.
In iceoryx we have a cyclic discovery in the background that adapts connections according to user requests. Default is a 100 ms cycle time. Is this a problem? I just had the idea if it could make sense to create publishers and subscribers that are offered or want to be subscribed by default. Then we could do the wiring already when creating the resources. Currently it takes until the next discovery loop to detect that a created subscriber wants to be subscribed now. Sure, as applications can come and go individually, there is no guarantee that you are subscribed when you start an application with a subscriber or that you will be subscribed all the time.

With ara::com on top of iceoryx you don't have to use the OfferService / FindService. E.g. when creating a proxy you can create an iceoryx subscriber for each Event receiver and already call subscribe() on iceoryx side during creation. Same with offer() for Event Senders. I.e. you don't have to use the ara::com discovery functionality and do the mapping to iceoryx if you are only interested in static discovery. This would save you the ara::com discovery overhead but it would still need some time for the connections behind the scenes.

Which of the two use cases is yours? Both is also a valid answer ;-). I also like more and more the idea of establishing the connection at creation time if this is desired. Maybe we should consider this in #408

If you are thinking about using iceoryx for Adaptive these two features are maybe interesting for you #27 #415

[budrus]

WIth #584 it is possible to connect matching publisher and subscribers without the need for discovery. So closing this issue

[Indra5196]

WIth #584 it is possible to connect matching publisher and subscribers without the need for discovery. So closing this issue

But with #584, we are eventually doing what offer() was doing. By setting offerOnCreate = true, we are setting m_offeringRequested = true in the publisher port data, which we were doing by calling the offer() method. Both offer() and offerOnCreate are eventually doing one thing only, that is registering the port for service discovery.

Maybe, what @hemalbavishi was looking for, is that there should be some static configuration, which will be used by Publisher port to add a sender queue on its side, without involving port manager.

Reason for this can be

1. Its known that the receiver will be available, and
2. There can be occasions where Service discovery could fail (although it wont fail generally)

i feel that the CaProMessage provided by the subscriber to the publisher, which is used to add sender queues on the publisher side, can be statically configured. Please let me know if there is any catch in doing so

[elBoberido]

@Indra5196 I'm not quite sure if I understand your request correctly. With the current approach to offer and subscribe on create it doesn't matter if the port manager is involved. It also doesn't matter if service discovery fails since the queues are added once the publisher or subscriber are created. From a user point of view, it is not distinguishable if the queue was already there or only added when the subscriber was created. Except that the samples are only delivered once the subscriber is there. But if the publisher has a history capacity large enough to match the specified subscriber queue capacity, there would be no difference.

[Indra5196]

From a user point of view, it is not distinguishable if the queue was already there or only added when the subscriber was created. Except that the samples are only delivered once the subscriber is there.

Exactly. For the static discovery scenario, we are 110% sure that the subscriber is always available. Hence, we do not want to go through the port manager logic and get the ports created. Instead, if we have the sender queues on the publisher end without checking for the subscriber's presence, we will be 110% sure that we have the connection in place and we are ready to publish the data right from the start.

Yes I understand that that the time taken for discovery of ports is negligible, But there is always a chance that we are stuck in some exception during discovery.

[elBoberido]

I think there is not much difference when it comes to things that can go wrong. In one case everything is statically created and when you request a subscriber, RouDi has to find the statically created subscriber which matches the service description and return it to the application. If too many applications requesting a subscriber with the same service description, the request fails. With the current approach, RouDi takes a free port from the port manager, then iterates over all available publisher and adds the subscriber queue to the matching publisher. Similar to the static approach, if there are no free ports available, the request fails. Additionally if there are already too many subscribers on the publisher, the subscription would fail. This two possible failures are quite similar in their cause to the one possible failure with the static approach. Additionally, we still would need a cleanup mechanism in case an application crashes and gets restarted, which would lead to a similar architecture like we have now.

Do you participate on the developer meetup today? Maybe this is something we can talk about at the meeting?