Discovery process addressing
 

I have come across an interesting discovery behavior that the standard does not appear to address.
The DISCOVER_UNIQUE_BRANCH command is always supposed to be sent to the broadcast address: 0xff ff ff ff ff ff. However, what is supposed to happen if the DISCOVER_UNIQUE_BRANCH is sent to a specific UID as the destination address? This is obviously wrong on the part of the controller, but it is something that the RDM Integrity software does. It sends a discovery command addressed to the specific UID of the responder and it sets the parameter data (upper and lower bounds) for the same UID after it has narrowed things down to the single device. There are three possible routes to take in my mind:
1. Respond with a standard discovery response.
2. Do not respond.
3. Respond with a NACK format error response.
My products take route 2 as I have received an illegal command. I'm open to hearing thoughts from others on how this situation should be addressed.

The general advice I give when dealing with corner cases like this is:
"Don't crash"


It doesn't really matter what the responder does. There's no "correct" response. But it's important that the responder doesn't crash so that it can keep operating when/if a controller generates this condition by mistake.


IMO route 1 and 2 are both good approaches. I'd be wary of #3 because I hesitate to generate a break on the line during the time when other equipment on the wire might be expecting a discovery response.





I do a lot of tests like this when I'm evaluating a responder. Discover to Unicast, Discovery to Vendorcast, discover to sub-devices, etc. These tests help find corner cases in the software. But if the responder stays online (doesn't crash) and is ready for the next packet, the I consider if to have passes the test.

Hey Milton,

I generally try to write very permissive responders so that even if something is not strictly following the standard I can be accepting of it so it doesn't look like the product is broken, even if it is the controllers fault.

So given that, I believe #1 is completely acceptable as it shouldn't break anything.

I will admit in my own implementations #2 is what would have happened in this corner cause because I first check destination addressing and if it isn't a broadcast or my matching UID then I would have stopped parsing the packet.

#3 is absolutely the wrong thing to do. There should never be a NACK to a UNIQ_BRANCH message. As Eric said, this could cause a break on the line or also in the rush of other responders potentially sending NACK's too it would cause corrupted data and trigger the Controller to start going down invalid branches and could potentially break discovery completely.

I'm also investigating Integrity's Discovery Testing behavior. I've just upgraded to the latest version of Integrity (2.0.0.68). I have the Standard E1.20-2010 choice selected, and it's showing an "Advisory" if I respond to my VENDORCAST. Reading the ANSI E1.20-2010, Section 7.5 says "The DISC_UNIQUE_BRANCH message shall always be sent to the ALL_DEVICES_ID UID Address, since all devices must process this message". Appendix A then defines ALL_DEVICES_ID as 0xmmmmFFFFFFFF where 0xmmmm is Specific Manufacturer ID.. so the Standard seems to say VENDORCAST is legitimate for DISC_UNIQUE_BRANCH. Is this a typo in the E1.20-2010 Standard? and.. is best practice to also ignore VENDORCAST when get the DISC_UNIQUE_BRANCH command?

Section 7.5 in -2010 probably should have said BROADCAST_ALL_DEVICES_ID rather than ALL_DEVICES_ID. That was the intent anyway.

I don't think there is a consensus best practice for how to handle vendorcast discovery beyond the “don't crash” advice I gave above.