Chapter 21
21.1 | When we run the program, there is no output. To prevent accidental reception of multicast datagrams that a server is not expecting, the kernel does not deliver multicast groups to a socket that has never performed any multicast operations (e.g., joining a group). What is happening here is that the destination address of the UDP datagram is 224.0.0.1, the all-hosts group that all multicast-capable nodes must join. The UDP datagram is sent as a multicast Ethernet frame and all the multicast-capable nodes receive the datagram since they all belong to the group. However, the kernel drops the received datagram since the process bound to the daytime port has not set any multicast options. |
21.2 | Figure E.14 shows a simple modification to the main function to bind the multicast address and port 0.Figure E.14 UDP client main function that binds a multicast address.mcast/udpcli06.c
Unfortunately, on the three systems on which this was triedFreeBSD 4.8, MacOS X, and Linux 2.4.7all allowed the bind and then sent the UDP datagrams with a multicast source IP address. |
21.3 | 21.3 If we do this from our host aix, which is multicast-capable, we get the following:
Both systems on the right-hand Ethernet in Figure 1.16 respond. To prevent certain denial-of-service attacks, some systems do not respond to broadcast or multicast pings by default. To get freebsd to respond, we had to configure it with |
21.5 | The value 1,073,741,824 is converted to a floating-point number and divided by 4,294,967,296, yielding 0.250. This is multiplied by 1,000,000, yielding 250,000, which in microseconds is one-quarter of a second.The largest fraction is 4,294,967,295, which divided by 4,294,967,296 yields 0.99999999976716935634. Multiplying this by 1,000,000 and truncating to an integer yields 999,999, the largest value for the number of microseconds. |