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.

[nomis52]

Bump.

This problem appears to be getting worse as more responders become available. What are the plans to address it?

I'm writing RDM test cases now and according to the standard, a device which responds with an ack timer but doesn't implement QUEUED_MESSAGE is in violation of the standard and will be marked as failing the tests

Simon

[sblair]

It's an area where there has been long standing disagreement between folks on how it should work and what should and shouldn't be mandated.

My view is that everyone should implement QUEUED_MESSAGES, particularly if they are going to use ACK_TIMER messages. I know my view is not shared by Peter though.

Until there is general agreement between everyone, I don't see much changing with the current situation sadly.

[hamish]

I see where Peter is coming from, however, as I understand the standard at present, I would agree with Simon.

My view is that there are four categories of interpretation of the standard.

1. ERROR.
It is deviant from the standard and will cause interoperability issues, IE, this issue.

2. WARINING.
It is deveiant from the standard but should have minimal impact on operability, IE declaring a mandatory parameter.

3. ADVISORY
It is not covered by the standard but is likley to cause problems, IE a sensor temperature out side of the stated scale range.

4. COMPLIANT

On Peters proposal, an alternative ACK would be required, however, I wouldn't want to confuse that point with the issue of complinace.

As discussed at large at the last CPWG, a universal test standard has to be the way forwards. Anything that brings up a category 1 result should be declaired incompatible.

[nomis52]

Scott: I agree with this view. I know Eric does as well so it looks like the majority support this.

Originally Posted by hamish

My view is that there are four categories of interpretation of the standard.

1. ERROR.
It is deviant from the standard and will cause interoperability issues, IE, this issue.

2. WARINING.
It is deveiant from the standard but should have minimal impact on operability, IE declaring a mandatory parameter.

3. ADVISORY
It is not covered by the standard but is likley to cause problems, IE a sensor temperature out side of the stated scale range.

4. COMPLIANT

On Peters proposal, an alternative ACK would be required, however, I wouldn't want to confuse that point with the issue of complinace.

As discussed at large at the last CPWG, a universal test standard has to be the way forwards. Anything that brings up a category 1 result should be declaired incompatible.

Ok, I'll go forward with my interpretation. At the moment the test framework just has ERROR & WARNINGS and I've put all deviations (no matter how minor) from the standard into the ERROR category. We can discuss this more in Dallas and I can split it out if people think it's worthwhile.

[sblair]

Simon, thanks for all your hard work on this project! Looks forward to seeing you in a couple weeks.

[nomis52]

Originally Posted by nomis52

At the moment the test framework just has ERROR & WARNINGS and I've put all deviations (no matter how minor) from the standard into the ERROR category. We can discuss this more in Dallas and I can split it out if people think it's worthwhile.

I've gone ahead and added ADVISORY messages. You can read more about the entire test framework here: http://opendmx.net/index.php/Writing...esponder_Tests