-
Notifications
You must be signed in to change notification settings - Fork 207
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
Labels
Comments
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.
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
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 theMsgId
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-inMsgId
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.
The text was updated successfully, but these errors were encountered: