Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
respondd: delay replies to multicast packages to avoid flooding the server #140
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
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. ;-)
Ah, nice one, thanks :)
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