-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
service registry as a built-in topic #415
Comments
A big drawback to the built-in topic is the worst case memory consumption. We maybe have to take into account that each application holds a different generation of the service registry sample, depending on how it's implemented. Even if we don't expose the sample to the user and do everything in the runtime, there might still be situation where multiple generations are held by various runtimes. With the introspection we currently assume that there is only one client and we just print some errors if the mempool runs out of chunks. It might be problematic to do the same with the service registry topic. The proposed fix for #332 will enable segmented transmissions by IPOSIX PC channels. This doesn't solve the problem of the shared communication channel for registration, heartbeat and requesting resources like ports. I would split that into multiple channels, at least one just for registration/heartbeat and resource requests. This would still not solve the problem of sending large data by this channels but at least doesn't block registration. The IPC channel could be used as a fallback in case all chunks reserved for the service registry are exhausted. In order to make this work, the service registry must not be a built-in topic but still be requested by the IPC channel. So we would have the following scenario:
This ensures that the application always gets the information although it might be expensive if the chunks are exhausted. Alternatively instead of serializing the chunk, a pending response or error message could be sent. |
good point @elBoberido. Having the MQ or UDS channel as point of contact and in the startup phase of an application is fine. But during runtime any possible interference from such a resource and potentially blocking calls on it should be avoided. I'm not sure if we solve this with your proposal without making things complicated. |
sure, iceoryx req/res would work exactly like the POSIX IPC channel, just that there would be a pending response/error response instead of serialization |
When we touch the service registry here, should we also take care about naming of our IDs in the CaPro description? The proposal of @MatthiasKillat was to have Topics, Instances of Topics and Groups of Topics. I.e. renaming ServiceID to GroupID, InstanceID stays, renaming EventID to TopicID. |
@budrus I think it's a good idea to rename the three CaPro identifiers. We need to make sure to have good documentation, so that developers coming from different backgrounds feel at home. Ok from my side to do this in this issue. |
With the proposed change to the composition of a service description, we would be restricting services to a single topic. Is this something that we want ? Considering the above, it seems that the concepts of services and events are being conflated, and this makes it confusing (at least to me). What are we trying to achieve with the change?
If the former, then I think just adding another component |
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
…relevant code places Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
…uilt-in topic Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
Signed-off-by: Simon Hoinkis <simon.hoinkis@apex.ai>
…nition Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
iox-#415 Add functional find service example
User API finished, implementation will be refactored with #1200 |
Brief feature description
The discovery requests from user side are currently transferred via the message queue connection. This has some drawbacks
findService()
is very close to AUTOSAR ara::com and maybe cannot be used in a reasonable way in other frameworksDetailed information
The proposal is to have a service registry that provides it's content as a built-in topic, similar to the introspection topics. Then a subscriber could be created to get the information either in a polling way or event-driven by using the subscriber in combination with a waitset. The service registry publisher would use a history with size 1. Then every subscriber gets the current state on subscribe if desired. By providing the full CaPro ID information and not only service and instance IDs, this built-in topic could also be used for non AUTOSAR use cases. With this approach having a large service registry is fine as we don't have to send the content over the message queue and it's distributed with iceoryx' finest true zero-copy. I guess we can then also get rid of
getServiceRegistryChangeCounter()
which smells like workaroundTodo
cxx::map
(Will be done in Create a map data structure for the iceoryx hoofs library #829)ServiceDescription
ServiceDescription
ServiceDescription
Forbid creating Pub/Sub withServiceDescription(AnyServiceString, AnyInstanceString, "foo")
and forbid adding such a invalidServiceDescription
to the registryAdd ServiceDescriptionBuilderMoved to Refactoring of ServiceDescription #1141ServiceRegistry
to use the wholeServiceDescription
ServiceDescription(const cxx::Serialization& serial)
likeclient_options.cpp
DiscoveryInfo
class and movegetServiceRegistryChangeCounter
,findService
,to this classofferService
andstopOfferService
icediscovery
README.md
foricediscovery
[ ] Introduce newMoved to Design newStatusPorts
StatusPort
#982Built-in topic for service registry based onMoved to UseBroadcastPorts
StatusPort
for introspection andServiceDiscovery
#1135User facing API[ ] ReplaceMoved to Design newInterfacePorts
withStatusPorts
StatusPort
#982Mapping to Autosar Adaptive and APIs to work on an Autosar service levelMoved to Create example of service discovery monitoring #1103[ ] Usage of Create a set data structure for the iceoryx hoofs library #830[ ] Adaption of(not needed, we basically have a multiset with counters)ServiceRegistry::add()
(remove duplicate search)ServiceRegistry::remove()
should use same algorithm asfind()
to locate the entry (and then remove it)Discussions:
ServiceRegistry::find("Foo", Wildcard, [] (auto& serviceDescription) { })
APIServiceDescription::isValid()
be avoided?ManyToManyPolicy
is used, would a user be interested in the number of offers? This is stored in theServiceRegistry
asServiceDescriptionEntry::referenceCounter
but currently not passed up to the user API.Does theMoved to RefactorServiceRegistry
belong toroudi
orruntime
? Somehow, it sits in-between, currently it is insource/roudi/service_registry.cpp
ServiceDiscovery
#1200Stretch goals:
Naming of the CaPro ID members, consider comment from @ithierMoved to RefactorServiceDiscovery
#1200Storage of IDs in service registry and ports (short IDs that are references to the string-based IDs, dictionary)Moved to RefactorServiceDiscovery
#1200Decision on whether to remove wildcard in Cyclone DDS gatewayMoved to RefactorServiceDiscovery
#1200FindServiceError::UNABLE_TO_WRITE_TO_ROUDI_CHANNEL
can be removedCaproMessageSubType
can be removedThe text was updated successfully, but these errors were encountered: