that is the in/out/reply pair... this is about the request node...
edit: hmm starting back at the start .. indeed it is about both... so more extensive fix needed... doh.
1 Like
@cymplecy - so in your case it's the in/reply pair. If we let msg.reset === true (and you already set _session.id or not) then if we kill the connection (so no reply can be sent, ie any payload will be dropped) - and also the client is then free to reconnect if it wants.... presumably that is ok.
Sounds good 
PR - updated - thanks all for the good discussion.
Now
-
request node
msg.reset = true; - resets all connections;.
msg.reset = "host:port"; - just resets that specified connection. -
Out node in reply mode
msg.reset = true; and no msg._session.id - resets all clients;
msg.reset = true; and msg._session.id is set - resets specified client.
3 Likes
Just copied your PR into an instance and it does what it says on the packet - pun intended
It force closed my MQTT connection
And then when the MQTT client tried to reconnect - it did so.
And then when I tried to force disconnect again - it didn't work - which was right because I was using the 1st _session.id value in my inject node
updated to new _session.id and it disconnected again
[edit]Additionally - made another connection from MQTT Explorer and then sent the disconnect to it with its _session.id and it disconnected but my other connection stayed up
2 Likes
That's great to hear. Thanks for the validation.
1 Like
Could I some more please....
...cough websocket node as well
.....runs away VERY quickly......
too late - it's past gin o'clock... (in this house)
2 Likes
Let's not start this again! 
Hey - it's Friday ! just a fact...
1 Like
Dang I have to wait another couple hours again!
If its passed 10AM - your fine
Liquid Brunch!
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
