E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old October 14th, 2008   #1
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default ACK_TIMER Handling

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).
ericthegeek is offline   Reply With Quote
Old October 14th, 2008   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old October 14th, 2008   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old December 21st, 2010   #4
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

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
nomis52 is offline   Reply With Quote
Old January 7th, 2011   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 7th, 2011   #6
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default

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.
hamish is offline   Reply With Quote
Old January 7th, 2011   #7
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

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

Quote:
Originally Posted by hamish View Post
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.
nomis52 is offline   Reply With Quote
Old January 7th, 2011   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Simon, thanks for all your hard work on this project! Looks forward to seeing you in a couple weeks.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 20th, 2011   #9
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by nomis52 View Post
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
nomis52 is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ACK_TIMER, QUEUED Messages berntd RDM Interpretation Questions 1 November 12th, 2008 10:02 PM
ACK_TIMER Example Error prwatE120 RDM Interpretation Questions 1 December 26th, 2006 03:46 PM
Request in the middle of ACK_TIMER endoftheworld RDM Interpretation Questions 1 July 13th, 2006 10:53 PM


All times are GMT -6. The time now is 03:23 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.