server: Reuse the raw socket #129
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #129 +/- ##
==========================================
- Coverage 42.62% 41.93% -0.69%
==========================================
Files 24 24
Lines 1342 1364 +22
==========================================
Hits 572 572
- Misses 679 701 +22
Partials 91 91
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I am OK with this behaviour |
|
This version should also cover #131 now |
Natolumin
force-pushed
the
raw_socket
branch
3 times, most recently
from
d37889f
to
3be5424
Compare
Creating, then destroying a raw socket for every packet is very heavy. We can open the socket and keep it when first opening the listening socket, so that we are able to reuse it This however requires knowing and binding to an interface at socket creation time (which is fairly standard for dhcpv4) due to a limitation of the library we use Signed-off-by: Anatole Denis <anatole@unverle.fr>
When deferring to the system routing, the ip address is automatically selected by the kernel. We were previously using the message's ServerIPAddr, but that is incorrect as a source address since that is the address of the next server, and not necessarily the address of the current server or an address that is routable by the client Signed-off-by: Anatole Denis <anatole@unverle.fr>
Signed-off-by: Anatole Denis <anatole@unverle.fr>
With the deprecation of mdhlayer/raw and its replacement with mdhlayer/packet, we lost BSD support for AF_PACKET sockets Since the server code degrades gracefully if tryOpenRawSock fails, compile a stub to let the server compile and start outside linux Signed-off-by: Anatole Denis <anatole@unverle.fr>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creating, then destroying a raw socket for every packet is very heavy. We can open the socket and keep it when first opening the (udp) listening socket, so that we are able to reuse the raw socket for further packets
Instead of managing the packet socket with manual syscalls, we can use the https://github.com/mdlayher/raw library (which we already imported before anyway) which will give us portability for free.
This does however mean that we cannot support dynamically setting the interface differently for each packet (at the moment) as the library requires an interface when binding to the socket; so this requires binding to a specific interface at startup (rather than relying on out-of-band data when receiving packets to choose the outgoing interface).
For DHCP servers this is a very common behavior (and we even required it until not that long ago) so I'm happy to take that tradeoff until we can update the upstream library to support the other usecase if needed.
Finally, if we can't setup the raw socket, we can then fallback to sending over broadcast (which is allowed by the RFC), ensuring that the server can keep working without for example CAP_NET_RAW