Chapter 15
15.1 | unlink removes the pathname from the filesystem, and when the client calls connect at a later time, the connect will fail. The server's listening socket is not affected, but no clients will be able to connect after the unlink. |
15.2 | The client cannot connect to the server even if the pathname still exists, because for the connect to succeed, a Unix domain socket must be currently open and bound to that pathname (Section 15.4). |
15.3 | When the server prints the client's protocol address by calling sock_ntop, the output is "datagram from (no pathname bound)" because no pathname is bound to the client's socket by default.One solution is to specifically check for a Unix domain socket in udp_client and udp_connect and bind a temporary pathname to the socket. This puts the protocol dependency in the library function where it belongs, not in our application. |
15.4 | Even though we force 1-byte writes by the server for its 26-byte reply, putting the sleep in the client guarantees that all 26 segments are received before read is called, causing read to return the entire reply. This is just to confirm (again) that TCP is a byte stream with no inherent record markers.To use the Unix domain protocols, we start the client and server with the two command-line arguments /local (or /unix) and /tmp/daytime (or any other temporary pathname you wish to use). Nothing changes: 26 bytes are returned by read each time the client runs.Since the server specifies the MSG_EOR flag for each send, each byte is considered a logical record and read returns 1 byte each time it is called. What is happening here is that Berkeley-derived implementations support the MSG_EOR flag by default. This is undocumented, however, and should not be used in production code. We use it here as an example of the difference between a byte stream and a record-oriented protocol. From an implementation perspective, each output operation goes into a memory buffer (mbuf) and the MSG_EOR flag is retained by the kernel with the mbuf as the mbuf goes from the sending socket to the receiving socket's receive buffer. When read is called, the MSG_EOR flag is still attached to each mbuf, so the generic kernel read routine (which supports the MSG_EOR flag since some protocols use the flag) returns each byte by itself. Had we used recvmsg instead of read, the MSG_EOR flag would be returned in the msg_flags member each time recvmsg returned 1 byte. This does not work with TCP because the sending TCP never looks at the MSG_EOR flag in the mbuf that it is sending, and even if it did, there is no way to pass this flag to the receiving TCP in the TCP header. (Thanks to Matt Thomas for pointing out this undocumented "feature.") |
15.5 | 15.5 Figure E.13 shows an implementation of this program.Figure E.13 Determine actual number of queued connections for differentbacklog values.debug/backlog.c
|