Number of concurrent connections
- Thread starter KentDub
- Start date
ELK's ELKRM page always listed 30 as the maximum number of connections, so I would say it's a safe bet that this is the limit. If I remember correctly, it's because of the M1XEP CPU (or maybe the RS485 databus) not being able to handle more.
apostolakisl
Senior Member
I don't quite understand how that limit would work. With IP, the connections aren't active except for when info is actually being transferred, right? It isn't like there is some handshake and then a continuous streaming connection. Or is there? So how would the system know if there were thousands of items all hooked up but not communicating at any given point in time?
I do know that when you are logged in via RP the system locks out my ISY and I assume all other ethernet activity.
I do know that when you are logged in via RP the system locks out my ISY and I assume all other ethernet activity.
KentDub
Active Member
While I do not know the internals of the M1G, traditionally for each connection you spawn a new thread to handle it. There is a lot of overhead creating and maintaining all of these threads. There is also additional overhead for simply having an open socket. The limitations are not bandwidth related, but more the aforementioned overhead related to each connection. In TCP, a connection is 'active' if the connection was established; regardless of if any data is being sent or received. UDP on the other hand, is a connection-less protocol, faster, but unreliable (usually used in games), and not appropriate for a security system at all. If you're on a windows machine, open a command prompt and type 'netstat -no' (no quotes) and press enter. That will list all of the connections on your computer. It is a basic requirement of any network to know what connections have been made (otherwise how do you send/receive data?), and finding idle connections is as simple as storing a timestamp of the last data sent/received and comparing that to the current system time.
I was originally concerned that the M1G would only allow only one or connections, mainly due to it being a serial protocol. I am very glad to hear that is supports at least 4, which is around what I'll need =) (Automation software, Custom software, Remote connection from cell phones, etc.) If you had a system that required more than 16 or 32 concurrent connections I would ask you to seriously take look at your architecture.
wuench
Senior Member
The M1 does a lot of proactive notifications so to benefit from those the TCP connections would need to stay up. If you just connected/talked/disconnected you would need to re-poll for all the changes and that can take a long time on the M1 (most notably) counters. So probably 30sec-1min to get all the updated info via polling. So the polling method is not really ideal for a near-real-time interface like ElkRM.
The two programs I am familiar with CQC and eKeypad both maintain their TCP connections, I can't speak for ElkRM specifically, but if I had to guess I would say it does also just based on the Elk's protocol.
One other note is when ElkRP is connected, all other communication must is suspended, but I believe the TCP connections can remain up.
The two programs I am familiar with CQC and eKeypad both maintain their TCP connections, I can't speak for ElkRM specifically, but if I had to guess I would say it does also just based on the Elk's protocol.
One other note is when ElkRP is connected, all other communication must is suspended, but I believe the TCP connections can remain up.
apostolakisl
Senior Member
Thanks for the answers. I assume at some point the Elk closes those TCP connections due to inactivity? I did execute the netstat on my laptop here and found about 50 tcp ports were listed, a couple I recognized as they were ports I opened on my router for specific applications, but the vast majority I couldn't figure out what they were. Interesting stuff.
Lagerhead
Active Member
I have had connections maintained for long periods -- several weeks or more. Of course there is activity at least every 30 secs with the M1 keep-alive string.
Right it's better to track the spontaneous activity coming out of the M1 on a continuous basis. But you can pull all lighting status, all zone status and all touble status with just a few commands, in way less than one second. Counters -- I don't know, 64 distinct queries, right? Still I'd be surprised if it took more than a few seconds (Ethernet at 100 mbps).
Right, the connections are maintained, but traffic stops until the "installer mode" is ended. After this I don't trust the data that I have, so just to be sure I didn't miss anything, my code refreshes all tracked states via polling.
I actually find the ELK M1 protocol to be one of the best documented and easiest to implement protocols out there. It's pretty advanced, yet the syntax is so simple I was able to write drivers in ActionScript, PHP, VBScript and other fun languages. Kudos to ELK for getting that right!
Similar threads
