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.

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

Add source-routing feature to Software Bus #2362

Open
jphickey opened this issue May 31, 2023 · 0 comments · May be fixed by #2367
Open

Add source-routing feature to Software Bus #2362

jphickey opened this issue May 31, 2023 · 0 comments · May be fixed by #2367
Assignees

Comments

@jphickey
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Normally, software bus messages are fully assembled by clients, then passed to the software bus via e.g. CFE_SB_TransmitMsg() for delivery to subscribers. This routing to subscribers is currently done based on the MsgId value that is present in the message - that is, the MsgId is looked up in the routing table, which is in turn translated to a list of destinations (subscribers) to deliver that message to.

Describe the solution you'd like
Add an alternative API that allows the message to be routed to destination(s) that are are given explicitly in the API call. That is, allow the caller to specify the MsgId that SB should use to route and deliver the message. Specifically - this passed-in MsgId for routing may be different than the MsgId value contained in the message.

Describe alternatives you've considered
N/A

Additional context
The use-case for this feature has to do with complex systems with distributed software bus services across many instances of CFE. In this context the destination may not be directly reachable from the source, but reachable through some sort of intermediate hop. This feature gives the needed flexibility to work with such an architecture, by allowing messages to be routed to an intermediate delivery assistant app that may not be the final destination of the message.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this May 31, 2023
jphickey added a commit to jphickey/cFE that referenced this issue Jun 1, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
@jphickey jphickey linked a pull request Jun 1, 2023 that will close this issue
2 tasks
jphickey added a commit to jphickey/cFE that referenced this issue Jun 2, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
jphickey added a commit to jphickey/cFE that referenced this issue Jun 2, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
jphickey added a commit to jphickey/cFE that referenced this issue Jun 2, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
jphickey added a commit to jphickey/cFE that referenced this issue Jun 2, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
jphickey added a commit to jphickey/cFE that referenced this issue Jun 5, 2023
Add two new APIs that allow more control over the message routing.
These allow the caller to directly specify the route (MsgId) and size of
the content, and the message will be delivered based on the passed in
values vs. the values inside the message itself.

This restructures the existing/historical API calls to use the same
underlying mechanism.  Send/Receive actions have a transaction object
associated and this tracks the status and events.  Common event
reporting is done based on this transaction object.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant