TCP Request node doesnt disconnect - BUG?

Core Development
1

Firstly, Relevant info...

npm -v 6.9.0
21 Jun 15:40:03 - [info] Node-RED version: v0.20.5
21 Jun 15:40:03 - [info] Node.js  version: v10.16.0
21 Jun 15:40:03 - [info] Windows_NT 10.0.17763 x64 LE

Issue...
I have an issue with the TCP Request node staying connected when "after a fixed timeout of" option is set in the Return property (ms is set to 10000ms / 10s).

TCP Request Node Settings...
image

But 5 mins later, node is still connected...
image

I believe the reason is setTimeout isn't called unless data arrives back from the TCP endpoint. see here. This is where I have a problem though - this particular unit never sends any data back (by design) so the setTimeout function is never called and the connection remains connected.

Can anyone confirm similar behaviour?

Is this by design?

I can post sample code however you would need a TCP device or application that will accept data & not reply, to test it.

If this is a bug or unexpected condition that needs some attention, a workaround might be...

  • Upon the node receiving a msg, if there is no ID in original-timeout or no-data-timeout , setup a no-data-timeout.
  • If a 2nd/3rd... msg is received before the no-data-timeout occurs, restart the no-data-timeout.
  • If data is received, clear the no-data-timeout & setup the original-timeout.
  • Upon no-data-timeout, send an empty payload and disconnect.

Regards, Steve.

2

If it really never sends anything back could you not just use a TCP out node ?

3

I have tried that but had problems with that too (I forget what now).

However, in the interest of things working as expected for all users, would we be correct in signifying this as a bug?

4

depends if you expect to use an out node to send something out, and a request node to get a response. So currently to my mind no. What is wrong with the out node ?

5

I had issues (I forget what now) with simply using the TCP out and this particular device.

However, It's more the point of disconnection not occuring after set time.

As far as I understand, the option after a fixed timeout of is supposed to disconnect after xxms.

I would just like to confirm that is the intention and if so, I believe the node to have a bug. Regardless of workarounds or or other options, I believe it's in our interest to highlight them & ultimately fix them no matter how benign.

6

As per the sidebar info the intention is to "wait a fixed timeout from first reply and then return, "
so it is as per that - so I don't see an issue. (Yes the prompt could be improved - suggestions please). Or indeed it could be a new mode of operation.

Timing out a node is the subject of a much larger design review (see https://github.com/node-red/designs/blob/master/designs/timeout-api.md)

If you can recall / recreate the issue with the vanilla tcp out node that would be useful.

7

Wow! Dangerous request on a Friday Night :wink:

How about something like: "Wait [After a fixed time of] [xxxx] ms after 1st response"?

8

It's when I find you lot most "creative" :wink:

9

Hmmmm....

So, I see a gap in the market!

If I'm reading the cues (and code) right, if I did get a response, the node will disconnect after xxms.

Since some devices don't respond I have only the option of disconnect immediately. And this cases an issue on the device.

Ideally, I need for the connection to remain open 10,000ms (as more messages may arrive) however holding the connection indefinitely has other issues so I need to disconnect. This is actually how I thought the after a fixed timeout of should work regardless of recieving any data.

Is there a command that can be sent to the node to initiate disconnection?

Or perhaps, an additional option named disconnect if no messages after.

Thoughts?

10

Yes possibly something like that. But not sure what you mean about staying open for a while because more may arrive. What if 12 seconds worth of messages need to be sent ? does it close 10 secs after first message sent - or get reset to 10 secs after last is sent ? (the timeout gets extended) I think some more thought is required before anything is implemented.

And indeed I still think that it needs to be considered as part of the out node

11

Hi again.

What I mean by ...

... Is to essentially if additional inputs occur, causing a transmission, that they be sent and the disconnection be deferred (extended) from the last message sent.

Any clearer?

12

Are there any news on this? I have a TCP connected device where I have to manually close connection after communication is ready.