E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDMnet (E1.33) General Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=22)
-   -   E1-37-7 ENDPOINT_LIST and ENDPOINT_RESPONDERS parsing (http://www.rdmprotocol.org/forums/showthread.php?t=1305)

Fraser Connollly January 8th, 2020 10:22 AM

E1-37-7 ENDPOINT_LIST and ENDPOINT_RESPONDERS parsing
 
I'm struggling a wee bit to modify my RDM parser to support ENDPOINT_LIST and ENDPOINT_RESPONDERS from E1.37-7 as these two PIDs are the only ones in all of the published RDM standards which have different payloads depending on whether they are the first in a series of ACK_OVERFLOW or not.

Could someone please double check for me that I've read this right. There is no reliable way to parse these replies on their own, you need to know the whole ACK/ACK_OVERFLOW process. This will be a nightmare for whoever ends up writing the packet dissector won't it? Especially in an E1.20 environment.

Also the minimum PDL value is a bit confusing for ENDPOINT_LIST as the standard says it 0x07 but that's only true for first in a series. For all others it's only 0x03.

Has anyone else had issues with this? Any tips would be appreciated.

Cheers

-Fraser

ericthegeek January 8th, 2020 09:46 PM

Yes, this is new payload structure for RDM.

Up until this point all of the responses that could generate an ACK_OVERFLOW consisted of a single repeating data structure without any header.

ENDPOINT_LIST and ENDPOINT_RESPONDERS now have a header, followed by a repeating data structure. This is different, and (as you say) complicates parsing.


The latest public-review draft of E1.37-5 also has at least one PID with a similar structure.


However, it's always been a good idea for the controller to receive and reassemble all of the packets in an ACK_OVERFLOW sequence before parsing the responses. Most responders would split the responses between records, but that's not actually required anywhere in the standard.

It's valid for a responder to split a long response partway through one of the repeating data structures. For example, with PROXIED_DEVICES, you could have the first 4 bytes of a UID in the one packet and the last 2 bytes in the next packet.

In My Personal Opinion splitting one record across two packets is a bad idea, and I strongly discourage it. But it can happen, and responders should be able to handle it.


All times are GMT -6. The time now is 09:49 AM.

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