View Single Post
Old September 5th, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote