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.

Thread Tools Search this Thread Display Modes
Old February 18th, 2021   #1
Junior Member
Join Date: Feb 2021
Posts: 2
Exclamation RDMnet gateway implementation difficulties

Hello Everyone!

My name is Matteo and I've been working at City Theatrical for about 5 years.
We are currently in the process of making our Multiverse Transmitter compatible with E1.33
So far the process was quite smooth, but I have run into a problem that I can't see a solution for.
This is my scenario:

RDMnet Controller and Broker running on my computer. Multiverse Transmitter connected to my computer over ethernet.
I'm using ETC's RDMnet github code for the controller and the broker (https://etclabs.github.io/RDMnet)
Our Multiverse Transmitter is acting as a gateway between RDMnet and regular RDM devices connected to the Multiverse Radio.
In my test rig I have 4 RDM devices connected to Endpoint 1

The problem I'm facing is the following:
Once the Controller discovers Multiverse Transmitter, it asks for the list of Endpoints, and when expanding one of the Endpoints, it asks for the list of Endpoint Devices.
As soon as the Controller receives the list of Devices connected to that Endpoint, it generates 4/5 messages (I do not remember exactly how many) for each Devices (basic messages like DEVICE_INFO, SUPPORTED_PARAMETERS, etc...)
As you all know well, the bandwidth on a physical DMX/RDM port (as well as our Multiverse Radios) is way less than the bandwidth of an ethernet port, and it also is half duplex.
This means that it is physically impossible to generate responses for those messages as fast as they are coming in.
This means that our gateway will have to store those messages, start serving them one by one, and send back the response before it can start to free up its memory.
Of course, this is not too much of an issue if the gateway has plenty of memory, or if the number of devices connected to it is small.

In the specific case of our Multiverse Transmitter, we were planning on being able to support up to 5000 devices connected to it, and the MCU we are using does not have the memory to store that many messages.

So my question is: Is the behavior of the Controller I'm using, a legit one? I know it is just a test code, so I was wondering if it is somehow not compliant regarding this specifi issue. Alternatively, is there any form of flow control I can implement to signal the Controller that I'm running out of resources and that it should peace itself a bit? I read through the E1.33 standard, but I could not find anything about it.

In my opinion, there should be some kind of rule that should impose a Controller to wait for some kind of reponse (either actual reponse or status message) before sending a new command to the same endpoint. At least for phisical ones, because we know that phisical DMX/RDM ports are slow compared to ethernet ports.
This would make the memory requirements of a gateway easily estimatable. Without this rule, the memory required by a gateway is virtually infinite.
Also a status message signaling that the gateway ran out of resources sould be present, to make sure the controller knows that a message will have to be asked again later.

Thank you all for your replies and for taking the time to consider this issue.

mvigni is offline   Reply With Quote
Old February 18th, 2021   #2
Task Group Member
Join Date: Jul 2018
Location: Chicago, IL
Posts: 6

Hey Matteo,

I maintain ETC's RDMnet implementation and examples. There is no rule in the standard that mandates a maximum request rate or flow control for RDM messages, and in fact such a rule would be overly limiting for purely network-based RDMnet communication.

The good news is that RDMnet uses TCP for its underlying transport, which has built-in flow control. To throttle the rate of requests from a controller, simply pause reading your TCP socket when your local message buffer gets full. This will cause data to back up in the TCP queues on the controller and broker and eventually will cause the controller's send requests to block until your device is ready to handle them. TCP's guarantees of reliable and ordered delivery will ensure that all of the requests will eventually get through as long as everything stays connected.

Let me know if you have questions.
Sam Kearney
Software Engineer
bootress is offline   Reply With Quote
Old February 18th, 2021   #3
Junior Member
Join Date: Feb 2021
Posts: 2

Thank you for the hint Sam.
Being so focused on the RDM side of things I lost view of the big picture.

Thank you again

mvigni is offline   Reply With Quote


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
RDMnet Introduction Webinar sblair RDMnet (E1.33) General Discussion 0 September 4th, 2019 01:45 PM

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

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