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)
-   -   RDMnet gateway implementation difficulties (http://www.rdmprotocol.org/forums/showthread.php?t=1323)

mvigni February 18th, 2021 11:21 AM

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.


bootress February 18th, 2021 11:49 AM

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.

mvigni February 18th, 2021 12:23 PM

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


All times are GMT -6. The time now is 05:12 PM.

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