Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add the table for listeners to distinguish different message types. #188

Merged
merged 5 commits into from
Jul 17, 2024
Merged

Add the table for listeners to distinguish different message types. #188

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
c9a87c7
Add the table for listeners to distinguish different message types.
evshary Jun 19, 2024
47a9cc6
Move the table to uAttributes.
evshary Jul 2, 2024
c09c9d2
gove the table to up-l1 README.
evshary Jul 3, 2024
51fd6fe
Update the listener table.
evshary Jul 8, 2024
9c9e5e3
Simplify the table for RegisterListener API.
evshary Jul 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions basics/uattributes.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -226,3 +226,39 @@ a|The link:uri.adoc[UUri] that the service consumer expects to receive this resp
== Validation

Each link:../languages.adoc[uProtocol Language Library] *MUST* provide means to assert the consistency of a message's attributes according to its type as defined in the sections above. The concrete implementation should follow common practices of the particular programming language.


== Listeners for different message types
evshary marked this conversation as resolved.
Show resolved Hide resolved

In uTransport listener API, we only have the `resource_id`` of the source and sink.
However, sometimes it's necessary to distinguish the message types which should be listened to.

Here is the table to map the various combination of source `resource_id` and sink `resource_id` to different message types.

[%autowidth]
|===
| src resource_id | sink resource_id | Publish | Notification | Request | Response

| [8000-FFFE] | None | V | | |
| [8000-FFFE] | 0 | | V | |
| 0 | [1-7FFF] | | | V |
| [1-7FFF] | 0 | | | | V
| FFFF | 0 | | V | | V
| FFFF | [1-7FFF] | | | V |
| 0 | FFFF | | | V |
| [1-7FFF] | FFFF | | | | V
| [8000-FFFE] | FFFF | | V | |
| FFFF | FFFF | | V | V | V
|===

These can be reorganized as:

[%autowidth]
|===
| Message Type | Possible resource_id combinations {src_resource_id, sink_resource_id}

| Publish | {[8000-FFFE], None}
| Notification | {[8000-FFFE], 0}, {[8000-FFFE], FFFF}, {FFFF, 0}, {FFFF, FFFF}
| Request | {0, [1-7FFF]}, {0, FFFF}, {FFFF, [1-7FFF]}, {FFFF, FFFF}
| Response | {[1-7FFF], 0}, {[1-7FFF], FFFF}, (FFFF, 0), {FFFF, FFFF}
|===