Problems with UDP nodes

[Per Thomas Jahr]

Hi

I upgraded node-red to v0.12.1 and (Node.js v0.12.7) on my Raspberry Pi 2, but now I can't get my flow that uses UDP to work. For testing I now only have two nodes in one tab:

1. udp-out: sends a message to an IP and binds to local port 9999.

2. udp-in: listens for messages on port 9999.

This used to work fine, but now I get the following in the log:

15 Nov 14:29:46 - [info] Starting flows

15 Nov 14:29:46 - [info] [udp out:eb1b9dbf.14e46] node-red:udp.errors.ready

15 Nov 14:29:47 - [info] Started flows

15 Nov 14:29:47 - [error] [udp in:c676d976.398928] error: __error_

The problem seems to be that I use the same port number in udp-in and udp-out (9999), but I guess that is the only way to read from the UDP socket...

Any hints for what I can do to solve this?

Thanks

Per Thomas Jahr

[Per Thomas Jahr]

I got it to work by modifying the dgram.createSocket calls in 32-udp.js so that they use SO_REUSEADDR.

But I'm not at all sure that it is the correct solution...

[Dave C-J]

Seems reasonable to me. I don't think making reuse the default will break anything and would be more useful as you have pointed out. I'll double check and if OK will fix in a while.

[Dave C-J]

Hmm - slightly confused... the docs here - https://nodejs.org/docs/latest-v0.12.x/api/net.html

say - " (Note: All sockets in Node set SO_REUSEADDR already)  "

and a simple example works - you don't need to bind the output to the same port as it's the destination port that matters (in this case... unless you are talking two way...)

[{"id":"120d244.fedf2dc","type":"udp in","z":"9e538f88.61ac7","name":"","iface":"","port":"9000","ipv":"udp4","multicast":"false","group":"","datatype":"utf8","x":212,"y":1770,"wires":[["17ffa7c5.e80058"]]},{"id":"6ee882c1.91177c","type":"inject","z":"9e538f88.61ac7","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":229,"y":1718,"wires":[["2815e98f.d7ea16"]]},{"id":"17ffa7c5.e80058","type":"debug","z":"9e538f88.61ac7","name":"","active":true,"console":"false","complete":"false","x":484,"y":1769,"wires":[]},{"id":"2815e98f.d7ea16","type":"udp out","z":"9e538f88.61ac7","name":"","addr":"127.0.0.1","iface":"","port":"9000","ipv":"udp4","outport":"","base64":false,"multicast":"false","x":489,"y":1720,"wires":[]}]

[Per Thomas Jahr]

Almost like that, except I'm sending some content over UDP to remotehost:33333 and then binding to port 9000 because I then later will get some data back on that port (see updated flow). So that is why I have to bind to the local port.

Regarding the documentation: that seems to be for TCP only. In 32-udp.js this API seems to used: 

https://nodejs.org/api/dgram.html#dgram_dgram_createsocket_options_callback

I attached my diff where I also removed the "hack" to use a timeout (which seems to be exactly this problem):

- // Hack for when you have both in and out udp nodes sharing a port
- // if udp in starts last it shares better - so give it a chance to be last
- setTimeout( function() { server.bind(node.port,node.iface); }, 250);

It is confusing because it used to work for me and then I saw multiple problems with my Raspberry (which now seems to be the power supply). In the process I updated the firmware (rpi-update), all packages (deb and npm). So it is hard to say exactly what broke this.

My kernel version:

$ uname -a

Linux bod2 4.1.7-v7+ #817 SMP PREEMPT Sat Sep 19 15:32:00 BST 2015 armv7l GNU/Linux 

[{"id":"fc79bf67.03864","type":"udp in","z":"fb2f4229.04d0c","name":"","iface":"","port":"9000","ipv":"udp4","multicast":"false","group":"","datatype":"utf8","x":177,"y":195,"wires":[["41c5bd71.be3a44"]]},{"id":"d7189691.28e768","type":"inject","z":"fb2f4229.04d0c","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":194,"y":143,"wires":[["5bd39848.a42c68"]]},{"id":"41c5bd71.be3a44","type":"debug","z":"fb2f4229.04d0c","name":"","active":true,"console":"false","complete":"false","x":449,"y":194,"wires":[]},{"id":"5bd39848.a42c68","type":"udp out","z":"fb2f4229.04d0c","name":"","addr":"127.0.0.1","iface":"","port":"33333","ipv":"udp4","outport":"9000","base64":false,"multicast":"false","x":454,"y":145,"wires":[]}]

--

Per Thomas

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave C-J]

Hi,

yes - I have added the reuseAddr to the create socket by default now, removed the hack... (or actually moved it so it is only used when necessary on the client side. Seems a lot more solid now.

- and fixed the error messages.

Fix pushed to https://raw.githubusercontent.com/node-red/node-red/master/nodes/core/io/32-udp.js

if you want to just try that version.

[Per Thomas Jahr]

Hi

The new version didn't work that well. I get this error over and over:

node-red-0 (err): Error: Socket is already bound

node-red-0 (err): at Socket.bind (dgram.js:161:11)

node-red-0 (err): at null._onTimeout (/usr/lib/node_modules/node-red/nodes/core/io/32-udp.js:135:22)

node-red-0 (err): at Timer.listOnTimeout (timers.js:119:15)

--

[Dave C-J]

Hi - is it possible to share the main part of your flow with me ? (either via here or direct email ?) - I'm struggling to get my test case to fail now.

[Per Thomas Jahr]

I see now that there is something really wrong with the my rpi2 and the sd-card (multiple things failing). I will reinstall and come back to you.

man. 16. nov. 2015 kl. 23.30 skrev Dave C-J <dce...@gmail.com>:

Hi - is it possible to share the main part of your flow with me ? (either via here or direct email ?) - I'm struggling to get my test case to fail now.

--