You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The uStreamer needs the ability to open connections between UAuthority-level, so we must follow along with the uProtocol Zenoh spec:
Note that there is a special case. If the UUri only contains UAuthority with empty UEntity and UResource, it’s defined as a special form of Zenoh key upr/[byte hexadecimal of UAuthority]/**. It can listen to all the messages sending to a certain UAuthority.
Therefore registerListener should be updated to support this use case.
Note how the in the Rust implementation when we realize it's a special UAuthority-only UUri there is a special control path to ensure we register for all message types:
if topic.authority.is_some() && topic.entity.is_none() && topic.resource.is_none(){// This is special UUri which means we need to register for all of Publish, Notification, Request, and Response// RPC responseself.register_response_listener(&topic, listener.clone());// RPC requestself.register_request_listener(&topic, listener.clone()).await?;// Publish & Notificationself.register_publish_notification_listener(&topic, listener.clone()).await?;Ok(())
When I review the C++ implementation, I don't see the same sort of determination performed.
To me it reads like what would happen in the UAuthority-only UUri case we would be in this case:
if (false == isRPCMethod(uri.resource())) {
z_owned_closure_sample_t callback = z_closure(SubHandler, OnSubscriberClose, arg);
auto sub = z_declare_subscriber(z_loan(session_), z_keyexpr(key.c_str()), z_move(callback), nullptr);
if (!z_check(sub)) {
spdlog::error("z_declare_subscriber failed");
status.set_code(UCode::INTERNAL);
break;
}
listenerContainer->subVector_.push_back(sub);
listenerContainer->listenerVector_.push_back(&listener);
In that case, we would be able to receive any type of messages originating from the provided UAuthority.
Issues
Request messages
However, we would not appropriately handle Request messages, as for those we'd need to insert them into the queryMap such that later when we attempt to send a Response message the corresponding Zenoh Query can be located. That's a problem.
Response messages
In addition, it seems like Response may also not be handled correctly? I'll say that in the Rust implementation there's a map kept to be able to refer to later when doing a send() on a Request message to ensure that we have registered a listener for the returned Response message.
The text was updated successfully, but these errors were encountered:
PLeVasseur
changed the title
Support UAuthority-only UUri to support uStreamer use-case
Support UAuthority-only UUri to for uStreamer use-case
Apr 18, 2024
PLeVasseur
changed the title
Support UAuthority-only UUri to for uStreamer use-case
Support UAuthority-only UUri for uStreamer use-case
Apr 18, 2024
The uStreamer needs the ability to open connections between
UAuthority
-level, so we must follow along with the uProtocol Zenoh spec:Therefore registerListener should be updated to support this use case.
An example of how to do this can be found in
up-client-zenoh-rust
.Note how the in the Rust implementation when we realize it's a special
UAuthority
-onlyUUri
there is a special control path to ensure we register for all message types:When I review the C++ implementation, I don't see the same sort of determination performed.
To me it reads like what would happen in the
UAuthority
-onlyUUri
case we would be in this case:In that case, we would be able to receive any type of messages originating from the provided
UAuthority
.Issues
Request messages
However, we would not appropriately handle Request messages, as for those we'd need to insert them into the
queryMap
such that later when we attempt to send a Response message the corresponding Zenoh Query can be located. That's a problem.Response messages
In addition, it seems like Response may also not be handled correctly? I'll say that in the Rust implementation there's a map kept to be able to refer to later when doing a
send()
on a Request message to ensure that we have registered a listener for the returned Response message.The text was updated successfully, but these errors were encountered: