search

DelfiSpace / DelfiPQcore

0 stars 1 forks source link

SoftwareUpdateService error messages #35

Open StefanoSperetta opened 4 years ago

StefanoSperetta commented 4 years ago

After implementing some commands in the XTCE file, I realized the responses from the SoftwareUpdateService are making the GS packet processing a bit tricky. We have 2 responses (response and error) but they have a different structure. Errors have an extra field for error type (which can also say success by passing a 0 error code).

What about always using the reply message with the error code and if the error code is non-zero then it is an error?

Main rationale for this is trying to make messages more homogenous. The other thing could also be to try and use the error code for "syntax" issues such that all error messages would be identical. This way the error return code could be used for malformed messages only and then services have one single response (response). This should not cost extra code in the services.

What do you think @CasperBroekhuizen ?

StefanoSperetta commented 4 years ago

One extra comment: in the service, responses to messages are COMMAND_REPLY and COMMAND_ERROR: I would use the generic SERVICE_RESPONSE_REPLY to make sure this is "searchable"

CasperBroekhuizen commented 4 years ago

I don't know if always using the reply (instead of the error commandtype) would cause much changes in other services, since I then would argue that you should always reply with some sort of status code to double check everything is working correctly.

Adding the status code after the reply command (0 - no error) in order to make the commands more homogeneous (they will have the same size) is very doable.

I will replace the Command_reply/Command_error with the generic type.

The OTA is due for a cleanup, I wanted to stress test the service a bit before making more changes in order to make sure its functional.