Tcp In Nodes connecting to same host

Core Development
1

Hi There,

Another one of those "why is it so" questions.

Screenshot 2025-07-05 at 09.50.51
Screenshot 2025-07-05 at 09.50.51925×428 23.7 KB

Three tcp in nodes that connect to the same host/port combination. Initially all are disconnected, then when I start the service (i.e., netcat on 9393 - (while date ; do sleep 1 ; done) | nc -lk -p 9393), one node will randomly connect and produce time stamps messages.

I've been implementing the tcp nodes over at Erlang-Red and changed that behaviour to be the following:

Screenshot 2025-07-05 at 09.49.24
Screenshot 2025-07-05 at 09.49.241826×804 64.7 KB

All three tcp in nodes connect to the server and receive the same data. There aren't three separate connections, there is one single connection with the data being routed to all three nodes. (Behind the scenes, a centralised connection manager maintains a "routing" table and ensures that there is a single connection.)

All three tcp nodes receive the same data from the source with the same session id but they generate three different messages (differing message ids) containing the same payload.

I actually quite like this behaviour of having all tcp in nodes receiving the same data - I know that it's confusing and it shouldn't be done because .... <--- why though? That's where I got lost.

Also accidentally having multiple tcp in nodes with the same host/port combination is probably not that unlikely and then having a random node make the connection and receive the data is probably also confusing - IMHO.

So the question is, is there a reason for the Node-RED behaviour or is it simply a consequence of the implementation? Node-REDs node behaviours are unfortunately not standardised (something that I believe should change) so there is no explanation that I can find.

2

the tcp nodes were very early nodes so were written before the concept of config nodes existed - so instead of having one connection config they each try to create their own connection and so fight for the port.

While I agree it's probably no longer "best practise" -- I personally would find it confusing to have multiple nodes receiving the same data - I would naturally expect to have one receiving node then branch any messages out from it instead.

3

Sure that would be the NR way of doing things but I work with many independent flows that each - potentially - have their own tcp in node because each flow is designed to be "complete". So the potential for overlap is greater (since I import these into a single NR instance).

It's again one of those things that if it hasn't been an issue in ten years, then probably it isn't an issue!

Ah of course, that would be the solution - makes sense. However changing them now would cause - potentially - many old flows to break.

4

Yes. It can be done but the seamless migration is hard.