TCP connection vs. Add route
jamesrdelaney
Posts: 7
Hi
If I have an Netlinx box at one site and another Netlinx box at another site
and I would like to make a device on the first box available to the second box,
is it better to:
a)
Just add the second box to the first box's connections as if it were on the same LAN
OR
b)
Start a TCP connection from within the code, to my button push or send a string or whatever, and close the TCP connection.
Thanks
James
If I have an Netlinx box at one site and another Netlinx box at another site
and I would like to make a device on the first box available to the second box,
is it better to:
a)
Just add the second box to the first box's connections as if it were on the same LAN
OR
b)
Start a TCP connection from within the code, to my button push or send a string or whatever, and close the TCP connection.
Thanks
James
0
Comments
I would say this depends on two things: how good is the connection, and how much traffic do you need to send back and forth. If the devices shared need to do a lot of give and take, and your connection is good, I'd go with a). If you only need to do occasional communications, or if the connection is flaky, go with b).
The thing is, once you define a remote connecton in the URL list, the NetLInx master will try to maintain it continuously. So if the network link goes down, the process of re-connecting, which you have no control over, will be happening in the background, and can really, really bog things down. In fact, it can crash your master. NetLinx devices do not deal well with disconnects, not at all. If there is any uncertainty in the connection, a persistent entry in the URL list can cause big trouble.
Dave, can you prove this?
I take great issue with you claiming that Master to Master does not work well. I would argue it works extremely well with a properly configured network. Worse case you get OFFLINE/ONLINE Data_Events from the remote system.
Use a telnet or terminal session and configure both Masters as follows:
1) route mode direct
2) set udp bc rate 0.
Put the URL of the second Master in the first Master.
Leave the URL list of the second Master empty.
Can you explain what Route mode direct and setting the udp bc rate to 0 does?
James
Hi
I thought I would try this.
However I have realised that setting the Route Mode to direct causes some problems for me.
I have more local AMX boxes that are all connecting the the local box here.
So when I set route mode to direct, some of them go offline from this box.
Can I set all boxes on this site to route mode direct to all others whever Master-To-Master communication is required?
Is there any issue with performance or stability?
James
Set the Master-Master route mode.
set udp bc rate
Set UDP broadcast rate. A broadcast message is sent by the master to allow devices to discover the master. This command allows the broadcast frequency to be changed or eliminate the broadcast message.
As long as you don't have more than 15 Masters you can use direct mode. Make sure the URL lists are set correctly.
So does setting the udp bc to 0 mean that boxes won't automatically pick each other up?
What happens when one of them goes offline? How do the others find it again?
James
There should be no problem M2M.
Don't forget to make your system numbers unique for each Master.
This is working well now.
James
I have one very large system with multiple masters that had the problem I am alluding to. I have stabilized it, for the most part, but every once in a great while I still get masters falling into this oddball disconnect cycle where they will go online and offline, and messages back up until one or more of them become very sluggish or unresponsive. The unresponsiveness causes more disconnect/connect cycles until nothing works. When this happens, I have to reboot every master in the sytem, and that clears it up. Fortunately for me, I only seem to get the problem at all when I have loaded new code; something gets goofed up when my main master is started up. It's rare when it happens, but it is nearly always the result of me loading something new, so I am there to reboot the other masters. They all seem to run fine without intervention if left to themselves.
Originally (and there are several threads from when I was having the worst trouble), this was happening on it's own every week or so, and I was constantly running to the site to reset everything. That turrned out to be a TCP/RS-232 converter. When I eliminated it from the system, most of my other troubles went away. I also went through the entire project and modify as many chatty devices and feedback methods as I could. There was a clear relatonship between my lockups and some device or a master disconnecting from the rest. It seems there is an issue that messages will continue to go out to a unit that has fallen offline. I have concluded that NetLinx devices do not always, or perhaps just do not immediately detect an offline condition, and will continue to try to send to them until they are certain of the disconnect. This results in backlog in the message queue, and that is what takes the system down. NetLinx masters are very sensitive to message queue issues.
Is that proof? No, it's deduction, but I think it's pretty solid. I would be more than happy to entertain alternate theories, and AMX is strangely silent on the issue. I have spent many hours with tech support not getting anywhere with this.
Because of these troubles, I make very certain of a couple things: (1) I have as solid a network superstructure as I can possibly get; (2) I limit feedback, send commands and messaging that travel between master to an absolute minimum, so that if there are any network glitches, the chance of them bogging something down is minimized.
If I came across as seeming like I was saying master-to-master is unstable and should be avoided, I sure didn't mean to. I use it all the time. I just am careful about things that might casue an undetected disconnect, and it seems to me an Internet-based connection just leaves an awful lot of room for that to happen.
I have had much experience with this.
Here's the deal. Most of our clients (residential) have pretty large systems that commonly have both Cablevision and sometimes 1,2 or 3 flavors of Satellite and Sat Radio going at the same time.
as many of you know, all these providers commony change their channel lineups. EX: CNN was channel 202 last week but now it's 222.
I program all the channels in for our clients so they don't have to use the on screen menu or remember the channel numbers.
Now the problem is that I have to do a lot of programming changes whenever the SAT / Cablevisio co. change their line-up or add XM channels or whatnot.
My solution is that I have a Netlinx Master here at our offices that is called the Mothership. In it are current channel lineups that the client systems check in to every day. If the lineup changes, I know the masters will upload all the changes and the client is none-the-wiser. When I update any information (not just channel lineups but other system stuff too) the mother ship knows and reports to me that all of my systems have updated or lets me know of lost sheep that haven't reported. Also the systems report back that they could or couldn't see the mothership.
I also use this system to upload all sorts of user data and system info. I get twice daily reports about any and all parts of the system and its use. (or misuse as the case may be.) It's like a customized i!-Equipment Monitor that AMX wrote.
Now...
I first tried the master-to-master type connection for the obvious advantages that it offered. However, whenever a large melt-down on the Interenet would occur, It would really mess things up. (Example, Comcast Digital Cable's Internet goes dead on an entire subnet.) I would commonly have to reboot each system and sometimes even the Mothership. The error logging just gets to be too much. Also of note: I did have the masters set up in the precise method you mentioned. That being the advice of tech support.
I ended up converting the whole system over to a IP Port to Port system. I don't use the telnet port but a set of ports I decided upon. I also created my own method of security for it.
Connection failures don't kill my masters. They just show up in my logs. I also have my own system of backing off the number of re-connect tries as the system stays offline. In other words, I scale back the number of connection attemps as the offline time increases. I figure, that if it's just a minor hiccup, I'll get back on fast. However, if it's been offline for over an hour, there's bigger problems than just network traffic.
In my previous job on a large Univesity campus we found that we had a similar problem even though we had a pretty good and reliable network.
I do use Master-to-Master quite a bit. Usually, it's within a home's network behind one router. I like to use NI-700's for remote small home theater controlers. I load an empty Netlinx template in them and connect them to the master.
Not to Threadjack, but a similar issue happens concerning ICSNet stuff. ICSNet communication errors do not show up to us (programmers/users) as errors in our feedback. I found this out when I was dealing with troubles from ViewStat thermostats with the Miniverters. The Stats were flooding the ICSNet with errors. The master became overwhelmed trying to log all the errors. All I saw was that the master would start to bog down and run erratically. Eventually, the masters would just freeze up, requiring a power cycle. There was never an 'offline' message from the device and it would even act somewhat correctly. I'd watch in NetLinx Diagnostics and see nothing wrong exept that ND would hand up and crash.
After battling this for some time I found out through tech support that they have an Über Netlinx Diagnostics program that can see the 'under-the-hood' errors. He told me of the comm problem and how to solve it. I asked him why we weren't allowed to have the Über ND. TechSupport's response was that it would give us too much info about the inner workings.
So, there is some problem with how the NetLinx master handles communication errors and how they log them. There is sufficient evidence of this phenomonon, IMO...
Sorry to hear about your problems.
One of the techniques that I use for M2M systems is to only use Channel_Events between systems as a way to pass control functionality. I know this requires code to reside in secondary masters, but it reduces the number and size of the packets that pass between the systems.
Pulse the channel of a virtual device in a remote system which generates a Channel_Event to trigger the required code. Feedback status is passed back in similar manner with channel states.
I totally understand that when the event stack gets filled the master will run out of memory and stop functioning. Careful coding can minimize pending messages so this does not occur.