RDM-NET forces TCP

[Florida-Rob]

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 ?

[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.

Thanks.

[bootress]

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).

[Florida-Rob]

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.

[ericthegeek]

Originally Posted by Florida-Rob

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.