ACK_TIMER Handling

[ericthegeek]

There seem to be two different, and largely incompatible, interpretations of ACD_TIMER in the wild.

According to the text of E1.20, after sending an ACK_TIMER, the responder "shall" send the properly formatted response as a queued message after the timeout has elapsed.

But some implementations seem to assume that you can simply resend the same request after the timeout period and expect to get a valid response. Unfortunately, I don't see this behavior called out on the standard anywhere so there's no way to know how a given responder will handle it.

In the second case, what assumptions does the responder make? Is it treated like ACK_OVERFLOW? (With ACK_OVERFLOW you can't send any other PIDs between the first and second requests and if the responder receives any other PID it must reset its parser state).

[prwatE120]

As support for Queued Messages is not mandated, you possibly have to decide based on whether your reponder supports that PID.

I think we need to propose a scheme whereby requests that are initially met by an ACK_TIMER can be serviced by a subsequent request within a known "time to live" period.

You ask for something not immediately available - and are are given an ACK_TIMER xxx. If you ask again within (say) 10 xxx you are handed the requested data. If you ask after that time it is deemed to be stale and yiu get another ACK_TIMER.

And yes, if your responder supports QUEUED_MESSAGES, it can get added to the list of pending messages.

mroe discussion needed ...

Peter Willis

[ericthegeek]

The way I read the document is that a responder that wants to use ACK_TIMER has to support queued messages. If a responder can't support queued messages, then it can't use ACK_TIMER.

Still, there are devices out there that don't do this, so to some extent we're stuck with this behavior. Since it's not defined in the standard, is there a generic way to handle this? What I'd really like to avoid is a situation where the controller has to keep a table of specific device types and how they handle ACK_TIMER.

The worst case is a device that claims to support queued messages, but uses ACK_OVERFLOW style handling of ACK_OVERFLOW. In that case, you have to:

Send Get Lamp Hours
Get the ACK_TIMER
Wait for the timeout
Send get queued messages until you drain everything in the queue.
Determine the device did not queue the appropriate response
Send Get Lamp Hours Again
Wait for the timeout again
Send Get Lamp Hours a third time
Read the response

This is very cumbersome.

I don’t mind the TTL style handling you mention, but I’m afraid adding that to the RDM standard would be outside the scope of the current errata document.

At a minimum, I'd like to document the behaviors that are out there in a public forum. This will help everyone.