* SO_BROADCAST
This option enables or disables the ability of a process to send broadcast messages. Broadcasting is only supported on datagram sockets, and must also be on networks that support broadcast messages (eg, Ethernet, Token Ring, etc.), not on point-to-point links. EACCES errors will be slowed down when the destination address is a broadcast address but this option is not set.
* SO_DEBUG
This option is only supported by TCP. When this option is turned on for a TCP socket, the kernel will keep detailed traces of all packets sent and received by TCP on that socket. This information is kept in one of the kernel's ring buffers and can be inspected using the trpt program.
* SO_DONTROUTE
This option specifies that outgoing packets will bypass the normal routing mechanism of the underlying protocol. Outgoing packets such as IPv4 are directed to the local interface determined by the network and subnet parts of their destination address. If such a local interface cannot be determined from its destination address (eg, the destination host is not on the other end of a point-to-point link, nor on a shared network), an ENETUNREACH error will be returned. Using the MSG_DONTROUTE flag for the functions send, sendto, or sendmsg also has the same effect as this option on individual datagrams. Routing daemons (routed and gated) often use this option to bypass routing tables (when the routing table is incorrect) to force packets to be sent out a specific interface.
* SO_ERROR
This option can be obtained but not set. When an error occurs on a socket, the protocol module in the Berkeley-derived kernel sets the socket's variable named so_error to one of the standard Unix_Exxx values, called the socket's pending Handling errors. The kernel can immediately notify the process of this error in one of two ways.
(1) If a process is blocked on a select call on that socket, then whether checking for a readable or writable condition, select returns and sets one or both of the conditions.
(2) If the process uses the signal-driven I/O model, generate a SIGIO signal to the process or process group.
The process can then obtain the value of so_error by accessing the SO_ERROR socket option. The integer value returned by getsockopt is the pending error for this socket. so_error is then reset to 0 by the kernel. When the process calls read and no data is returned, if so_error is non-zero, then read returns -1 and errno is set to the value of so_error, which is then reset to zero. When a process calls write, it calls read.
* After SO_KEEPALIVE
sets the keep alive option for a TCP socket, if there is no data exchange in either direction of the socket within 2 hours, TCP will automatically send a keep alive detection section to the peer, which will cause the following three one of the situations.
(1) The peer responds with the expected ACK, and the application process cannot receive the notification at this time.
(2) The peer responds with RST, indicating that the peer has crashed and has been restarted. Pending errors for the socket are set to ECONNRESET, and the socket itself is closed.
(3) The peer does not respond to the keep alive probe section. At this point the TCP from Berkeley will send up to 8 additional probe segments.
If there is no response to TCP's probe section at all, the socket's pending error is set to ETIMEOUT and the socket itself is closed. And if the socket receives an ICMP error in response to a probe section, the corresponding error is returned and the socket itself is closed. A common ICMP error is "host unreachable", in which case pending errors are set to EHOSTUNREACH.
The following figure is a summary of the various detection methods that can be used when certain events occur on the other end of a TCP connection.
* SO_LINGER
This option specifies how the close function operates on connection-oriented protocols. The default is that close returns immediately, but if there is data remaining in the socket send buffer, the system will try to send the data to the peer. This default setting can be changed with this option, which requires the following structure to be passed between the user process and the kernel.
#include <sys/socket.h>
struct linger{
int l_onoff; // 0xoff, nonzero = on
int l_linger; // linger time, POSIX specifies units as seconds
};
A call to setsockopt will result in one of the following 3 cases depending on the values of two of the structure members.
(1) If l_onoff is 0, this option is turned off, l_linger is ignored, the default setting takes effect, and close returns immediately.
(2) If l_onoff is not 0 and l_linger is 0, then when a connection is closed, TCP will terminate the connection. This means that TCP will discard the data remaining in the socket send buffer and send an RST peer without the usual four-packet connection termination sequence and without TCP's TIME_WAIT state, which may result in 2MSL seconds Another incarnation of that connection created within receives an old duplicate section. In this case SCTP also terminates the association by sending an ABORT block to the peer.
(3) If neither l_onoff nor l_linger is 0, the kernel will delay for a period of time when the socket is closed, until the data in the send buffer is sent and both are confirmed or the delay time expires. However, non-blocking sockets do not wait for close to complete, even if the latency is non-zero. If this feature is used, it is necessary to check the return value of close. Because if the delay expires before the data is sent and acknowledged, close will set errno to EWOULDBLOCK and any residual data in the socket send buffer will be discarded. It should be noted here that the successful return of close only indicates that the previously sent data has been confirmed by the peer, but it cannot tell whether the peer has read the data. One way to know that the peer has read its queued data is to call the shutdown function with the second parameter set to SHUT_WR, followed by a read call to read until the peer's FIN is received. Another method is to call read before calling close to read until some flag data appears. This is generally called applying ACK. The following figure shows the possible packet exchange process.
The following table summarizes the two possible calls to shutdown and the three possible calls to close, and their effect on TCP sockets.
* SO_OOBINLINE
When this option is turned on, out-of-band data will be left in the normal input queue (ie online retention). In this case the MSG_OOB flag of the receive function cannot be used to read out-of-band data.
* SO_RCVBUF and SO_SNDBUF
Each socket has a send buffer and a receive buffer. The receive buffer is used by TCP, UDP and SCTP to hold received data until the application process reads it. For TCP, the size of the available space in the socket receive buffer limits the window size that TCP advertises to the peer. Due to TCP's flow control, it is impossible for the TCP socket receive buffer to overflow, and the data exceeding the advertised window size will be discarded by the local TCP. For UDP without flow control, when the received datagram does not fit into the socket receive buffer, the datagram will be discarded. This means that a faster sender can easily overwhelm a slower receiver, causing the receiver's UDP to drop datagrams.
These two options can be used to change the default size of these two buffers. The order of function calls is important when setting the size of the TCP socket receive buffer. Because the TCP window size option is obtained by exchanging the SYN section with the peer when establishing a connection, this means that the SO_RCVBUF option must be set before calling connect and listen. Setting this option for a connected socket has no effect on possible window size options, because accept does not create and return a connected socket until the TCP three-way handshake is complete. The size of the socket buffer is always inherited from the listening socket by newly created connected sockets.
The size of the TCP socket buffer should be at least four times the MSS value of the corresponding connection, based on how the TCP fast recovery algorithm works. The TCP sender uses three repeated acknowledgments to detect if a segment is lost. After finding that a segment is missing, the receiver will send a duplicate acknowledgment for each segment received. Therefore, if the window size is not large enough to hold four such segments, it is impossible to send three repeated acknowledgments in a row, and thus the fast recovery algorithm cannot be activated. Additionally, to avoid potential wasted buffer space, the TCP socket buffer size should also be an even multiple of the corresponding connection's MSS value, since space in the socket buffer beyond the MSS size will not be used. Some implementations handle this detail for the application process by rounding up the socket buffer size after the connection is established, which is one reason why these two socket options should be set before establishing the connection.
* SO_RCVLOWAT and SO_SNDLOWAT
each socket also has a receive low water mark and a send low water mark, which are used by the select function. The receive low water mark is the amount of data required in the socket's receive buffer when select returns "readable", and the send low water mark is the amount of data required in the socket send buffer when select returns "writable" Available space.
* The SO_RCVTIMEO and SO_SNDTIMEO
options allow to set a timeout value for socket sending and receiving.
* SO_REUSEADDR and SO_REUSEPORT
SO_REUSEADDR can play the following 4 different functions.
(1) It allows to start a listening server and bind its well-known port, even if previously established connections using that port as their local port still exist. This condition is usually encountered like this:
a) start a listening server;
b) A connection request arrives, fork a child process to handle the client;
c) The listening server terminates, but the child process continues to serve clients on existing connections;
d) The listening server is restarted.
By default, when the listening server is restarted at step d by calling socket, bind and listen, bind will attempt to bind a port on an existing connection (that is, the connection being handled by the child that was spawned earlier). fail. But if the server sets SO_REUSEADDR between the socket and bind calls, then the bind will succeed. Generally all TCP servers should specify this socket option to allow the server to be restarted in this situation.
(2) SO_REUSEADDR allows multiple instances of the same server to be started on the same port, as long as each instance is bundled with a different local IP address. When there is a wildcard address in the binding address, in order to prevent a malicious server from being bound to the IP address and port being used by a system service, resulting in interception of legitimate requests, the server process that performs wildcard address binding should be placed in The last one to start.
(3) SO_REUSEADDR allows a single process to bind the same port to multiple sockets.
(4) SO_REUSEADDR allows completely duplicated binding: when an IP address and port are bound to a socket, the same IP address and port can be bound to another socket if the transport protocol supports it. However, this feature generally only supports UDP sockets. When used for multicast, this feature allows multiple copies of the same application to run concurrently on the same host.
The SO_REUSEPORT option is not supported by all systems, and it mainly introduces the following semantics:
(1) This option allows completely repeated binding, but only if each socket that wants to bind the same IP address and port specifies this socket option only.
(2) If the bundled IP address is a multicast address, this option is considered equivalent to SO_REUSEADDR.
* SO_TYPE
This option returns the type of socket (such as SOCK_STREAM, etc.), which is usually used by processes that inherit sockets at startup.
* SO_USELOOPBACK
This option is only used for sockets in the routing domain (AF_ROUTE). For these sockets it defaults to on (this is the only SO_xxx binary socket option that defaults to on). When this option is on, the corresponding socket will receive a copy of any datagrams sent on it (another way to disable these loopback copies is to call shutdown with SHUT_RD as its second parameter).