ALP layer: unsolicited commands are sent back in the response

[sjorsdewit]

Current implementation

process_async() parses incoming ALP actions and builds a response. If the ALP data contains ALP_OP_RETURN_FILE_DATA, this is copied to the response and the response is marked as 'unsolicited'. The response is then passed to the app callback via transmit_response_to_app(). The app may then handle the unsolicited data before the response is sent.

Unhandled data is echoed back

Any item that is not explicitly handled by the app remains in the fifo and is sent out as part of the response: apps must handle them, ortherwise they message is simply repeated back to the sender. I think that is not as intended?

Differentiating between unsolicited ALP_OP_RETURN_FILE_DATA and response to incoming ALP_OP_READ_FILE_DATA

What makes parsing from the callback extra tricky is that you can't just pop everything from the queue: anything that is popped and is not an unsolicited response is then missing from the response. What makes this especially difficult is that incoming ALP_OP_READ_FILE_DATA is parsed and translated into ALP_OP_RETURN_FILE_DATA before the callback is called.

It seems there is no way to know whether an ALP_OP_RETURN_FILE_DATA command is an incoming unsolicited request (that must be handled) or a response to an incoming ALP_OP_READ_FILE_DATA (that must not be handled since the framework has already done so).

Example

A client sends an ALP command consisting of two actions:

alp_append_return_file_data_action(command, FILE_ID_TO_SEND, 0, sizeof(to_send), (uint8_t*)&to_send);
alp_append_read_file_data_action(command, FILE_ID_TO_REQUEST, 0, 8, false, false);

The receiver then receives this data, parses the READ_FILE_DATA action into a RETURN_FILE_DATA response and calls the application callback alp_command_result_cb.

The application then sees two ALP_OP_RETURN_FILE_DATA actions. In case FILE_ID_TO_SEND and FILE_ID_TO_REQUEST are the same, the application cannot determine if the action must be parsed or must not be parsed..

[glennergeerts]

Thanks for the detailed issue description. We will look into this and come to back to you with a proposal.