design - protocol development guidelines -
We have a design as below and I have to get feedback or protocol guidelines for the following error scenarios.
Layer 1 --------------- | ^ ^ | (1) | (4) | (6) V. | | Remote unit ---------------- --------------- Layer0 ---------------- - (2) ------------------------------- & gt; Layer 0 layer 0 & lt; ---------- ------ (3) ------------------------------- - Layer0 Layer0 & lt; ------ ---------- (5) ------------------------------- - Layer0 1. New session Request for remote unit 2. Install link + data (session request) 3. Link installation is ongoing 4. Link installation pending 5. Link installed + data (approved session) 6. Session approved
If layer 1 decides that it does not require the service of remote institutions between steps 4 and 6. That is, Event 4 has been received and Event 6 has not yet been received due to some error.
>1) Should it wait for event 6 and should start the session release or 2) Layer 1 should give instructions to layer 0 to immediately end the connection installation process.
Which is the right way? There will be a problem with
(1), even though we know that we are going to end the session due to an error, we have to handle other events before event 6.
I am a fan of the design as soon as you know that you can not continue, Should and should be left.
If for some reason you need to verify that on the other side you have received a message to leave, then I would like to answer or request a message with a UNABLE_TO_COMPLY
The problem is that you can get it in half-open state.
There is a way to handle a situation where instead of sending unsuccessful messages to other requests, other requests are stuck waiting for the response, instead of processing the requests in the order that the priority queue receives, you Indicate that some messages are processed instantly whenever no one is received. High priority messages are placed in front of the queue, so the quit_on_failure
events are not blocked by other requests that you know you can not actually process.
(Because the time period that the developer is choosing for all situations is never accurate), but for these types of protocols, you often have to define the worst situation where your Failed
messages. In these situations, a configurable time-out is usually the only way to clean. Timeout should always be the last resort, never.
Comments
Post a Comment