| 8.4 | Running ping like this is an easy way to see ICMP messages that are received by the host on which ping is being run. We reduce the number of packets sent from the normal one per second just to reduce the output. If we run our UDP client on our host aix, specifying the server's IP address as 192.168.42.1, and also run the ping program, we get the following output:
aix % ping -v -i 60 127.0.0.1
PING 127.0.0.1: (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0 ms
36 bytes from 192.168.42.1: Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0022 0007 0 0000 1e 11 c770 192.168.42.2 192.168.42.1
UDP: from port 40645, to port 9877 (decimal)
Note that not all ping clients print received ICMP errors, even with the -v flag.
|
| 8.6 | We run the sock program on the multihomed host freebsd, specifying the -u option (use UDP) and the -l option (specifying the local IP address and port).
freebsd % sock -u -l 12.106.32.254.4444 192.168.42.2 8888
hello
The local IP address is the Internet-side interface in Figure 1.16, but the datagram must go out the other interface to get to the destination. Watching the network with tcpdump shows that the source IP address is the one that was bound by the client, not the outgoing interface address.
14:28:29.614846 12.106.32.254.4444 > 192.168.42.2.8888: udp 6
14:28:29.615225 192.168.42.2 > 12.106.32.254: icmp: 192.168.42.2
udp port 8888 unreachable
|
| 8.8 | The largest IPv4 datagram is 65,535 bytes, limited by the 16-bit total length field in Figure A.1. The IP header requires 20 bytes and the UDP header requires 8 bytes, leaving a maximum of 65,507 bytes for user data. With IPv6 without jumbogram support, the size of the IPv6 header is 40 bytes, leaving a maximum of 65,487 bytes for user data. Figure E.9 shows the new version of dg_cli. If you forget to set the send buffer size, Berkeley-derived kernels return an error of EMSGSIZE from sendto, since the size of the socket send buffer is normally less than required for a maximum-sized UDP datagram (be sure to do Exercise 7.1). But if we set the client's socket buffer sizes as shown in Figure E.9 and run the client program, nothing is returned by the server. We can verify that the client's datagram is sent to the server by running tcpdump, but if we put a printf in the server, its call to recvfrom does not return the datagram. The problem is that the server's UDP socket receive buffer is smaller than the datagram we are sending, so the datagram is discarded and not delivered to the socket. On a FreeBSD system, we can verify this by running netstat -s and looking at the "dropped due to full socket buffers" counter before and after our big datagram is received. The final solution is to modify the server, setting its socket send and receive buffer sizes.
Figure E.9 Writing the maximum-sized UDP/IPv4 datagram.
udpcliserv/dgclibig.c
1 #include "unp.h"
2 #undef MAXLINE
3 #define MAXLINE 65507
4 void
5 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)
6 {
7 int size;
8 char sendline[MAXLINE], recvline[MAXLINE + 1];
9 ssize_t n;
10 size = 70000;
11 Setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));
12 Setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));
13 Sendto(sockfd, sendline, MAXLINE, 0, pservaddr, servlen);
14 n = Recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL);
15 printf("received %d bytes\n", n);
16 }
On most networks, a 65,535-byte IP datagram is fragmented. Recall from Section 2.11 that an IP layer must support a reassembly buffer size of only 576 bytes. Therefore, you may encounter hosts that will not receive the maximum-sized datagrams sent in this exercise. Also, many Berkeley-derived implementations, including 4.4BSD-Lite2, have a sign bug that prevents UDP from accepting a datagram larger than 32,767 bytes (line 95 of p.770 of TCPv2). |
