How to pass session to TCP REQUEST?

I have a device that listens on a specific ip port (e.g. 30000).
I need to connect multiple times to that device, at least from two different tcp-request nodes. Typically when the device accepts the connection, it returns a work socket to the caller and goes back to listen for other connections on the original port (30000).
The problem is that I can't catch that port from tcp-request node and every time I want to send something I have to pass host and port. In this way I don't know what port to pass, because I can't get the work port.
Instead of using tcp-request, I understood I can use tcp-in and tcp-out, by storing the _session object. Thant could work, but tcp-in and tcp-out can't work with dynamic host:port.
So, I need either of the two:

  1. possibility to get and set _session or work port from tcp-request node
  2. possibility to dynamically set host and port in tcp-in / tcp-out

Can anybody help me ? (I don't have much time to tweak the source code and create a new node. I would need to learn everything from scratch... :slight_smile: )


How is the new port info transfered to device that is connecting?

What do you get when you connect to the port with a terminal emulator? (i.e. Realterm or YAT)

The new port info is typically negotiated by the underlying socket handshake when the connection is accepted by the listening socket (the device).
Performing tests with Hercules (or putty) terminal you can't see it because they expose the connecting/listening port and not the work port.
I fear this is not possible with the current tcp implementation in node-red. Probably a little modification will be needed.
Thanks indeed.

Is it completely random or always in a certain range? If so you could just try to connect to that range and use a status node to catch the status of the request to keep polling the next port untill the port opens.

Or if time is of the essence because the port might close or the TCP listener might be remove on that port. just make a lot of tcp request and define which one works with the status node.

It is not a high tech solution but it might work

Update. Doing some tests I found that internally the node remembers the working socket, so if the new message is given with the original port, it is automatically addressed internally to the working port.
I think the topic can be closed.

1 Like

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