diff options
author | Chris Kuiper <ckuiper@google.com> | 2019-08-21 22:53:07 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2019-08-21 22:54:25 -0700 |
commit | 8d9276ed564ffef5d12426e839aeef7de5164d7d (patch) | |
tree | 460163aed957d3fb241016a69c975857d0feefa4 /CONTRIBUTING.md | |
parent | 5fd63d1c7fc8ea8d0aff30abc6403aa4491b6f81 (diff) |
Support binding to multicast and broadcast addresses
This fixes the issue of not being able to bind to either a multicast or
broadcast address as well as to send and receive data from it. The way to solve
this is to treat these addresses similar to the ANY address and register their
transport endpoint ID with the global stack's demuxer rather than the NIC's.
That way there is no need to require an endpoint with that multicast or
broadcast address. The stack's demuxer is in fact the only correct one to use,
because neither broadcast- nor multicast-bound sockets care which NIC a
packet was received on (for multicast a join is still needed to receive packets
on a NIC).
I also took the liberty of refactoring udp_test.go to consolidate a lot of
duplicate code and make it easier to create repetitive tests that test the same
feature for a variety of packet and socket types. For this purpose I created a
"flowType" that represents two things: 1) the type of packet being sent or
received and 2) the type of socket used for the test. E.g., a "multicastV4in6"
flow represents a V4-mapped multicast packet run through a V6-dual socket.
This allows writing significantly simpler tests. A nice example is testTTL().
PiperOrigin-RevId: 264766909
Diffstat (limited to 'CONTRIBUTING.md')
0 files changed, 0 insertions, 0 deletions