Open JakubLedworowski opened 1 year ago
@JakubLedworowski , please review the sample PR https://github.com/DMTF/libspdm/pull/2405, to see if that API meets your requirement.
@JakubLedworowski , please try the sample PR https://github.com/DMTF/libspdm/pull/2406, to see if that API meets your requirement.
Current libspdm architecture
Current architecture of libspdm requires providing callback functions for sending and receiving messages (see libspdm_register_device_io_func ). Such approach is sufficient for a client application that calls libspdm library, because the client application is the "caller" (or "initiator") of the SPDM flow.
New business case
There is a different business use case, where it is the cloud service (for example REST API service) that is using libspdm but the "caller" (or "initiator") of the flow is a network client calling REST API.
Problem statement
At least three problems arise in such situation:
Proposed solution
Proposed solution to all of those problems is splitting the existing APIs, like
libspdm_get_version
,libspdm_get_measurement
, etc. to separately invoke sending message and handling received response, but maintaining backward compatibility to existing implementation, i.e.:In this way, current implementors would still call one method
libspdm_get_measurement(...)
which would perform both send message and handle response, but at the same time allowing to calllibspdm_get_measurement_send_message
separately fromlibspdm_get_measurement_handle_response
.This would enable multiple instances of REST API service to share SPDM connection only by sharing SPDM context.
All slides explaining the problem and solution can be found in the attached presentation: libspdm_SPDM_API_split_proposal.pdf