dgram: setMulticastInterface() outgoing interface selection

[lostnet]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

dgram

Description of change

Add wrapper for uv's uv_udp_set_multicast_interface which provides the
sender side mechanism to explicitly select an interface. (The
equivalent receiver side mechanism is the optional 2nd argument of
addMembership().)

[santigimeno]

wrapping this with assert.throws will allow to remove the thrown variable

[santigimeno]

I don't know how difficult it would be to test, but would it be possible to test that the sender is indeed sending the multicast messages using the chosen interface?

[lostnet]

I don't know how difficult it would be to test, but would it be possible to test that the sender is indeed sending the multicast messages using the chosen interface?

It is very easy to test on a system where you can copy output from an ifconfig -a into your script and at least 2 real interfaces have been setup. For automated tests, its rather hard to get anyone to do the prerequisite manual system configuration.

My current test script (requires ifaces[] to be updated to match the system):
multitest.js.txt
(source of original)

[lostnet]

Thanks santigimeno, I've made improvements corresponding to each of your comments and verified "make -j4 test" against the new version. Please let me know how it looks.

[cjihrig]

Space after //. Also, Interface doesn't need to be capitalized.

[cjihrig]

Perhaps you could add a test similar to test/internet/test-dgram-multicast-multi-process.js.

[lostnet]

Thank you @cjihrig and @yorkie, I agree with, and believe I have addressed all the comments in this second set of review changes.

On test-dgram-multicast-multi-process.js:
I've added default interface selection and explicitly to the membership in that test to show that they do no harm. But the only ways I've seen to test that this kind of network setting isn't always doing a NO-OP is with test frameworks that have either a privileged system configuration stage or a configuration verification stage where they decide if they can test opportunistically. (The test framework has to know what a real non-default interface's IP is and that it isn't physically on the same physical network as the default network or all packets get received simply since there isn't an alternative.)

Please let me know what you think, and if I've missed or misunderstood anything on the other changes,
Will

[yorkie]

filename in test/parallel should be in lower-case?

[lostnet]

I like the order with regards to dgram-multicast for tab completion and relatedness, so maybe:
test/parallel/test-dgram-multicast-set-interface.js ?
(set_if is the only lowercase I would parse as an IF ioctl and IMO mixing '-'&'' is worse than mixed case.)

[jasnell]

This should likely include some additional detail about when this method should be called and what the side effects are.

[lostnet]

I've added a significant amount of detail (and hopefully used subsections correctly?) But I've intentionally left the question of exactly when a socket is first ready unanswered since it would be redundant to repeat libuv's unusual need to bind before socket operations for every operation.