The multicasting of Network programming (I.)

Preface

This article is more, the author in order to save time, improve the efficiency of reading, will focus on the more simple implementation of multicast. And around that end, record some of the content in the UNP. 1. Multicast Addresses

Ipv4:class D addresses, in the range 224.0.0.0 through 239.255.255.255, is the multicast addresses in IPV4 (Figure A.3). The Low-order bits of a class D address form the multicast group ID and the 32-bit address is called the group address It's important to remember that the low 28 bits of the Class D address are multicast group IDs
This means, multicast addresses map to a single Ethernet address:the mapping are not one-to-one. The Low-order 2 bits of the first byte of the Ethernet address identify the address as a universally administered group AD Dress.
Universally administered means the high-order bits has been assigned by the IEEE and group addresses is recognized an D handled specially by receiving interfaces. 224.0.0.1 is the all-hosts group. All multicast-capable nodes (hosts, routers, printers, etc) in a subnet must join this group on all multicast-capable int Erfaces. 224.0.0.2 is the All-routers group. All multicast-capable routers on a subnet
Must join this group on all multicast-capable interfaces. 224.0.0.0 through 224.0.0.255 (which we can also write as 224.0.0.0/24) is called link Local. These addresses is reserved for low-level topology discovery or maintenance protocols, and datagrams destined to any of T Hese addresses is never forwarded by a multicast router.

Ipv6:the Low-order-bits of the first byte of the Ethernet address specify the address as a locally administered group Address.
Locally administered means there is no guarantee, the address is a unique to IPv6. There could be protocol suites besides IPV6 sharing the network and using the same High-order both bytes of the ether NET address. When the P flag is 0, the T flag differentiates between a well-known multicast group (a value of 0) and a transient multic AST Group (a value of 1). T-Flag distinguishes well-known multicast group and transient multicast group A P value of 1 designates A multicast address that's assigned B ased on a unicast prefix. If the P flag is 1, the T-flag also must be 1 (i.e., unicast-based multicast addresses was always transient), and the Plen and prefix fields is set to the prefix length and value of the unicast prefix, respectively. The upper-bits of this field is reserved. These two concepts are now not very specific understanding of the way, if you do not refer to other information ff01::2, Ff02::2 and Ff05::2 is the all-routers groups at Interface-local, Link-local, a nd site-local scopes. All routers to a subnet must join these groups on all multicast-capable intErfaces. Ff01::1 and Ff02::1 is the all-nodes groups at interface-local and link-local scope. All nodes (hosts, routers, printers, etc.) on a subnet must joins these groups on all multicast-capable interfaces.

2. Scope of multicast Addresses

As to the concept of this multicast domain, the descriptions in UNP are not well understood, and the following words can help to understand the following features: IPV6 multicast addresses has a explicit 4-bit scope field that Specifie s how "far" the multicast packet would travel. IPV6 packets also has a hop limit field that limits the number of the Times the packet are forwarded by a router. An interface-local datagram must is output by an interface and a link-local datagram must never is forwarded by a rout Er. IPV6 multicast addresses this differ only in scope represent different groups. 3. Multicasting versus broadcasting on a LAN

The process described above, UNP gives a specific description:The receiving application on the rightmost hostStarts and creates a UDP socket, binds port 123 to the socket, and then joins the multicast group 224.0.1.1. When this happens, the IPV4 layer saves the information internally and then tells the appropriate datalink to receive EThe Rnet frames destined to 01:00:5e:00:01:01. The recipient of the multicast message should first be added to the group corresponding to the multicast
The frame is received by the Datalink in the right based on the "What do we call imperfect filtering, which are done by the Interfa Ce using the Ethernet destination address.
This is imperfect because it's normally the case if the interface is told to receive frames destined to one specif IC Ethernet multicast address, it can receive frames destined to other Ethernet multicast addresses, too. There is ambiguity here, the author of this to see the Chinese version of the UNP, whose translation is ambiguous, is now understood as follows: Because the time to map Ethernet is only low 28 bits, so there may be more than one multicast address mapped to the same Ethernet multicast address the IP layer compares this addresses against all the Multicast addresses that applications on the this host has joined. We call this perfect filtering since it was based on the entire 32-bit class D address in the IPV4 header.The leftmost hostTo create a UDP socket and send a datagram to 224.0.1.1, Port 123. Nothing special was required to send a multicast datagram:the application does not having to join the multicast group. The sending host converts the IP address into the corresponding Ethernet destination address and the frame are sent. AssumeThe host in the middleis not IPv4 multicast-capable. This host ignores the frame completely because: the reason is one of the 3 people inside
The destination Ethernet address does not match the address of the interface; The destination Ethernet address is not the Ethernet broadcast address; The interface has no been told to receive any group addresses4. Multicast Socket Options

About the section here, the above image in order to achieve the author's first goal, only need to care about two options. ip_add_membership, Ipv6_join_group, Mcast_join_group:

struct Ip_mreq {
struct in_addr imr_multiaddr;/* IPV4 class D Multicast addr */
struct IN_ADDR imr_interface;/* IPV4 addr of local interface */
};
struct Ipv6_mreq {
struct in6_addr ipv6mr_multiaddr;/* IPV6 Multicast addr */
unsigned int ipv6mr_interface;/* I Nterface index, or 0 */
};
struct Group_req {
unsigned int gr_interface;/* interface index, or 0 */
struct sockaddr_storage gr_group;/* IPv 4 or IPV6 multicast addr */
}

Join an Any-source multicast group on a specified local interface. We specify the local interface with one of their unicast addresses for IPV4 or with the interface index for IPV6 and the pro Tocol-independent API. IPV4 uses a unicast address to represent the interface, and IPV6 uses the interface serial number, and here I don't quite understand why this difference
The change is made with the IPV6 and protocol-independent options to use a interface index to specify the interface inst EAD of the local unicast address that's used with IPV4 to allow joins on unnumbered interfaces and tunnel endpoints. Not here either. To explain this, just repeat the 1th above If The local interface is specified as the wildcard address for IPV4 (Inaddr_any) or as a index of 0 for IPV6, then a single local interface was chosen by the kernel. More than one join are allowed on a given sockets, but each joins must be-a different multicast address, or for the same multicast address but on a different interface from previous joins for the address on the this socket. The same socket can be joined to multiple multicast addresses, The site must be different, or the same multicast address corresponds to a number of different interfaces, each interface of course the socket is different. Ip_multicast_loop, Ipv6_multicast_loop:

Enable or disable local loopback of multicast datagrams. By default, loopback are enabled:a copy of each multicast datagram sent by A process on the host would also be looped back And processed as a received datagram by this host, if the host belongs to that multicast group on the outgoing interface. This Species of loopback also seen during the broadcast, the host received its own message.