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 March 7th, 2023   #1
Junior Member
Join Date: Jan 2023
Posts: 3
Default RDM-NET forces TCP

reading the spec, had hoped to build intelligent devices, based on a micro (i.e 64K Flash, 8K RAM), supporting sACN / DMX / RDM and RDM-NET
we support UDP stack, but full TCP is too much memory...
hence LLRP would be ok, but we cannot support TSP for RDMNet.
thoughts ?
Florida-Rob is offline   Reply With Quote
Old March 7th, 2023   #2
Join Date: Feb 2006
Posts: 436
Send a message via AIM to sblair Send a message via MSN to sblair

Hey Rob, welcome to the forums!

LLRP is ONLY meant to be used as a rescue protocol for devices that have incorrect network settings or settings that prevent them from establishing a TCP connection to the Broker to use RPT.

You'll notice in the E1.33 standard that there are VERY strict rules that only allow specific RDM PIDs to be used with LLRP and disallow all others. This is because LLRP does not have the scalability or any of the reliability that are built into RPT. LLRP was intentionally limited to have the most minimal configuration capabilities in order to perform just enough configuration to establish the Broker TCP connection.

If we allowed for LLRP to do more than that then it would cause enormous interoperablity issues as it would essentially create 2 different protocols for doing the same functions and it would be random as to which one someone chooses. In many cases the easier one would be picked which does not have any of the scalability or reliability needed or the synchronization for multiple clients.

To be compliant to the RDMnet protocol it really does require RPT to be implemented using TCP. We put a significant amount of effort into creating an architecture that had the most minimal TCP requirements for an end-device. In this case, only a single TCP connection is required to be supported.

I hope that helps clarify the reasoning.

Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 7th, 2023   #3
Task Group Member
Join Date: Jul 2018
Location: Chicago, IL
Posts: 6

As my colleague Scott says, TCP is required for RDMnet, but only at most one TCP connection is required at a time. I would recommend looking into the compile-time config options of your network stack and see if you can tweak the settings to just the minimum necessary to support a single TCP connection. For example, in the popular stack lwIP, there are many config options that control how much memory is allocated to hold state for connections; most of them are defined in this file.

As you probably know, 64K flash and 8K ram is toward the bottom range of hardware that can support any kind of network stack at all. It may not be practical to support RDMnet on this hardware, but even if not, you almost certainly could do it with a spec increase on the same order of magnitude (say, 128K flash, 32K ram).
Sam Kearney
Software Engineer
bootress is offline   Reply With Quote
Old March 15th, 2023   #4
Junior Member
Join Date: Jan 2023
Posts: 3

I still think its a mistake forcing TCP, i'm looking at the code, and its not pretty on resources required even for minimum TCP stack (even for a single connection), for qty of SRAM and FLash - it simply blows the use of smaller micros, and adds a TON of cost. even if we use external Flash, the RAM content is fixed and small in most micros.
Florida-Rob is offline   Reply With Quote
Old March 15th, 2023   #5
Task Group Member
Join Date: Aug 2008
Posts: 376

Originally Posted by Florida-Rob View Post
I still think its a mistake forcing TCP
At one point during the standard's development, everything was based on UDP for exactly the reasons you gave. The "send and forget" model of UDP is very attractive for small microcontrollers.

As development progressed there were several cases where both ends of the communication link needed to have a consistent view of the protocol state. UDP is an unreliable transport, so maintaining consistency meant building a re-send/re-try/reliability layer on top of UDP.

We actually tried to design this. But building a reliability layer that can handle lost and re-ordered packets over a network with latency and multiple packets in-flight simultaneously meant we were effectively re-implementing the full complexity of TCP in the application layer.

At that point it made more sense to use the standard Layer 3 protocol that already existed rather than develop something new at the application Layer. TCP has existed for decades, and is well understood, and well debugged.

I was perhaps the biggest advocate for the "All UDP" model. I've spent much of my life working with small MCUs, and counting every byte of SRAM and EPROM. But in the end it became clear that using TCP was the best solution, and that it would result in better interoperability.

Last edited by ericthegeek; March 15th, 2023 at 11:51 AM. Reason: spelling correction
ericthegeek 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
RDM over Art-Net jpk__ RDM User Discussion 2 July 21st, 2013 02:44 PM
RDM V1.0 and Art-Net anstein RDM General Implementation Discussion 1 July 23rd, 2006 09:50 PM

All times are GMT -6. The time now is 03:59 AM.

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