sin->sin_len = sizeof(struct sockaddr_in);
	

if (ifindex > 0) {
    mreq6.ipv6mr_interface = ifindex;
} else if (ifname != NULL) {
    if ( (mreq6.ipv6mr_interface = if_nametoindex(ifname)) == 0) {
        errno = ENXIO;  /* i/f name not found */
        return(-1);
    }
} else
    mreq6.ipv6mr_interface = 0;

if (ifi->ifi_flags & IFF_MULTICAST) {
    Mcast_join(sockfd, mcastsa, salen, ifi->ifi_name, 0);
    printf("joined %s on %s\n",
           Sock_ntop(mcastsa, salen), ifi->ifi_name);
}

Similarly the next line should be "plus 6 bytes for IPv6 (46 + 6 = 52)".

	str_echo(connfd);
	Close(connfd);
	

In the first printing, all is OK (other than the two figures appearing out of order, which is aesthetically incorrect) and there is nothing to fix, but the ordering will be corrected in the second printing.

In the first printing, all is OK (other than the two figures appearing out of order, which is aesthetically incorrect) and there is nothing to fix, but the ordering and the resulting references will be corrected in the second printing.

Banga, G., and Mogul, J. C. 1998. " Scalable Kernel Performance for Internet Servers under Realistic Loads," Proceedings of the 1998 USENIX Annual Technical Conference, pp. 1-12, New Orleans, LA.

I see two ways around this, when one line of input from the client can generate any amount of output from the server. First is to split the client into two processes (Figure 15.9) or two threads (Figure 23.1). Then each direction of data flow is totally independent of the other. The second is to change Figure 6.13 so that when the socket is readable, don't just read one line, but read everything that is in the socket's input buffer, and output that to standard output.

If you really wanted a lock-step approach, so that the client is not allowed to enter another request until all the server output has been received for the current request, then you need some way for the server to tell the client that its reply is complete. HTTP 1.0 essentially does this by using a separate TCP connection for each client request, and having the server close the connection to signify the end of each response.

Delete lines 21-22. Replace lines 31-37 with:

	if (++maxi == FD_SETSIZE)
		err_quit("too many clients");
	client[maxi] = connfd;

	sockfd = client[i];

	client[i--] = client[maxi--];

	#ifdef	HAVE_SOCKADDR_SA_LEN
		servaddr.sin_len = sizeof(servaddr);
	#endif

In this same function, the call to Fcntl on line 36 should really be moved between lines 41 and 42, to avoid the call in the case of an error.

The dg_cli function on page 485 that uses IPC has a similar problem: the signal can be delivered between recvfrom returning OK and storing the return value in n. This can be solved by turning off the alarm after select returns. Another exercise for the reader with Figure 18.10 is to not use alarm but use select's timer instead.

Second, there is no guarantee that the time between the call to alarm and the first call to sigsetjmp is less than the alarm time (5 seconds). One way around this is to set another flag after calling sigsetjmp and test this flag in the signal handler: if the flag is not yet set, do not call siglongjmp and just reset the alarm.

The bottom line here is that for robustness in these possible scenarios, avoid siglongjmp and use either pselect or the IPC method.

do {
    do {
        n = Recvmsg(fd, &msgrecv, 0);
    } while (n < sizeof recvhdr);

        /* calculate & store new RTT estimator values */
    rtt_stop(&rttinfo, rtt_ts(&rttinfo) - recvhdr.ts);
} while (recvhdr.seq != sendhdr.seq);

alarm(0);       /* stop SIGALRM timer */

Later, I was thinking what a really nice solution it is because it comes almost for free (in terms of bandwidth). That lead me to think about what would happen if heartbeats backed up on the sender (because of a closed send window, say). Specifically, I wondered whether some of the early urgent bytes could leak into to the main-band data.

I checked my kernel, and there didn't seem to be any protection on the send side--i.e., when a user sends urgent data, tcp_usr_send (in tcp_usrreq.c) just sets snd_up without worrying about any previous _unsent_ urgent bytes. There is a remark in tcp_input (see TCPv2, page 984, lines 1075-1078) that urgent bytes could indeed get into the user data if there were multiple urgent bytes pending.

I then changed one of the programs from unpv12e/oob to send 8192 bytes of '1' as normal data, an OOB byte ('2'), 1024 more bytes of '1' as normal data, and another OOB byte ('3'). I then changed tcprecv05.c to sleep 5 seconds and then read and print all the data it receives.

When I ran the two programs, sig_urg printed the value of 3, and the 2 was in the user data. All of this is a long winded way of saying that the heartbeat functions might lead to data corruption. It's pretty unlikely because two or more unsent urgent bytes have to back up on the send side, but it clearly can happen.

I can't think of a transparent way (i.e., without having to check the user data for a special byte etc.) to fix this other than having only one urgent byte in flight at a time. That is, rather than declaring a connection dead if 5 consecutive 3 second heartbeats are missed, send a heartbeat every 15 seconds and declare the connection dead if you don't get it back before the 15 second timer fires again.

A socket's offset can be very useful. In most UNIX dialects the offset comes from the file structure's f_offset. That structure member is incremented each time bytes are transferred to or from the file. So a changing offset value for a socket can mean that data transfers are taking place.

I use this feature to watch incoming ftp transfers with a custom Perl script that uses lsof field output and the lsof repeat feature. Usually I run it with the lsof repeat time set to 30 seconds, but here is some sample output for a test transfer from vic.cc to vic.cc and a 1 second repeat time:

=====
 3822    9r        0x600    1129991    28942
              /usr/ftp/pub/tools/unix/lsof/lsof_4.34_W.tar.Z
        10u   0x10169de8     901120      TCP
              vic.cc.purdue.edu:ftp-data->vic.cc.purdue.edu:listen
                                (ESTABLISHED QR=0 QS=4096)
=====
 3822    9r        0x600    1129991    28942
              /usr/ftp/pub/tools/unix/lsof/lsof_4.34_W.tar.Z
        10u   0x10169de8    1024000      TCP
              vic.cc.purdue.edu:ftp-data->vic.cc.purdue.edu:listen
                                (ESTABLISHED QR=0 QS=0)
=====

The fourth column is SIZE/OFF and you'll notice it increments as the ftp server pumps data to the ftp client.

Paxson, V. 1997. "End-to-End Routing Behavior in the Internet," IEEE/ACM Transactions of Networking, vol. 5, no. 5, pp. 601-615 (Oct.). ftp://ftp.ee.lbl.gov/papers/vp-routing-TON.ps.Z