Phases of Request / Response Handling

[steven-bellock]

Looking at how libspdm handles requests and responses, there is a consistent pattern in the flow.

For a Requester:

1. Check that input parameters are legal.
2. Verify that the Requester is in the proper state to construct the request.
3. Construct the request.
4. Send the request.
5. Receive the response.
6. Validate the response.
7. Parse and process the response.
8. Update Requester state.

For a Responder:

1. Check that input parameters are legal.
2. Verify that the Responder is in the proper state to process the request.
3. Receive the request.
4. Validate the request.
5. Parse and process the request.
6. Construct the response.
7. Send the response
8. Update Responder state.

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:

try_spdm_get_measurement (*context,...)
{
   verify_state (*context,...);
   construct_request (*context, *request, ...);
   send_request (*context, *request, ...);
   receive_response (*context, *response, ...);
   validate_response (*context, *response, ...);
   process_response (*context, *response, ...);
   update_state (*context, ...);
}

[taprinz]

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.

[jyao1]

Good idea

[PrithviAPai]

For Requester Case:
It will be helpful if integrator gets flexibility to send request to SPDM endPoint, receive response and call libspdm to handle response. Currently libspdm triggers the receive callback which makes application send and receive the payload in synchronous manner.