E1.20 RDM (Remote Device Management) Protocol Forums  

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

RDMnet (BSR E1.33) Draft Standard General Discussion General Discussion and questions concerning the draft E1.33 standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old September 25th, 2012   #1
owaits
Member
 
Join Date: Aug 2011
Posts: 32
Default RDMNet Draft

Finally managed to have a first read of the draft and impressed by some of the improvements. Initial reaction though is that it has got way more complex (which worries me). I have some questions from my first read that hopefully someone can answer.

- is the controller supposed to publish over SLP both a controller and device service?
- if the answer above is no then why does the controller not have to publish its Device ID in the SLP discovery?
- how is it decided whether to use a "Controller Mesh" or "Master Controller"? Should you assume that if the user has entered a master IP Address then you use a master controller. If so what if the lighting console is on one show where they use a master and they take the same show to another show with no master. Things wont work.
- I am sure there is a good reason why you have not used a multicast group to distribute the queued messages but what is it. My guess is reliability but is the reliability so bad it warrants all the extra complexity in the standard.

Good work though! My questions are partly curiosity. Sure I will have more in due course. Bit tight to look at everything before the deadline though. Not great time of year for this with PLASA just gone.
owaits is offline   Reply With Quote
Old September 25th, 2012   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

Most of the changes were driven by public review comments.

The move from a Multicast "Squawk Group" to a TCP mesh was driven by reliability concerns. We found ourselves spending a lot of time debating how many times a given message to the Squawk Group should be repeated, with how much time between repeats. But no matter how we arranged it, there were always packet loss scenarios that could result in important data getting lost. We eventually realized we'd need a reliability layer on top of the UDP multicast (Thus triggering the "Those who do not understand TCP are condemned to reimplement it badly" maxim). The move to a TCP mesh eliminates those concerns.

Generally, the use of TCP in a live performance environment is a bad idea because of the TCP Cascading delay problem. But, RDM is primarily used for management traffic, no live control. Thus, an occasional 500ms delay in the TCP data isn't catastrophic. I fought against TCP for a long time, but in the end the advantages were compelling.


The "Master Controller" *shall* only be used when manually enabled by the user. We jokingly call it the "I know what I'm doing option". Some users may want this option available under certain circumstances. Yes, if that option is set in an E1.33 Device, it may not work when you connect it do a different network, but that's true for many other options as well (static IP addresses, etc.).


I'll let others address the SLP issues, I'm not especially familiar with SLP.

Last edited by ericthegeek; September 25th, 2012 at 12:07 PM.
ericthegeek is offline   Reply With Quote
Old September 25th, 2012   #3
owaits
Member
 
Join Date: Aug 2011
Posts: 32
Default

Quote:
Yes, if that option is set in an E1.33 Device, it may not work when you connect it do a different network, but that's true for many other options as well (static IP addresses, etc.).
Coming from a console manufacturers point of view this concerns me. It is not so much the person who knows what he is doing but the person who does not but then has to either take over the same rig or use equipment that has been configured by someone else to use the master config. My feeling as a developer at the moment would be to not implement the master mode so users could not tie themselves in knots (this would push me out of spec though). I agree that static IP addresses have the same issue, I get calls on a daily basis from our customers. I can forgive IP though as it is a standard that was designed for fixed installations not touring shows or one off setup's. However we are designing an event industry protocol so ideally it wont require the LD to phone the console manufacturer to find out why it is not working.

Does it need to be in the spec at all?
owaits is offline   Reply With Quote
Old September 25th, 2012   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

Quote:
Originally Posted by owaits View Post
Coming from a console manufacturers point of view this concerns me. It is not so much the person who knows what he is doing but the person who does not but then has to either take over the same rig or use equipment that has been configured by someone else to use the master config.
Speaking for myself only (not the task group), I struggle with this as well. Should the standard protect the user and prevent them from doing things that might break "Plug and Play". Or, do we include more flexibility that could be mis-configured and cause confusion.

In the end, when there are reasonable use cases, I feel we should permit the additional flexibility. No matter what we do at the standards level, lighting systems will require some level of configuration. Many consoles support softpatch, even though it can confuse someone who's expecting a 1-to-1 patch.

A well design product might include a "factory defaults" button (ala most consumer WiFi routers) to force it back to a plug-and-play state. A given manufacturer might also include a "Fix My System Wizard" that addresses the problems, or write their software to not use the more complex features. But these are product level design choices, not standards level.

Obviously we need to avoid unnecessary complexity whenever possible. But, at the standards level, I feel we shouldn't handicap knowledgeable users for the sake of protecting the less skilled.

