First rewrite of the uSubscription spec #238
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sophokles73
reviewed
Sep 24, 2024
Comment on lines
+29
to
+31
| - link:../../../basics/uri.adoc[unified addressing] scheme | ||
| - link:../../../up-l2/dispatchers/README.adoc[message forwarding] between different pub-sub domains | ||
| - link:../../udiscovery/v3/README.adoc[discoverability] of available publishers/publications |
There was a problem hiding this comment.
these should better use the xref macro instead of the link macro (https://docs.asciidoctor.org/asciidoc/latest/macros/link-macro/#when-to-use-the-link-macro)
| - link:../../../up-l2/dispatchers/README.adoc[message forwarding] between different pub-sub domains | ||
| - link:../../udiscovery/v3/README.adoc[discoverability] of available publishers/publications | ||
| - cross-system tracking of subscriptions, especially to/from remote systems (this specification) | ||
| - option for link:../../utwin/v2/README.adoc[local caching and temporally decoupled access] to published data |
|
|
||
| In a distributed pubsub network, there exist two subscription scenarios: local subscriptions and remote subscriptions. | ||
|
|
||
| A local subscription is the conventional case where a subscriber requests a message from a publisher on the same transport network, both parties using the same pubsub implementation. For instance, imagine a MQTT broker used by publishers and subscribers, all deployed within the same system context. |
There was a problem hiding this comment.
Suggested change
| A local subscription is the conventional case where a subscriber requests a message from a publisher on the same transport network, both parties using the same pubsub implementation. For instance, imagine a MQTT broker used by publishers and subscribers, all deployed within the same system context. | |
| In the local case a client subscribes to messages published by a uEntity on the same transport network, both parties using the same pubsub implementation. For instance, imagine an MQTT broker used by publishers and subscribers, all deployed within the same system context. |
|
|
||
| A local subscription is the conventional case where a subscriber requests a message from a publisher on the same transport network, both parties using the same pubsub implementation. For instance, imagine a MQTT broker used by publishers and subscribers, all deployed within the same system context. | ||
|
|
||
| In contrast, a remote subscription scenario involves publishers and subscribers using different pubsub implementations and/or being located on different systems. For instance, a client interacting with a co-located MQTT broker to subscribe messages that actucally originate from a low-level mechatronics device, being published via SOME/IP. |
There was a problem hiding this comment.
Suggested change
| In contrast, a remote subscription scenario involves publishers and subscribers using different pubsub implementations and/or being located on different systems. For instance, a client interacting with a co-located MQTT broker to subscribe messages that actucally originate from a low-level mechatronics device, being published via SOME/IP. | |
| In contrast, a remote subscription scenario involves publishers and subscribers using different pubsub implementations and/or being located on different systems. For instance, a client interacting with a co-located MQTT broker to subscribe to messages that originate from a low-level mechatronics device, being published via SOME/IP. |
|
|
||
| In contrast, a remote subscription scenario involves publishers and subscribers using different pubsub implementations and/or being located on different systems. For instance, a client interacting with a co-located MQTT broker to subscribe messages that actucally originate from a low-level mechatronics device, being published via SOME/IP. | ||
|
|
||
| To be workable, the remote subscription scenario requires a dispatcher (`uStreamer`) which is able to forward published messages from one pubsub network to another. To do so intelligently (i.e., only forward traffic that actually is requested by a remote entity), some form of bookkeeping is needed to keep track of local and remote subscriptions, synchronize remote subscription requests with their bookkeeping counterpart on the remote system, and serve as information source for subscription states for the dispatcher entity. |
There was a problem hiding this comment.
Suggested change
| To be workable, the remote subscription scenario requires a dispatcher (`uStreamer`) which is able to forward published messages from one pubsub network to another. To do so intelligently (i.e., only forward traffic that actually is requested by a remote entity), some form of bookkeeping is needed to keep track of local and remote subscriptions, synchronize remote subscription requests with their bookkeeping counterpart on the remote system, and serve as information source for subscription states for the dispatcher entity. | |
| To be workable, the remote subscription scenario requires a dispatcher (`uStreamer`) which is able to forward published messages from one pubsub network to another. To do so intelligently, i.e. only forward traffic that actually is requested by a remote entity, some form of bookkeeping is needed to keep track of local and remote subscriptions, synchronize remote subscription requests with their bookkeeping counterpart on the remote system, and serve as information source for subscription states for the dispatcher entity. |
|
|
||
| [.specitem,oft-sid="req~usubscribe-remote-max-timeout~1",oft-needs="impl"] | ||
| -- | ||
| Remote Subscribe/Unsubscribe requests *MUST* have a maximum timeout of 5 minutes |
There was a problem hiding this comment.
I wonder if we should instead define a minimum time to wait instead ...
|
|
||
| [.specitem,oft-sid="req~usubscribe-remote-retry-indefinitely~1",oft-needs="impl"] | ||
| -- | ||
| Timed-out remote commands *MUST* be retied indefinitely until the business logic behind it no longer requires the command to be sent (ex. the last subscriber calls unsubscribes from a topic that is in state `SUBSCRIPTION_PENDING`). |
There was a problem hiding this comment.
Suggested change
| Timed-out remote commands *MUST* be retied indefinitely until the business logic behind it no longer requires the command to be sent (ex. the last subscriber calls unsubscribes from a topic that is in state `SUBSCRIPTION_PENDING`). | |
| Timed-out remote commands *MUST* be retried indefinitely until the business logic behind it no longer requires the command to be sent (e.g. because the last entity unsubscribed from a topic that is in state `SUBSCRIPTION_PENDING`). |
Comment on lines
+267
to
+269
| -- | ||
| Remote commands *MAY* be retried upon device to device connectivity (link up) and *MAY NOT* be tried when there is no device connectivity (link down). | ||
| -- |
There was a problem hiding this comment.
there is no requirement to meet here ...
| * uSubscription *MUST* change the subscriber to itself (core.usubscription) when subscribing to remote topics, this allows the reverse flow (publication) to be properly multicasted to local subscribers by the local disaptcher (ex. uBus) when it queries the local uSubscription for a list of local subscribers | ||
| To allow the reverse flow (publication) to be properly multicast to local subscribers by the local disaptcher when it queries the local uSubscription for a list of local subscribers: | ||
|
|
||
| [.specitem,oft-sid="req~usubscribe-remote_subscribe-subscriber-change~1",oft-needs="impl,utest"] |
|
|
||
| [.specitem,oft-sid="req~usubscribe-remote_unsubscribe-subscriber-change~1",oft-needs="impl,utest"] |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Restructuring and partial rewrite of this spec; specific focus on: