Socket options are typically set through the following functions: GetSockOpt and SETSOCKOPT functions; fcntl functions; IOCTL functions
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>
int getsockopt ( int sockfd int level int optname
void * optval socklen_t * optlen
int setsockopt(int sockfd, int level, int optname,
const void * optval, socklen _t optlen);
SOCKFD points to a set of socket descriptors, level specifies the system Interpretation option code, Optval is a pointer to a variable, for setsockopt is a value parameter, and for getsockopt is a value-result.
Universal socket option so_keepalive socket option when the Keep-alive option is set for a TCP socket, there is no data exchange on either side of the socket within 2 hours, and TCP automatically sends a surviving detection section to the peer. It will result in the following 3 cases (1) The peer sends the expected ACK, the application process is not notified (because everything is OK), if there is still no movement after 2 hours, TCP sends a detection section (2) to the end of the RST response, to inform this side TCP: The end has been hung, and reboot. The socket's error is set to Econnreset, and the socket itself is closed. (3) There is no response to the end to keep alive detection sub-section, TCP will continue to send, until xx seconds to give up, the socket is set to etimeout, the socket itself is closed. If the socket receives an ICMP error as a response, it returns the corresponding error and the socket is closed. Error if it is host unreachable, the peer host may not crash, just unreachable. errno is set to Ehostunreach because of a network failure
So_linger socket Options This is the operation for the close function, generally close immediately returns, by default if there is data remaining in the socket send buffer, the system will attempt to send the data to the peer. Struct linger structure will change this default setting struct linger {int l-onoff;int L_linger;} (1) L_onoff as long as 0, is the default setting (2) L_onoff not 0 but linger is 0, when close, will discard any data saved in the socket send buffer, and send rst to each other, And generally there is no four-packet termination sequence. This avoids the time_wait state of TCP (3) If L_onoff is not a 0 value and L_linger is also a non-0 value, the kernel will stall for a while when the socket is closed. That means if the socket buffer has data, The process will be killed until the data is sent and an ACK or time-out is received. It is important for the application process to check the return value of close, if it is time. Returns a Ewouldblock error, and the data for the socket buffer is discarded
Tcp_nodelay socket option Turning on this option disables the TCP Nagle algorithm, which is the function of the Nagle algorithm to reduce the number of small packets in a WAN at a certain time, such as the data that a given connection needs to be determined, Then the response that was supposed to be a user write operation will not occur immediately after the connection is sent, until the data is confirmed the general Nagle algorithm is often used in conjunction with other TCP algorithms: ACK delay algorithm,The ACK delay algorithm causes TCP not to send an ACK immediately after receiving the data, but to wait for a short period of time before sending an ACK.TCP expects the data to be sent back to the peer during this short period of time, and the delayed ACK can be used to piggyback the data, thus eliminating a TCP subsection. This is possible for Telnet clients because their servers generally echo each byte sent by the client, so that the ACK to the client character can be returned on the service side of the echo character piggybackCons: However, for customers whose servers are not echoing content to carry an ACK, there is a problem with the ACK delay algorithm, and these customers may be aware of a noticeable delay because client TCP waits until the server's ACK delay timed out to continue sending data to the service. These clients need to suppress the Nagle algorithm. Tcp_nodelay play this role. another class of clients that are not suitable for using the Nagle algorithm with the ACK delay algorithm for TCP is to send small pieces of data. Not applicable to write-write-read this way. Http://www.blogjava.net/killme2008/archive/2011/06/30/353441.htmlWorkaround: (1) preferred to use Writev instead of two call to write, for this example, a single Writev call eventually leads to a call to the TCP output function once instead of two times, resulting in a TCP subsection (2) to copy the first 4 bytes followed by 396 of their own data into a single buffer, Then electrophoresis the buffer once write (3) Set tcp_nodelay socket option, continue to call write two times, this is the most undesirable method, and detrimental to the network
From for notes (Wiz)
7th Socket Options