Correctly handling ACK_OVERFLOW

[nomis52]

Originally Posted by prwatE120

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]

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]

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.