View Single Post
Old August 19th, 2011   #5
Task Group Member
Join Date: Aug 2008
Posts: 373

Originally Posted by eldoMS View Post
Such a device can indeed store some or even many SET requests but at some point it can lead to an overrun in some practical device, that is the case I meant to be referring to also.
One option when this occurs is for the proxy to queue up a response with a NACK:NR_PROXY_BUFFER_FULL. For example, if you've gotten too many Broadcast SET FACTORY_DEFAULTS, you can queue up a SET_RESPONSE FACTORY_DEFAULTS NACK:NR_PROXY_BUFFER_FULL. This gives the controller a way to know that the proxy has overflowed.

Fortunately, assuming a reasonable buffer size in the proxy, these conditions are unlikely to occur in the real world. The fraction of broadcast packets in most RDM systems is relatively small. It's quite rare to see more than a handful of broadcast requests back-to-back.

I mostly see broadcast used for:

The first two are only for discovery, and since proxies handle discovery on behalf of their proxied devices these can be handled immediately in the proxy and don't need to be queued.

You may see a Broadcast IDENTIFY OFF sent 3 or 4 times back-to-back by a controller (to mitigate lost or corrupt packets), but you won't see hundreds at once.

Originally Posted by eldoMS View Post
With regards to the 10 to 20 ms back-off as Eric is suggesting in practice for a controller to handle the overrun issues, are there plans on integrating in the standard a number as a suggested spec for this, or somehow a way informing a controller on responder capabilities on this point?
The is really an implementation-specific decision. A wired proxy may need 10ms, but a wireless proxy could require 100ms or more. Whatever value got written into the standard, some would say it's too long, and some too short.

Anyone who's designing a controller that makes heavy use of broadcast packets will need to consider the real-world behavior of proxies. Fortunately, other than test equipment, this kind behavior is very rare.
ericthegeek is offline   Reply With Quote