How many TCP/IP connections can one master sustain?

Morris

Hi smart forum people,

I am trying to understand the limitations of M2M systems and IP connections. I'm confused by the documentation and hope someone could clarify this for me.

From Netlinx Studio Keyword Help File (Master to Master section): The second constraint is the maximum number of 250 simultaneous TCP/IP connections supported by a single master. The maximum number of simultaneous TCP/IP ICSP (NetLinx device) connections supported by a single master is 200. The top ~25 of the remaining 50 are intended to be used for internal services i.e. FTP, Telnet, HTTP, etc?
The next 25 are intended to be used for IP connections used in the NetLinx code via IP_CLIENT_OPEN, IP_SERVER_OPEN, and Duet modules.
If there are more than 25 IP connections made from within the code they will utilize the required number of remaining 200 IP sockets which reduces the number of available socket connections and subsequently the number of available NetLinx device connections which will reduce the number of available entries within the URL List.

Is this saying that if I have no IP connections made in code I can have the max of 200 entries in the URL list? If I am controlling 25 IP devices from code, how many IP's can I have in the URL list before all sockets are being used? None? 175? Or still 200? If I have 26 IP devices I assume that will reduce the URL list entries by 1?

As you can see I am confused about this and I'm sorry if these are silly questions but I honestly think the description here is poorly written and poorly explained. Maybe there should be an example put in the documentation to help clarify this.

vining

Based of what you posted I would say if you use 25 sockets in code for IP_CLIENTs or IP_SERVERs you still have 200 entries available in your url list, if you had 26 clients/servers then you would be able to have only 199 entries in the url list. I always thought it was only 200 in total between code and M2M and other sockets were available but reserved for internals like ftp, etc but apparently not according to this.

Morris

Thanks for your reply. Yes, that is how I would interpret this. I don't think I would ever hit that limit but the wording makes it sound like there are only 25 total IP connections that can be made, including the URL list.

[Deleted User]

The 'constraints' section of PDF page 5 in this tech note may explain these numbers in more detail than you read in the help file. http://www.amx.com/techsupport/PDFs/919.pdf

zerkalo

Would like to read the link but it's down

HARMAN_icraigie

Try this - may not be there forever as mentioned previously

https://dropbox.com/s/foid5uu9t72h07m/tn919-Master%20to%20Master.pdf?dl=0

fogled@mizzou

I can reliably run 77 ICSP and another 77 IP_Client_open TCP/IP connections on a single NX controller, for over 150 total. The dynamic allocation obviously works OK up to that point at least. But, I wouldn't particularly recommend pushing a controller very far past that point in any kind of production capacity. I usually keep the load split between two controllers for about 75 connections each.

zerkalo

Thanks for the link!

Carlos Negron

Ian,
Thanks for the link!

Emily

In general, modern operating systems and network hardware can support a large number of concurrent TCP/IP connections. For example, a typical server-class machine can handle tens of thousands of TCP/IP connections simultaneously. However, the actual number of connections that a master can sustain in practice may be limited by various factors, such as available memory and CPU resources, network congestion, and the workload of the applications involved in the connections.

John Nagy

Emily looks like a GPT invader!

jimavoid

@Emily said:
In general, modern operating systems and network hardware can support a large number of concurrent TCP/IP connections. For example, a typical server-class machine can handle tens of thousands of TCP/IP connections simultaneously. However, the actual number of connections that a master can sustain in practice may be limited by various factors, such as available memory and CPU resources, network congestion, and the workload of the applications involved in the connections.

Correct!

John Nagy

Correct and useless! "Could be a lot, but might be less..."

Marc Scheibein

@John Nagy said:
Correct and useless! "Could be a lot, but might be less..."

Just joking - that's called a "Micro$oft Answer" - correct by statement, but totally useless