Current documentation of ReceptionStatus can quickly lead to dead locks

[lfse-slafleur]

The current mechanism for sending feedback regarding a message is to send a ReceptionStatus. This is simple, an example:

• Assume there is RM A and CEM B.
• RM A sends a ResourceManagerDetails to CEM B.
• CEM B should respond with a ReceptionStatus to RM A notifying the message was received okay.

However, the specification states that a ReceptionStatus should be send in the following case: Sent immediatly when a message has been received and processed (https://github.com/flexiblepower/s2-ws-json/wiki/Common_messages#receptionstatus) . While the specification has no direct implications for the implementation, this does lead to a possible implicit dependency that is currently allowed by the S2 specification:

• Assume there is RM A and CEM B

1. CEM B sends a HandshakeResponse which contains the selected S2 version and it waits for the ReceptionStatus.
2. RM A receives the HandShakeResponse message, but as part of processing this message it also sends the ResourceManagerDetails to CEM B and waits for its ReceptionStatus.
3. CEM B receives the ResourceManagerDetails from RM A but it is still waiting for the ReceptionStatus from RM A for the HandshakeResponse.
4. RM A is still waiting for the ReceptionStatus of ResourceManagerDetails from CEM B before submitting the ReceptionStatus of the HandshakeResponse.

• Conclusion: dead lock.

The core of this issue is that prior to sending the ReceptionStatus of some message it may depend on the ReceptionStatus of another (later) message.

Specification does not give any explicit directions here so I do see a couple of options but honestly only 1 simple one (the 2nd option:

1. We should allow for this implicit dependency in processing between ReceptionStatus messages. However, then we require that CEM's & RM's do not wait for the ReceptionStatus of prior messages before processing newer messages.
   In relation to the example: The CEM should process the ResourceManagerDetail message even though the ReceptionStatus for the HandshakeResponse message is not yet received. So it should not halt processing during step 3.
   A consequence of this option (and why I wouldn't consider it the preferred option) is this allows a whole conversation to take place e.g. HandshakeResponse -> ResourceManagerDetails -> SelectControlType -> FRBC.SystemDescription without explicitely requiring a ReceptionStatus for the initial HandshakeResponse. Essentially making the ReceptionStatus mecanism optional.

2. We should NOT allow for this implicit dependency and make the purpose of ReceptionStatus more explicit in the documentation. Scope of ReceptionStatus should be kept to receiving the message and ensuring it is congruent (e.g. an InstructionStatus should reference a previously send Instruction) but a ReceptionStatus must not wait on sending/receiving further messages. --> A ReceptionStatus is required for e.g. a HandshakeResponse before the next message (ResourceManagerDetails) should be send. Specifically, we should change the wording of processing of the description of ReceptionStatus to a phrase that captures A ReceptionStatus should be send ASAP after receiving a message, checking it is valid json & S2 and ensuring it is congruent to earlier send messages but it should not wait on receiving other S2 messages before being send. Any message for which a ReceptionStatus is not yet received cannot be assumed to have been properly received by the other end of the connection.
   In relation to the example: The ReceptationStatus for the HandshakeResponse send by CEM B, received by RM A should not depend on sending the ResourceManagerDetails & waiting for its ReceptionStatus. But it should be send immediately after receiving and parsing the HandshakeResponse during step 2.

The difficulty with option 2 is that it may lead to more complex code. We are essentially splitting the 'verification of a message' into 2 parts where one part influences the ReceptionStatus.status and the other part may cause errors/exceptions but it doesn't influence the S2 connection.

Now lets say we choose the 2nd option here. This does lead to another issue. Another example to show case this issue:

• Assume there is RM A and CEM B

1. CEM B sends a HandshakeResponse which contains the selected S2 version and it waits for the ReceptionStatus.
2. RM A receives the HandshakeResponse message. It sends a ReceptionStatus confirming the message was okay.
3. After, something goes wrong at RM A. E.g. it had a database connection and the connection is dropped. There is no way for RM a A to let CEM B know what is going wrong other than dropping the connection as the ReceptionStatus was already send. You could 'abuse' SessionRequest but that message is meant to for the server to request a client to drop the connection or reconnect.

Of course this is a separate discussion, but choosing option 2 also means we may want to extend the current messages with a 'CEM or RM is going to close the connection after this because...' message which may be send whenever by either party prior to terminating the connection.