feat(sources): multicast udp socket support

[jorgehermo9]

Closes #5732

This PR is still in draft. I have a few pending TODOs and also missing tests to propertly check this. Although, the happy path is working.

In order to test this, use this vector config:

[sources.multicast_udp]
type = "socket"
mode = "udp"
address = "0.0.0.0:4242"
multicast_groups = ["224.0.0.2"]


[sinks.console]
type = "console"
inputs = ["multicast_udp"]
encoding.codec = "json"

and with this command

echo "hello" | nc 224.0.0.2 4242 -u

you can see logs in vector.

I would like to receive some feedback about how the configuration of this setting should look like.

Also, note that IPv6 is not supported. We can work on that, but maybe it is not worth it if no one request that.

@nomalord take a look into this please, It would be great if you can build the binary from this branch and test if it works in your systems.

@dalesample as you were the first requester of this I also ping you, just in case (although this issue was created 4 years ago)

[nomalord]

This looks awesome🤯
As it's new years I won't be able to check our usecase until Thursday...
I will say though, that this looks like it answers our usecase exactly🙏🙏🙏🙏🙏🙏

[jorgehermo9]

Hi @nomalord perhaps you could test this?

[nomalord]

I don't really have experience with rust, but I'll try to compile the feature branch and update you🥹

[pront]

I don't really have experience with rust, but I'll try to compile the feature branch and update you🥹

Maybe this is helpful to you:

# cd /path/to/vector/repo
# brew install gh 
gh pr checkout 22099
cargo run -- --config /path/to/your/config.yaml

[jorgehermo9]

Thank you for popping in @pront 😃. I have left to include some tests to validate this PR and also add documentation & changelog. I will update this as soon as I can and mark the pr as non-draft then

[jorgehermo9]

Hi @pront. Sorry for the delay, had no time these past weeks. Addressed all your comments and left a few doubts about the new changes. Feel free to resolve any conversation, just wanted to raise some things so you are aware of it.

Thanks!

[jorgehermo9]

small bump in case this got forgotten @pront, I think it is almost done.

[pront]

small bump in case this got forgotten @pront, I think it is almost done.

👍 I will take a look first thing tomorrow

[jorgehermo9]

Ready to go! Thanks @pront

CC @nomalord I hope you still need this, sorry for the delay!

[pront]

Unfortunately some windows tests failed:
https://github.com/vectordotdev/vector/actions/runs/13661566864/job/38193708090

[jorgehermo9]

Hm, It is surprising that multicast_and_unicast_udp_message fails but multicast_udp_message doesn't fail. Both uses 224.0.0.2 multicast address, so I don't think that address is the problem. The only difference is that multicast_and_unicast_udp_message sends an unicast packet after the multicast one here:

vector/src/sources/socket/mod.rs

Line 1409 in cdd37cd

send_lines_udp_from(from, socket_address, ["test".to_string()]);

But can't understand why it is not working if multicast_udp_message is. I can only think of next_addr_any returning an invalid address... But it makes no sense :/

Is there any easy way to run windows tests from linux? Or do I have to spin up a VM and configure everything there..?

What we could do is to flag that test behind #[cfg(unix)] or delete it completely, as I think that test is a bit redundant, as we have multicast_udp_message and udp_message tests though.

[jorgehermo9]

Can't understand why the error is happening, as we always bind to INADDR_ANY and not to an specific IP see google search for this error

[pront]

Or do I have to spin up a VM and configure everything there..?

I am afraid this is the way to go.

What we could do is to flag that test behind #[cfg(unix)] or delete it completely, as I think that test is a bit redundant, as we have multicast_udp_message and udp_message tests though.

I wonder if this feature works on Windows, sounds like we never tested it on there. I have a feeling ti does but we don't want to merge it without testing it. If you don't want to go down that rabbit hole, we can start by advertising it as linux only (and apply #[cfg(unix)] everywhere).

[jorgehermo9]

no problem, I will try to run it all on windows!