TCP Listener doesn't disconnect ghost clients

Core Development
1

Hello,

I have a TCP listener on my flow and some clients that apparently doesn't disconnect after sending the message. Also they are not re-using the old connection when they send a new message.
I end up with a lot of ghost connections on my TCP listener.
image

Is there any method to disconnect them after each message? ... or after a certain time of inactivity maybe?
Thank you

2

Hi @LucianR I'm not sure I have an answer but I do have a question. What is connecting to your TCP endpoint? What's it used for? Do you have control over the incoming connection(s)?

3

Hi @Steve-Mcl,
Unfortunately those are some industrial PCs that I don't control.
I cannot do anything on that end ...

I was hopping that i can do something on the listener/server end.

I also don't know what is the max limit on my server .. and what will happen when it will reach the limit.
It will recycle? It will crush? It will restart? It will refuse new connections?

4

Industrial PCs or PLCs?

If it's PC them what software is making these connections?

If PLC, what PLC make & model?

All that said, It could be the software/hardware initiating the connection isn't closing it correctly. Or perhaps errors are occurring are you familiar with wireshark? If you can install it on on the node-red machine - look see if FIN is being sent? Check the close sequence?

Ps, what node version and node-red version are you using?

5

It's a linux based industrial PC with a vendor proprietary software.

I'm using this version
image

I'm not sure i can install wireshark but i can try with a different tcp listener client to see if it's doing the same. Thanks for the hint

6

@Steve-Mcl, apparently there is a bug on the client
Is sending a full message, is clean closing the connection and few milliseconds later is reopening it, and this time is not sending anything. Just hanging there.
I've open an incident ticket to my vendor .. but .. who knows how fast of if they will fix it.

So on the server side, there is no workaround to solve this kind of problems?
as in .. drop a connection if no message was received in X time...

Thanks for the help

7

Tbh, your options are limited.

Perhaps when you speak to the vendor, ask them if they have other options. Like MQTT. That would greatly simplify matters.

In the mean time, if production permits, you might want to schedule reboots.

I'm sure others will chip in & might have better options.

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.