Quote:
Originally Posted by owaits View Post
My feeling as a developer at the moment would be to not implement the master mode so users could not tie themselves in knots (this would push me out of spec though).
As I read the draft (my personal interpretation) you *may* implement master controller. But you are not required to support this style of operation. An implementer is free to include it, or not include it depending on what make sense for their customers and market.

If you do implement master controller it *shall* require manual intervention to become active. The reason for this is that we didn't want anyone to implement a controller that only supports Master Controller mode and promote it as complying with the standard. As and end user, you know that any E1.33 controller will handle the mesh. If you have specific needs that require the Master Controller mode, you'll have to ensure you purchase controllers with that support included.

Last edited by ericthegeek; September 25th, 2012 at 12:08 PM.
ericthegeek is offline   Reply With Quote
Old September 25th, 2012   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 415
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Eric covered the dilema we face well. Often what it comes down to during the Task Group meetings when we are debating these things is that Manufacturer A wants to be able to do X. Manufacturer B wants to be able to do Y. Both have compelling use cases and their parts of the market can have different needs. We all work hard to have the single simple solution wherever we can, but lots of times we have to accomodate the needs of both which is how we end up with something like that.

Please submit Public Review comments on it though. Those are what really drive the direction the standard takes at this point. As Eric noted most of the substantial changes you are seeing in this draft were all driven from the previous Public Review comments. It shows how seriously they are taken by the group.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 27th, 2012   #6
owaits
Member
 
Join Date: Aug 2011
Posts: 32
Default

Quote:
Should the standard protect the user and prevent them from doing things that might break "Plug and Play". Or, do we include more flexibility that could be mis-configured and cause confusion.
My answer is yes the standard should protect the user. The reason is that even if one implementation is bad the user will see the whole standard as bad and simply not use it. I think you are wrong if you do not encompass the user breaking the system within the reliability of the whole system.

Having read things a bit more I think there are changes which could make it more reliable. The most crucial perhaps is for a controller to report to other controllers which mode it is in. That way the system could detect a conflict in the setup and alert the user. In addition you could allow the master mode to be configured over RDMNet so that one controller can repair the whole network by sending a command to each controller.

I am all for adding advanced capability but that should never be at the expense of the reliability of the basic functionality.

Quote:
As I read the draft (my personal interpretation) you *may* implement master controller.
It says in section 8.1 "All controllers shall provide an option to the user which bypasses SLP controller discovery and statically configures a single master.". Is this a mistake as I do not read this as optional.

My intention is to submit these comments but I like to chew things over here as I want to be sure I have a full understanding before commenting on things.
owaits is offline   Reply With Quote
Old September 29th, 2012   #7
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by owaits View Post
It says in section 8.1 "All controllers shall provide an option to the user which bypasses SLP controller discovery and statically configures a single master.". Is this a mistake as I do not read this as optional.

My intention is to submit these comments but I like to chew things over here as I want to be sure I have a full understanding before commenting on things.
That is correct. Supporting master controller mode is required otherwise no one will do it and then when someone wants to scale the system by using a master controller the existing controllers won't work.

I like the idea of advertising the mode a controller is in. Sean suggested the same thing.
nomis52 is offline   Reply With Quote
Old September 29th, 2012   #8
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

- is the controller supposed to publish over SLP both a controller and device service?
Yes, it is required. Hopefully the standard is clear on that.

- how is it decided whether to use a "Controller Mesh" or "Master Controller"? Should you assume that if the user has entered a master IP Address then you use a master controller. If so what if the lighting console is on one show where they use a master and they take the same show to another show with no master. Things wont work.
The user decides what mode to use. It's up to the console manufacturers to may it clear this option may break the system, just like turning preview mode on in E1.31.


I'll be at the event in Gatwick if you'd like to discuss in person.
nomis52 is offline   Reply With Quote
Old October 5th, 2012   #9
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default

Quote:
Originally Posted by owaits View Post

Having read things a bit more I think there are changes which could make it more reliable. The most crucial perhaps is for a controller to report to other controllers which mode it is in.
I've already submitted a comment on this, but you should as well your ideas may be better than mine!

Really when we first put it in the standard it was a "Get out of Jail Free" card for us. The option is essentially there in case there are situations where the mesh does not scale well. Such as possibly, large theme parks with hundreds of controllers.

Please question our logic!!!
SeanSill 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

Similar Threads
Thread Thread Starter Forum Replies Last Post
RDMNet Controller SeanSill RDMnet (BSR E1.33) Draft Standard General Discussion 11 August 2nd, 2012 11:43 AM


All times are GMT -6. The time now is 07:10 PM.


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