Fix multicast send

[etiktin]

I had a consistent issue on Windows with multicast send, where it didn't really send on all available network interfaces. Once I added the interface address to mc.bind it started working on all of them.

According to the docs binding without an address should try to listen on all interfaces, but it doesn't work reliably. In any case, we're already iterating on all available interfaces (IPv4 and not internal) and calling bind, so being explicit about the interface address makes sense (that's also what we're doing in uc.bind).

[louaybassbouss]

Thx @etiktin for reporting the issue on this. The problem is that the behavior of UDP socket implementation is different across platforms and Node.js versions. Can you please tell us which Node.js version are you using?

[etiktin]

I'm using node v0.12.7 32 bit on Windows 8.1 64 bit. My network interfaces are (I have more but they are disabled):

{ 'Wi-Fi':
   [ { address: '192.168.43.125',
       netmask: '255.255.255.0',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'Loopback Pseudo-Interface 1':
   [ { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true },
     { address: '127.0.0.1',
       netmask: '255.0.0.0',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }

Using the code that didn't set the interface address explicitly, sending NOTIFY was executed only on the loop back interface instead of WiFi. When we pass the interface address to the bind method, everything works correctly (send is executed only on the WiFi interface).

In the code, we're selecting all IPv4 interfaces that are not internal, but then we let it bind to all available interfaces... It kind of looks like a simple oversight (it's very easy to miss). For unicast sockets we do pass the interface selection and they work correctly for me (see here).

[etiktin]

@louaybassbouss did you see my last comment?

[louaybassbouss]

@etiktin do you still have the problem on newer Node versions

[etiktin]

@louaybassbouss I'm no longer working on that project, so I don't know if the issue exists in newer versions. That said, I do know that the current maintainers still use the fix without any issues with Node.js v4. In any case I think being explicit about the address still makes sense for the reasons mentioned perviously.