filter icmp id with sock_filter, to optimize rawsocket preformance

[nvksie]

rawsocket will receive all packets matching the target protocol, including replies to another ping on this host.
with sock_filter we can filter icmp reply packets, only accepting icmp replies that match the id in the sent packet.

[SuperQ]

This is an interesting optimization, I like it.

One thing I was thinking about recently is what happens to performance when users are running a lot of Pingers.

Currently we create a new socket for ever Pinger. I was wondering if this was causing us to do a lot of memory copies of all the incoming packets, most of which aren't matched by the listener. I haven't tested this, but if this is correct I was thinking about adding an option to create a single listener socket and pass that to each newly created pinger.

This may slightly conflict with this PR, as it also creates a filter for the packet ID.

But, this could easily be refactored later.

What do you think?

[nvksie]

Thanks!
Sharing a single socket among all Pingers in a single-process scenario is a great idea, as it reduces redundant memory copies and IRQ caused by multiple raw sockets. However, I believe sock_filter has more advantages. It rejects unexpected packets in kernel space, resulting in even fewer IRQs or memory copies to user space compared to a single raw socket. Additionally, it offers better performance in multi-process scenarios.

[nvksie]

Oh, I see! You mean using a single raw socket together with sock_filter? Maintaining a map to match ICMP IDs might make the BPF more complex, but it sounds more powerful!

[SuperQ]

My thought is that we can just remove the ID filter from the BPF. Just allow all ICMP packets to be read by the library.

[SuperQ]

Needs an error handler.

[nvksie]

Needs an error handler.

Done