Hi,

There are some settings that could prevent the clients to connect to the listening port (assuming that the firewall is not blocking it):
-An element can be configured to only allow clients to connect from a certain IP address
-The protocol.xml can have a setting "maxConcurrentConnections", see info here

By default, when above is not applied, there is no limit on the number of clients that connect.

Note when there are more clients connecting that this will take up more resources.
Per connected client there will be two threads running in the background: one thread to send and one thread to receive. Each thread takes up 1MB of memory, meaning per client 2MB, resulting for 300 connected clients into 600MB memory of the SLPort process (total memory limit is 4GB), and then the data per client also needs to be temporary kept in memory when constructing the response.

Even though every client is a separate thread in SLPort, the data needs to be passed to SLProtocol (and SLScripting to execute the QAction that filters out the responses where the ID matches). This means that all data from all received clients need to be processed by one thread. That thread needs to be fast enough to process everything, or else large delays will start to happen, memory will build up, and eventually as the receive buffers in Windows are not processed fast enough it will start to drop the data. Depending if it works or not all depends on how fast the clients are sending data and how fast the QAction is able to process the received values.

I'm wondering, instead of filtering on the id inside the received data, if it would not be possible to filter on the IP address of the device? This way the element can be configured with the "allowed ip addresses" and already filter on that inside SLPort, without needing to go to the one thread bottleneck in SLProtocol.

Regards,