E1-37-7 ENDPOINT_LIST and ENDPOINT_RESPONDERS parsing - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · January 8th, 2020

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.

January 8th, 2020	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	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.