Phases of Request / Response Handling #453
Replies: 4 comments
-
|
This would also help deal with state resilience with half-calculated results when we encounter error. This way, we only update the state if we know the response is valid, and would limit the complexity of rolling back any state update when error has occurred. |
Beta Was this translation helpful? Give feedback.
-
|
Good idea |
Beta Was this translation helpful? Give feedback.
-
|
For Requester Case: |
Beta Was this translation helpful? Give feedback.
-
|
Resurrecting this discussion. I have an internal request for this functionality and before we charge forth with any changes I'm curious if any steps have been taken by other libspdm users, either in private or internal forks, towards this goal (whether fully to Steven's description or just at the request/response handling level.) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Looking at how libspdm handles requests and responses, there is a consistent pattern in the flow.
For a Requester:
For a Responder:
Right now most of these phases reside in a single monolithic function. I'd like to see them brought out into individual functions. This would make clear the ownership and identification of a phase and aid in debugging. So for example a request would look something like:
Beta Was this translation helpful? Give feedback.
All reactions