E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Correctly handling ACK_OVERFLOW (http://www.rdmprotocol.org/forums/showthread.php?t=1074)

nomis52 September 5th, 2010 03:09 PM

Correctly handling ACK_OVERFLOW
 
What's the correct behavior for this? The standard says "the controller should continue to send get commands for the same PID" but mentions nothing about what the PD field should contain.

Does that mean the PD and PDL fields should remain identical to the first message or can I send no data for the subsequent get commands?

For the two examples in the spec (proxied devices and supported parameters) it doesn't matter because the PDL is always 0 but I can imagine a case where the PD contained data specific to the GET request.

Thanks,

Simon

prwatE120 September 5th, 2010 04:07 PM

Simon

It is a very good question - and as the standard does not explicity state anything, a responder would be best advised to cope with either case.

It seems preferable that if the initial GET had a payload (and thus the PDL != 0), this should be repeated in all subsequent GETs until the responder stops replying with the ACK_OVERFLOW.

This needs to be documented in the next erratta.

Peter

nomis52 September 5th, 2010 04:30 PM

Quote:

Originally Posted by prwatE120 (Post 2055)
Simon

It seems preferable that if the initial GET had a payload (and thus the PDL != 0), this should be repeated in all subsequent GETs until the responder stops replying with the ACK_OVERFLOW.

This needs to be documented in the next erratta.

Peter

Thanks, that's what I expected. Is there a bug list for open issues where these things are tracked or do people just remember to bring them up at the next meeting?

nomis52 September 5th, 2010 05:05 PM

Here's a related problem: The standard states "The responder shall abort a partial transfer of overflow data for a PID when receiving a command
for a different PID before the overflow data transfer is complete."

It says nothing however about what happens if the src UID differs. In multi-controller setups like E1.33 we're going to need to be careful to ensure one of the following:

i) other get/set messages can't be interleaved when an ACK_OVERFLOW sequence is occurring on the DMX side
ii) if interleaving is allowed, the responders need to track the transfer status per src UID and only reset if a different PID is received from the same src UID.

I'll have a guess that no one has designed their responders to handle case ii) so I think we'll have to go with i). This means that gateways are going to have to buffer the entire message.

ericthegeek September 5th, 2010 06:59 PM

I think Peter's right. A responder should be able to handle both.

This could make things difficult for the controller. If the controller issues two issue back-to-back PIDs with different Parameter Data, it may be ambiguous what the response contains.

Looking at the PID list in E1.20, there are 6 PIDs that are likely to grow enough that they require an ACK_OVERFLOW
  • PROXIED_DEVICES
  • STATUS_MESSAGES
  • SUPPORTED_PARAMETERS
  • LANGUAGE_CAPABILITIES
  • SLOT_INFO
  • DEFAULT_SLOT_VALUE

The biggest potential culprit here is STATUS_MESSAGES (The others all have a PDL of zero). If the controller changes the "Status Type" field part-way through an ACK_OVERFLOW sequence, there's no telling what it will get. Fortunately in case of STATUS_MESSAGES, the response contains the "Status Type" for each of the status reports which should eliminate the ambiguity.

This is probably more of an issue for MFG specific PIDs.

> Is there a bug list for open issues where these
> things are tracked or do people just remember
> to bring them up at the next meeting?

In the past, we've gone through old forum threads before re-opening the document for editing. I think Scott also keeps an errata list.

> It says nothing however about what happens
> if the src UID differs. In multi-controller setups
> like E1.33 we're going to need to be careful to
> ensure one of the following:

This a big part of the reason I don't like E1.33 being multi-controller: It makes ACK_OVERFLOW handling much more complicated. But, multi-controller is highly desirable from an end-use standpoint, so I think the E1.33 gateway will have to initiate the entire overflow sequence on the DMX side, and buffer it for the IP side.

The only other option I can see would be for the E1.33 controllers to all collaborate to make sure ACK_OVERFLOWs are never interleaved, perhaps with a token-ring style "permission to talk" message. For a variety of reasons, I don't think this is practical.

During E1.20 development, there was a lot of discussion of how a responder should handle a change in the controller's UID. We could never reach a consensus. Some felt it should be ignored. Others wanted the responder to un-mute and reset several other protocol elements. In the end it was left un-defined.

sblair September 5th, 2010 08:20 PM

I agree with Peter and Eric's comments on the issues you raised.

On the errata side, as Eric mentioned I go back through and scrub all the discussions for errata issues whenever we re-open the doc. I also have a doc that I list them in as they come up in our meetings too.

Originally with the MUTE flag we had the devices clear the flag when they saw a change in Source ID. That proved to create an enormous mess, so the devices should generally be completely agnostic to the Source ID. The issue you raised about them getting interleaved in E1.33 is a valid one and something we will need to address in it.

ericthegeek September 6th, 2010 12:53 PM

Thinking about this a bit more, it's not clear if STATUS_MESSAGES should ever use ACK_OVERFLOW in the first place. Multiple status responses are packed into a single packet. But, STATUS_MESSAGES has its own queuing mechanism, so if you have more status conditions to report than will fit into a single response, you can use that queuing mechanism to get the additional statuses.

Again, a controller should probably handle both, but I'd argue a responder shouldn't generate ACK_OVERFLOWs for STATUS_MESSAGES responses.

nomis52 September 6th, 2010 04:54 PM

Eric and I did a bit of testing with an ArtNet node yesterday. I've documented the behavior at http://opendmx.net/index.php/ArtNet,...t_Interleaving

nomis52 September 6th, 2010 04:55 PM

Quote:

Originally Posted by ericthegeek (Post 2060)
Again, a controller should probably handle both, but I'd argue a responder shouldn't generate ACK_OVERFLOWs for STATUS_MESSAGES responses.

Agreed, when's the next revision due out :) ?

sblair September 6th, 2010 05:47 PM

Quote:

Originally Posted by nomis52 (Post 2062)
Agreed, when's the next revision due out :) ?

I'm still working on getting the last rev released!

hamish January 28th, 2011 04:10 AM

The time has come.
 
It has now become apparent that I will have to implement ACK_TIMER for FW upload over RDM, ug.

This post is just to report a minor documentation detail 6.3.3 Page -28- ACK_TIMER response (PD) = 0x00000258.
This is a 16 bit field...

sblair January 28th, 2011 03:49 PM

Hamish,

That error in the example has already been fixed in the soon-to-be-published-almost-any-day-now errata.

Also bulk data transfers can be accomplished without using ACK_OVERFLOW. I know that came up in discussion over the weekend. It can also be done without ACK_TIMER unless you're having timing issues where you need to be able to go away for a while.

I can send you a draft version of the Bulk Data Transfer document that we abandoned. It might at least give you some useful concepts/model to use.

Scott

hamish January 29th, 2011 06:05 AM

Scott

Just to confirm, this is a 16 bit timer value?
I think I may have posted in the wrong thread here, it was ACK_TIMER that I had in mind.
On the upload front, it is going to be done in pages, so no requirement for the ACK_OVERFLOW.
As I see it at the moment, I will not be able to avoid the ACK_TIMER during the re-configure process.

As this is going off topic for this thread, I'll start a new one when I make some headway. Meanwhile, anything you have to throw into the melting pot would always be appreciated.

ericthegeek January 29th, 2011 09:25 PM

Yes. Ack timer gets a 16bit value in tenths of a second.


All times are GMT -6. The time now is 03:33 PM.

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