respondd: delay replies to multicast packages to avoid flooding the server

[RalfJung]

Right now, when a multicast respondd request it sent to the network, all nodes respond at once. This is (in a network with 400 nodes) almost one megabyte of data arriving within a very short timeframe. As a result, the UDP receive buffers of the server fill up and packets are dropped.

This patch adds a random delay of up to one second before replying to a multicast packet. Unicast requests are not affected. To achieve this, I had to use recvmsg instead of recvfrom, which complicated things "a little". I am not very familiar with recvmsg or C socket programming in general, so maybe someone who knows more should check this. ;-) I tested this in a KVM machine where everything worked as expected.

[neocturne]

As respondd is single-threaded, blocking using usleep is a bad idea. You should rather maintain a list of requests and use some kind of timer to trigger sending the data.

To check for multicast addresses, you can use IN6_IS_ADDR_MULTICAST().

[RalfJung]

As respondd is single-threaded, blocking using usleep is a bad idea. You should rather maintain a list of requests and use some kind of timer to trigger sending the data.

I agree it is suboptimal. However, we don't expect large masses of requests at once. Also, in our network, I would say the additional "stacking" effect of the different delays is actually desired. If two multicast requests come it at once, this stretches the replies instead of waiting concurrently.

EDIT: In other words, this adds some form of rate-limiting.

Doing a timer would require reworking the entire deamon to a more asynchronous model, right? I don't really know how to write such a daemon properly. (Well, "properly" would imply using libevent or so, but that's not an option here. ;-)

To check for multicast addresses, you can use IN6_IS_ADDR_MULTICAST().

Ah, nice one, thanks :)

[RalfJung]

An alternative to the asynchronous approach would be to use multi-threading: For a delayed response, spawn a new thread and let that do the sleep; send. For me, that would be easier to code -- and considering the low number of expected requests, the slightly higher overhead (spawning a thread is comparatively cheap on Linux, but not for free) should be acceptable.

[rotanid]

this has been replaced by #144 the way i see it, also it would need to be based on master branch, not v2016.1.x
closed.