Implement UdpChannelFactory, UdpChannel, and UdpFace.
- create a UdpChannel for unicast communication on a local endpoint
If a UdpChannel with the same local endpoint exists, that one should be returned.
- create a UdpFace for multicast communication on a multicast group and port number via a local NIC
Only IPv4 multicast is supported.
If a multicast-UdpFace of the same multicast group, port number, and local NIC exists, that one should be returned.
A local port number can be used to create either one or more unicast channel with different local IPs, or one or more multicast faces on different NICs.
Creation should fail on violation of this rule.
UdpChannel represents a local endpoint (IP:port tuple). It can
- create a UdpFace for unicast communication with one remote endpoint
If a unicast-UdpFace with the same remote endpoint exists, that one should be returned.
- listen on the local endpoint for incoming packets not received by unicast-UdpFace, and create new unicast-UdpFace for new remote endpoint
UdpChannel should have a socket bind(2) to local endpoint but without connect(2) for this purpose.
UdpFace represents either a point-to-point tunnel (unicast) or a broadcast tunnel (multicast).
A unicast-UdpFace should have a socket that is bind(2) to local endpoint and connect(2) to remote endpoint,
so that kernel will dispatch incoming packets from the specific remote endpoint to this socket.
A multicast-UdpFace should have one or two sockets as necessary
to receive packets sent to the specific multicast group and port number via the specific local NIC,
and to send packets to the specific multicast group and port number via the specific local NIC.
Updated by Alex Afanasyev about 7 years ago
We had conversation about the UDP face before, but seems that I didn't put the conclusion of that into this issue.
UdpFaceChannel should use system-provided dispatching of incoming packets to the right destination, meaning that we should not do this dispatch manually in the channel. Similar to TCP channel we still should keep map of created channels, but it should be for completely different purpose (to remember previously created faces to the same endpoints).
Updated by Junxiao Shi about 7 years ago
- Estimated time set to 18.00 h
20140221 conference call decides that only accepted UdpFace should be deleted when idle; faces initiated by this channel shouldn't be deleted.
I'm separating the idle-delete feature to Task #1281 so that the basic features can be delivered earlier.