Need help resolviing an issue for a custom node

I started creating a set of ICMP tools for listening/sending messages/packets.
So the node is based around the npm package ICMP.
On some deploys listen node works successfully, but on some deploys, the node is just stuck, I have a detailed explanation on GitHub with screenshots and possibly the main error that someone more experienced than me should look at it.

Link to the repo

Does that happen (more) after repeated deploys?

well sometimes it happens right when i start node-red , i inserted it now in a function and i am calling a function it looks okay for now...

Hi Vukmirovic,

I see this on your readme page: "When i ping localhost , the listen nodes receives two pings back with completly same output".

I haven't looked at your code in detail, but I had this kind of issues multiple times in the past...
You start listening to the packets, as soon as your node starts.
When you deploy your flow, your node starts again so your start listening again to the packets.
So now you have two listeners for the same packets, so your listeners will be called twice.
And so on...

Could that be your issue perhaps?
If so, you should stop listening for packets as soon as your node is closed (at a deploy).
Something like this:

node.on('close', function() {
    // Stop listening for packets
    icmp.close()
});

Bart

Well i think natuarly when pinging localhost that should happen because when :
0. ICMP is listening for ping.

  1. I ping localhost. (listen node sends output) icm protocol returns answer.
  2. icmp listen is returning the answer as second message
    The node.on close does help fix some issues , will test it further in the morning...

Added ICMP.close, when starting node-red sometimes it works right at the start , sometimes it needs to be redeployed,when you have time please check it out. I updated the repo.

  • See you call icmp.close at the end of the "input" event in the send.js file. Shouldn't you add there also a "close" event where you call icmp.close?
  • I see you use the dns-lookup - npm library, which hasn't been maintained for more than 4 years. If I were you, I should try to find an actively maintained library ...

No idea at first sight. Then I should have to debug, but other issues at the moment....
Could it be that you start listening too soon perhaps? Because you start listening when the flow is still starting (i.e. as soon as your node is being started). Otherwise you shouldn't start listening automatically, but allow start/stop listening via an input message. When msg.payload=true then you start listening (if not listening already), and when msg.payload=false you stop listening (if listening currently). With a simple boolean you can remember whether you are listening or not...
Then you can use an inject node that sends a message at startup automatically, to start listening. In that case you know at least that everything has been started already, before you start listening....

1 Like

Could it be that you start listening too soon perhaps? Because you start listening when the flow is still starting (i.e. as soon as your node is being started). Otherwise you shouldn't start listening automatically, but allow start/stop listening via an input message. When msg.payload=true then you start listening (if not listening already), and when msg.payload=false you stop listening (if listening currently). With a simple boolean you can remember whether you are listening or not...
Then you can use an inject node that sends a message at startup automatically, to start listening. In that case you know at least that everything has been started already, before you start listening....

I think that is a great solution , i too was woried that i was starting to listen too soon...
I think i could use your solution or add a sort of double check function that will ping localhost to check if the icmp.listen is working properly.
But as it is late and i need to get up early in the morning i will just write small ideas on a piece of paper for now , and hopefuly finish these nodes and publish them by the end of the week.

Once again thank you for your help!

1 Like

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