Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
3 participants
@RalfJung
Copy link

commented Jun 23, 2016

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.

@NeoRaider

This comment has been minimized.

Copy link
Member

commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Author

commented Jun 24, 2016

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

This comment has been minimized.

Copy link
Author

commented Jun 25, 2016

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 comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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.

@rotanid rotanid closed this Nov 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.