Re: Time outs and state machines

Leslie Sanford wrote:
I have a state machine that sends messages to an external device. After sending each message, the state machine waits for 20 milliseconds. If it has not received an acknowledgment (ACK) from the receiving device when the 20 milliseconds have elapsed, it assumes a non-handshaking mode and sends the next message. On the other hand, if it does receive an acknowledgment before the 20 milliseconds have elapsed, it sends the next message immediately.

What is it you are trying to achieve with this protocol? For example, you may know it will take somewhat less than 20 ms to handle a single message, but that some messages can be handled much faster. This approach could increase throughput. Or, you could be worried that missing an ACK would shutdown the entire channel and by waiting 20 ms to send the next message, you might be able to keep going. Or, it could be something else.

What do you expect is the likelihood that an ACK will be missed? Is is an expected occurrence or does it represent an error?

The way I have implemented this is to have a timer that sends a one-shot timer event when the specified interval has elapsed, in this case 20 milliseconds. If the state machine receives an acknowledgement from the receiving device before the timer event has elapsed, it stops the timer, sends the message, and starts the timer again to begin the whole process all over again, i.e. send message wait for ACK, etc...

There is a scenario that's probably rare but it's bothering me. Suppose the receiving device sends an ACK message just before the timer elapsed event. The ACK message gets put on the queue and immediately after the timer event places its message on the queue as well. The state machine consumes the ACK message. The next message in the queue is the timer event. When the state machine consumes it, it believes that the 20 milliseconds for the last message have elapsed when in fact they have not.

What happens then? Is a message lost? What happens if it is? Missing an ACK is often a good indication that a message was missed, yet you don't sound worried about that. Should you worry about sending two closely spaced messages?

I'm not sure what I'm missing, but I'd like my code to me more robust than this. Is there an additional state that would prevent the above scenerio? I was thinking about giving each timer event a unique ID as one approach. When the state machine consumes a timer event, the ID must be valid for the next message or it is ignored.

The ID approach is good and will work for the mechanism you have described. I would use a sequential message number for the ID so all I would have to do is make sure the message ready to send has an ID one greater than the ACK I have just received.

What is more fundamental to the design is why you are taking this approach in the first place. Hopefully thinking about the above questions will help.

Regards,

Bob Oliver
.

Relevant Pages

  • Re: Time outs and state machines
    ... the state machine waits for 20 milliseconds. ... receiving device before the timer event has elapsed, it stops the timer, ... all over again, i.e. send message wait for ACK, etc... ...
    (comp.object)
  • Re: Time outs and state machines
    ... The ACK message gets put on the queue and immediately after the timer event places its message on the queue as well. ... When the state machine consumes it, it believes that the 20 milliseconds for the last message have elapsed when in fact they have not. ... Waiting Patiently | Processed ACK | Processed Timeout ...
    (comp.object)
  • Re: Time outs and state machines
    ... the state machine waits for 20 ... If it has not received an acknowledgment from the ... whether or not the receiving device implements handshaking. ... one-shot timer event when the specified interval has elapsed, ...
    (comp.object)