Unix Network Programming Episode 60

IPV6_CHECKSUM Socket Option

This socket option specifies the byte offset into the user data where the checksum
field is located. If this value is non-negative, the kernel will: (i) compute and store a
checksum for all outgoing packets, and (ii) verify the received checksum on input,
discarding packets with an invalid checksum. This option affects all IPv6 raw sockets,
except ICMPv6 raw sockets. (The kernel always calculates and stores the checksum
for ICMPv6 raw sockets.) If a value of -1 is specified (the default), the kernel will not
calculate and store the checksum for outgoing packets on this raw socket and will not
verify the checksum for received packets.

IPV6_DONTFRAG Socket Option

Setting this option disables the automatic insertion of a fragment header for UDP and
raw sockets. When this option is set, output packets larger than the MTU of the
outgoing interface will be dropped. No error needs to be returned from the system call
that sends the packet, since the packet might exceed the path MTU en-route. Instead, the application should enable the IPV6_RECVPATHMTU option (Section 22.9(See 9.11.9)) to learn about path MTU changes.

IPV6_NEXTHOP Socket Option

This option specifies the next-hop address for a datagram as a socket address structure, and is a privileged operation. We will say more about this feature in Section 22.8(See 9.11.8).

IPV6_PATHMTU Socket Option

This option cannot be set, only retrieved. When this option is retrieved, the current MTU as determined by path-MTU discovery is returned (see Section 22.9(See 9.11.9)).

IPV6_RECVDSTOPTS Socket Option

Setting this option specifies that any received IPv6 destination options are to be returned as ancillary data by recvmsg. This option defaults to OFF. We will describe the functions that are used to build and process these options in Section 27.5(See 9.16.5).

IPV6_RECVHOPLIMIT Socket Option

Setting this option specifies that the received hop limit field is to be returned as ancillary data by recvmsg. This option defaults to OFF. We will describe this option in Section 22.8(See 9.11.8).

There is no way with IPv4 to obtain the received TTL field.

IPV6_RECVHOPOPTS Socket Option

Setting this option specifies that any received IPv6 hop-by-hop options are to be returned as ancillary data by recvmsg. This option defaults to OFF. We will describe the functions that are used to build and process these options in Section 27.5(See 9.16.5).
IPV6_RECVPATHMTU Socket Option

Setting this option specifies that the path MTU of a path is to be returned as ancillary data by recvmsg (without any accompanying data) when it changes. We will describe this option in Section 22.9(See 9.11.9).

The rest of the option can be read in the books.

TCP Socket Options

TCP_MAXSEG Socket Option

This socket option allows us to fetch or set the MSS for a TCP connection. The value returned is the maximum amount of data that our TCP will send to the other end; often, it is the MSS announced by the other end with its SYN, unless our TCP chooses to use a smaller value than the peer’s announced MSS. If this value is fetched before the socket is connected, the value returned is the default value that will be used if an MSS option is not received from the other end. Also be aware that a value smaller than the returned value can actually be used for the connection if the timestamp option, for example, is in use, because this option occupies 12 bytes of TCP options in each segment.

TCP_NODELAY Socket Option

If set, this option disables TCP’s Nagle algorithm (Section 19.4 of TCPv1 and pp. 858–859 of TCPv2). By default, this algorithm is enabled.

The purpose of the Nagle algorithm is to reduce the number of small packets on a WAN. The algorithm states that if a given connection has outstanding data (i.e., data that our TCP has sent, and for which it is currently awaiting an acknowledgment), then no small packets will be sent on the connection in response to a user write operation until the existing data is acknowledged. The definition of a “small” packet is any packet smaller than the MSS. TCP will always send a full-sized packet if possible; the purpose of the Nagle algorithm is to prevent a connection from having multiple small packets outstanding at any time.

Another type of client that interacts badly with the Nagle algorithm and TCP’s delayed ACKs is a client that sends a single logical request to its server in small pieces. For example, assume a client sends a 400-byte request to its server, but this is a 4-byte request type followed by 396 bytes of request data. If the client performs a 4-byte write followed by a 396-byte write, the second write will not be sent by the client TCP until the server TCP acknowledges the 4-byte write. Also, since the server application cannot operate on the 4 bytes of data until it receives the remaining 396 bytes of data, the server TCP will delay the ACK of the 4 bytes of data (i.e., there will not be any data from the server to the client on which to piggyback the ACK). There are three ways to fix this type of client:

1.Use writev (Section 14.4(See 9.3.4)) instead of two calls to write. A single call to writev ends up with one call to TCP output instead of two calls, resulting in one TCP segment for our example. This is the preferred solution.
2.Copy the 4 bytes of data and the 396 bytes of data into a single buffer and call write once for this buffer.
3.Set the TCP_NODELAY socket option and continue to call write two times. This is the least desirable solution, and is harmful to the network, so it generally should not even be considered.