Skip to content

Practical limits on TCP/IP Sockets

IntegrelecJoshIntegrelecJosh
in PLCnext Technology & PLCnext Controls

Hello,

We're interested in building a TCP/IP server for a control application that will serve on the order of 400 clients. In this case, the data payloads are negligible -- say 4 bytes per TCP segment. The critical aspects for us are:

  • Keeping all of the sockets alive with a keepalive time of no more than 2 seconds.
  • Dynamically listen()ing for and accept()ing clients as they come online.

My questions are as follows:

  1. Is there any limit on how many TCP sockets can be kept alive at any point in time?
  2. For a network with 400 clients connected and container-only traffic (little or no payload), what kind of latency can be expected from the PLCnext in serving every client at least once?

Thanks and best regards,

Josh.


A few extra references:

I noticed a helpful thread regarding multi-client use within PLCNext Engineer. I expect it will be more efficient to avoid an IEC code implementation for this many clients.

https://www.plcnext-community.net/forum/#/discussion/3015/tcp-ip

Perhaps dynamic handling is the way to go? Here's the C++ API reference for easy access:

https://api.plcnext.help/api_docs_2022-9/classArp_1_1System_1_1Commons_1_1Net_1_1Socket.html

Comments

  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]

    Hi Josh,

    1. Is there any limit on how many TCP sockets can be kept alive at any point in time?

     Yes. My understanding is that Linux allows a maximum of 32768 TCP sockets. There is no additional limit placed on the number of TCP sockets in the PLCnext Control operating systems.

    2. For a network with 400 clients connected and container-only traffic (little or no payload), what kind of latency can be expected from the PLCnext in serving every client at least once?

    We don't have a number that we can give here (sorry). It should be relatively simple to write a basic server and and a basic client application that simulates these conditions, which would allow you to measure this latency. It will probably depend on the PLCnext Control device that you plan to use, and what else is running on that device (e.g. real-time program instances). 

    I expect it will be more efficient to avoid an IEC code implementation for this many clients.

    That may be the case - the choice of programming language may also depend on other factors, like where the TCP data is produced and/or consumed on the device.

    Perhaps dynamic handling is the way to go? 

    Perhaps. The development of a prototype/proof of concept would probably answer many of these types of questions.

  • IntegrelecJoshIntegrelecJosh

    Thanks for your quick reply Martin.

    My understanding is that Linux allows a maximum of 32768 TCP sockets. There is no additional limit placed on the number of TCP sockets in the PLCnext Control operating systems.

    I have also read this is the limit for a Linux system; I believe I've also read elsewhere that a kernel parameter or kernel compiler flag may reduce the number of sockets which can be allocated to a single process -- have you come across that before?

    Perhaps. The development of a prototype/proof of concept would probably answer many of these types of questions.

    Agreed. I'll be setting up some tests on a 2152 this week.

    That may be the case - the choice of programming language may also depend on other factors, like where the TCP data is produced and/or consumed on the device.

    Could you elaborate on this further? We want the payload to be calculated by some IEC code and egress via TCP to each client node on the network. Note, the payload is actually the same for all connections -- not much actual data handling is happening in the IEC code. I'm expecting to create a C++ real-time app to interface with the IEC code for this purpose; will this be the most deterministic approach? Also, what type of program would you recommend for this application?

    Best regards,

    Josh.

  • IntegrelecJoshIntegrelecJosh
    edited December 2022

    Hello again,

    A quick follow-up regarding my previous comment:

    I believe I've also read elsewhere that a kernel parameter or kernel compiler flag may reduce the number of sockets which can be allocated to a single process

    Some helpful light is shed I think by this thread https://unix.stackexchange.com/questions/84227/limits-on-the-number-of-file-descriptors

    Running ulimit -Hn returns 4096, and running ulimit -Sn returns 1024. So at least in the Linux userspace, it seems like 1024 is a default soft limit on the 2152.

    I'll proceed with some testing.

Sign In or Register to comment.