original input msg obj gets lost

[protonmw]

The original input msg object with all other information (for example return node information) is getting lost.
The better way would be to update msg.payload and keep the other information.

[jorgen-k]

The original input msg object with all other information (for example return node information) is getting lost. The better way would be to update msg.payload and keep the other information.

Please update with information on what you try to do. If possible add an example showing the faulty behaviour.

[protonmw]

Input object:

Output object:

The tcp node creates a new msg object, instead of changing the payload. Therefore all other information like "_linksource" are getting lost. Put the tcp node between link_in and link_out nodes (to create a function) to see the behaviour. I stored this manually in the screenshot below.

[jorgen-k]

I see your point.

In different applications, servers might emit data sporadically or may not respond in a timely manner, or will automacially emit a lot of data without any data from the client. This necessitates a TCP client design that can gracefully handle such variability. This includes the ability to manage data that arrives without a direct request as well as requests not resulting in any data.

To accommodate these diverse situations it will not be possible to always justs anhance the message object with payload.

To do this we could pursue a strategy that involves storing incoming message objects upon receipt. Should the server provide a response, the system update the payload of the stored message object, rather than creating a new one. If multiple messages are emitted, the same applies for all messages. Of course this behaviour must be configurable since it could have unwanted side effects.
The proposed approach is encapsulated in the following operational scenarios:

Client-Server Data Receipt:

• Given the feature is enabled and the client is connected to a server,
• When the tcp-client receives data,
• Then the data payload is forwarded to the server, and all other data is retained within the client for contextual integrity.

Server Data Emission:

• Given the feature is enabled and the client is connected to a server,
• When the server emits data,
• Then the emitted data is enriched with the retained data, if available, preserving the full context of the communication.

[protonmw]

I see your point too ;-)

I was used to this behaviour of the standard TCP request node, so it would be nice to have this feature implemented.
Since im not a js programmer but only a "stupid" node red user, I can´t help really much on this.

But I think I´ve found the code of the built in tcp node (especially line 646 and following):
https://github.com/node-red/node-red/blob/master/packages/node_modules/%40node-red/nodes/core/network/31-tcpin.js
Perhaps this helps?