E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDMnet (E1.33) General Discussion

RDMnet (E1.33) General Discussion General Discussion and questions concerning the E1.33 standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 8th, 2020   #1
Fraser Connollly
Junior Member
 
Join Date: Dec 2019
Location: Glasgow
Posts: 3
Default 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

Last edited by Fraser Connollly; January 8th, 2020 at 02:25 PM. Reason: Corrected a false assumption.
Fraser Connollly is offline   Reply With Quote
Old January 8th, 2020   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

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

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 05:01 AM.


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