Force disconnection of TCP connection

General
1

In my fun MQTT broker project, part of the MQTT spec is to force a disconnection to a connected client from my broker under certain circumstances.

I don't think it looks possible to do that with the TCP nodes but just asking in case it is

2

I don't think it is. Certainly not in the sidebar documentation.

Pretty sure I've seen this asked before, more than once.

I'm ok with this being raised as a feature request but I'd be happier if @dceejay backed it up (he has more background on the TCP nodes than I do)

1 Like
3

I'm not too bothered if it doesn't do it, as its just a play project, so I won't pursue it as an FR :slight_smile:

4

Yes, I also asked this question about how to manually (via message) disconnect / reconnect a TCP connection because it happens that a connection gets unexpected disconnected after a while (at least in my setup via VPN).

A manual disconnection in my opinion is necessary if you connect to a server with the option "never disconnect". You should be able to close this connection and select a different server, right?

1 Like
5

And interesting definition of "never disconnect"....

6

@dceejay
Yes, you're right, that's interesting... :thinking: - I think I should have read my post again, before posting this... :wink:
But I think you know, what I mean?

I mean, it would be good to have the option to close the connection manually. Not automatically. But when you need to. In this case it's the choice of the user of the NR instance. If he decides to connect to a different server, he should be able to do so, and close the foreign connection therefore...

2 Likes
7

@dceejay
What do you think about this addon?
Or is there any other solution for getting a TCP Connection opened, and kept open with the chance to reset / reconnect if the connection gets dropped?
In my setup with the VPN connection a disconnected session doesn't get reconnected when I just resend the connection message...

Thanks!
Florian

8

Pull request raised here Let msg.reset reset Tcp request node connection when in stay connected mode by dceejay · Pull Request #4406 · node-red/node-red · GitHub

1 Like
9

Great! Thanks for raising!

10

Will this PR take account of the sesssion id property and only reset that connection?

11

This is the request node - so it is connecting out to only one place - so yes.

1 Like
12

Excellent then :slight_smile:

13

@dceejay
This is interesting.
If using the same server with different ports you can open up two (or maybe more) connections at a time. Is this meant to be or is this just coincidence?

14

true. need to check. I suspect in that case it will reset the last connection.

15

Would be good to have one of those options:

  • reset/drop all previous connections
  • reset/drop a defined connection (when sending the desired port)

I think, I would prefer the first option.

16

I wonder if its cleaner, to set reset to an id?
and pass this id on the output - so one can 'store' the ids - that they can then disconnect from so to speak?

(I'm just thinking out aloud)

EDIT
But then again - it only supports one active connection, if I am not mistaken

17

Looking at it some more.. it stores connections by a key of host:port so the sender already knows that info... so... we could...
if msg.reset set and no msg.host and/or msg.port set then close all.
if msg.reset and msg.host and msg.port then close that specific connection.

thoughts ?

EDIT: - this does mean that if you supply reset host and port then it won't close an old connection and restart a new one. it will just reset an existing one. (current fix behaviour is to close the last one and start a new one)

so yes maybe accepting msg.reset = host:port would let us target specific one.

1 Like
18

<Can of worms open>

Sorry - I got dibs on brain activity currently

reset:'last' /* Last Connected */
reset:'all'  /* All connection */

Examples:

/* Clears all - no new */
reset:'all'

/* Clears last - as well as creating a new one */
reset:'last',
port:4050,
host:'x.x.x.x'

Both off these can include the new host detail, and no matter what happens with reset, a connection with the new details will be made (if provided)

This would allow to purge all connections, without having to send 2 messages, to both clear all and start a new connection.

EDIT
I think you just addressed my suggestion with your edit :laughing:

19

that can never happen - you are in stay connected mode - it will try to reconnect to something - either the host:port specified in the config - or the one supplied... if not supplied and not in config it's an error.

1 Like
20

Well I'm just using session.id to direct messages at the moment

So, I'm taking in message with one session.id and then either replying to them using same id or changing it to another connections id to pass it on

I'm not storing address or port and reply node seems happy to just rely on session.id

So, I'd like to send msg.reset and msg._session.id and have the node work out the address:port