How does a TCP out node work when it is set to listen to a port?

I am currently trying to understand a system designed in Node-RED. There is a "master" raspberry pi and a "slave" raspberry pi. In the "master" portion of the system, I have identified a TCP in node that points to the slave at tries to connect to it. In the slave portion, the only reference to the port that the master is trying to connect to that I can find is a TCP out node that is set to listen to that port. There is a function node connected to the TCP out node and tries to feed input to the TCP out node. This does not make any sense to me, how does the TCP out node work when it is set to listen to a port?

Ok, I am not the best person to reply, but I feel I should contribute something back as I am good at asking questions.

I kind of get what you are saying, but would like to ask you:
What is it you are sending? As in: is it a message, or are you wanting to control programs on the other machine?

My take is that the TCP nodes allow you to send commands (not really the right term/word, but for now it will suffice for the sake of what is being said now) to a program.

So, say you have a program running and it has a TCP port on port 25.

On the other machine you connect to the remote machine and send stuff to port 25 of the other machine.

That program replies on port 80.
So on the other machine (the one which sends stuff out on port 25) then gets are TCP IN node and listens to port 80 for replies.

I'm not sure you are using the right nodes to do what you want. Though you didn't really say.

Does that help you?

I have to be careful with what I say, because I am not allowed to divulge too much information about how the system works.

What is it you are sending ?

0 or 1 is being sent. This is being used to decide when the "master" should send something to the "slave" physically.

My take is that the TCP nodes allow you to send commands (not really the right term/word, but for now it will suffice for the sake of what is being said now) to a program.
That program replies on port 80

Shouldn't the tcp out be set to "Reply to TCP" in that case?

Let me try to be more clear on what is happening:
Master has a TCP in node that is set to "Connect to port 8260" on host "192.168.250.63"
Slave has a TCP out node that is set to "Listen on port 8260"

What is confusing me is, why would an output node listen to anything. Isn't the job of an output node to output things? Not receive? Or is it listening to that port so that it can establish a connection to the TCP in node on the master?

There are two separate ideas here:

  • whether a node sends or receives data.
  • whether a node connects to a remote port, or waits for something to connect to it.

A TCP In node will send a message into your flow for each packet it receives from a tcp connection.
A TCP Out node will send a TCP packet over a tcp connection for each message you pass to it.

The question is then whether the tcp connection those nodes use was created by the node connecting to a remote port, or by a remote system connecting to the local node-red.

Thanks! That makes things a bit more clear.

So the TCP Out is set to "Listen to" because the person who made this system just wants it to make a connection to the master then?

Can I suggest you run an mqtt broker on one of your PIs and just use mqtt to communicate between them. It is so much easier than handling this yourself. If you don't know what MQTT is, don't be afraid, it is very simple and it will greatly simplify your intercommunications I promise :crossed_fingers:.

Just have a look around, once you "get it" you will no longer wish to implement custom communication channels like you seem to have here.

The TCP Out node is going to listen for inbound connections on that port. When a client connects to your Out node on that port, that client will receive messages you send to that Out node (in exactly the same way that you receive messages from the server you are connecting to with your TCP In node).

1 Like

??? - the in port can only listen on one port at a time - so you need two in nodes... so then it's easy to wire each to their own out/reply-to node - which will keep them separate.