How to integrate our own transport layer

[evshary]

Hi, After studying uprocotol-spec, I still can't fully understand some points about uProtocol.

1. Is there any example application using uProtocol now? I'm just curious how the uProtocol API looks like when I want to do discovery/subscription or something else. It would be good to have a reference.
2. If I want to implement our own transport with uProtocol, then what should we do? Implement ulink by ourselves? I saw uprotocol-python-ulink-zenoh. Does that mean you're already working on putting Zenoh into uProtocol?
3. I saw there is a branch about SOME/IP bridge. I'm curious about the architecture here. I'm a little confused. Does that mean uProtocol bridge is used to bridge uDevice to other devices using SOME/IP natively? If there are two uDevice and I want them to communicate with each other, is it possible to use SOME/IP Bridge on both sides and make them talk to each other? Something like this:

flowchart LR
    uD1["uDevice 1"]
    uD2["uDevice 2"]
    b1["SOME/IP bridge"]
    b2["SOME/IP bridge"]
    uD1 -->|uProtocol| b1
    b1 -->|SOME/IP| b2
    b2 -->|uProtocol| uD2

Hope you don't think these questions are a little bit silly. They bothered me for quite a while.

[stevenhartley]

Hi @evshary ,

1. We are working on open sourcing an example apps and services as well the mock uServices (now open sourced to Eclipse) that should make it clearer how to use uSubscription, ETA end of the year.
2. Yes we are working on open sourcing Binder (for Android) and Zenoh based transports in partnership with Zettascale (for Zenoh). Zenoh will be implemented for rust, C++, Java, and python. Once we figure out the optimal "wire format" for sending UAttributes & UPayload, we'll document that in uprotocol-spec as well (WiP)
3. SOME/IP is special case. The bridge design was to map the mechatronics (pure AUTOSAR classic world) to the non-mechatronics high compute world of anything. Furthermore, SOME/IP has its own service discovery protocol built in and it is mainly designed for the classic to adaptive bridge using IP multicast while then using unix domain sockets for fanning out locally (see vsomeip for more details). We are still evaluating the most optimal way to bridge the mechatronic world, once the bridge (or uTransport) is worked out, we'll share as well since this is critical to the success of uProtocol.

For your diagram, either SOME/IP is merely a dumb pipe (and nothing more) or choose a different protocol between uDevice1 and uDevice2, like zenoh, MQTT, DDS, HTTP, etc... (depending on the ASIL requirements and such).

[evshary]

Yes we are working on open sourcing Binder (for Android) and Zenoh based transports in partnership with Zettascale (for Zenoh).

Yes, I suppose I would be one of the people who work on this project together (Luca told me). Therefore, I'm trying to read the uprotocol-spec first.

Zenoh will be implemented for rust, C++, Java, and python.

Let me make sure I get it right: Now we have uprotocol-rust, uprotocol-cpp, uprotocol-java and uprotocol-python. We need to implement uprotocol-rust-ulink-zenoh, uprotocol-cpp-ulink-zenoh, uprotocol-java-ulink-zenoh, and uprotocol-python-ulink-zenoh respectively to support Rust, C++, Java, and Python. Am I correct?

SOME/IP is special case

Okay, I guess I confused uTransport with bridge. Bridge is used to communicate with other devices using native protocol, such as SOME/IP. For uTransport, we can choose one of the protocols (Zenoh, DDS, MQTT..) to make different uDevice speak to each other. I think this is similar with the concept like ROS 2 uses DDS as its communication layer, right?

flowchart LR
    uD1["uDevice 1"]
    uD2["uDevice 2"]
    uT1["uTransport"]
    uT2["uTransport"]
    uD1 --> uT1
    uT1 -->|Zenoh| uT2
    uT2 --> uD2

    uD3["uDevice 3"]
    uD4["uDevice 4"]
    uT3["uTransport"]
    uT4["uTransport"]
    uD3 --> uT3
    uT3 -->|DDS| uT4
    uT4 --> uD4

    uD5["uDevice 5"]
    uD6["uDevice 6"]
    uT5["uTransport"]
    uT6["uTransport"]
    uD5 --> uT5
    uT5 -->|MQTT| uT6
    uT6 --> uD6

[stevenhartley]

Happy to know you'll be helping out, thanks!

Main purpose of uTransport is to enable L1 communication between uEs OR between devices (so more than what you show in your diagram). In the case of Zenoh, it will be used to talk to zenoh uEs (a wrapper around your publisher/subscriber etc... libraries).

Streamers as a specialized form of dispatchers (uP-L2), responsible for bridging transports (amongst other things), this is not implemented in the ulink libraries but in the uPlatform. In a Zenoh transport world, the zenoh router implements the streamer and the bridge to other transports (like SOME/IP) are your router plugins.

What we need to conclude on is the common "wire format", i.e. how UUri/UAttributes/UPayload shall be mapped to zenoh header & zenoh payloads, this is something we are talking with Luca and others now, and I'll capture in up-l1/zenoh.adoc that will be added to uprotocol-spec. This needs to be specified so that all language and implementations of zenoh based uTransports are interroperable with each other (i.e python, C++, java, proprietary implementations, etc...).

[evshary]

Thank you @stevenhartley Very detailed explanation. It's clear to me now!