Explanation of java socket Parameter options

Explanation of java socket Parameter options
Java socket has many parameters to choose from. The purpose of this blog is to accumulate the semantics and usage of these parameters for future reference. 1. java socket Parameter options Overview The following Parameter options are available in JDK 0001: 1 public final static int TCP_NODELAY = 0 x; 2 3 public final static int SO_BINDADDR = 0x000F; 4 5 public final static int SO_REUSEADDR = 0x04; 6 7 public final static int SO_BROADCAST = 0x0020; 8 9 public final static int IP_MULTICAST_IF = 0x10; 10 11 public final static int IP_MULTICAST_IF2 = 0x1f; 12 13 public final static int IP_MULTICAST_LOOP = 0x12; 14 15 Public final static int IP_TOS = 0x3; 16 17 public final static int SO_LINGER = 0x0080; 18 19 public final static int SO_TIMEOUT = 0x1006; 20 21 public final static int SO_SNDBUF = 0x1001; 22 23 public final static int SO_RCVBUF = 0x1002; 24 25 public final static int SO_KEEPALIVE = 0x0008; 26 27 public final static int SO_OOBINLINE = 0x1003; 2. public final static int TCP_NODELAY = 0x0001; to understand this parameter, you must first To solve the Nagle algorithm, let's talk about the background generated by the Nagle algorithm 2.1. When there are a large number of packets transmitted in network transmission, the transmission efficiency will be seriously affected. For example, if a packet has a 40-byte header and the actual content has only one or several bytes (typically Telnet), the transmission efficiency is very low. The Nagle algorithm is designed to solve this inefficient transmission problem. 2.2 In general, the principle of the Nagle algorithm is to cache the bytes to be sent by the packet and transmit the data at a time when the threshold value reaches a certain value. The specific algorithm (Pseudo Code) is as follows: if there is new data to send if the window size> = MSS and available data is> = MSS send complete MSS segment now else if there is unconfirmed data still in the pipe enqueue data in buffer until an acknowledge is already ed else send data immediately end if end ifend if where MSS is short for maximum segment size, is a field in the TCP Header, indicating the maximum data Carrying Capacity of a TCP segment. 2.3 The Nagle algorithm causes obvious latency when transmitting large files. Therefore, it is best to disable this algorithm in this case. Once you understand the Nagle algorithm, you will understand the significance of the TCP_NODELAY parameter. If this parameter is set to True, it is to disable the Nagle Algorithm for non-delayed transmission. If it is set to false, this algorithm is used to cache the sent data. 3. public final static int SO_BINDADDR = 0x000F; obtain the local address of the socket to be bound (you cannot set this option to "get" only because the socket is bound at creation, so the address bound locally cannot be changed ). 4. public final static int SO_REUSEADDR = 0x04; this parameter indicates whether the socket can reuse the port. This socket option notifies the kernel. If the port is busy but the TCP status is TIME_WAIT, You can reuse the port. If the port is busy and the TCP status is in another State, an error message is still returned when the port is reused, indicating "The address is in use ". If you want to restart your service program immediately after it is stopped, and the new socket still uses the same port, the SO_REUSEADDR option is very useful. It must be realized that any unexpected data arrival at this time may lead to confusion in the response of the service program, but this is only a possibility, in fact, very unlikely. A socket is composed of five groups: Protocol, local address, local port, remote address, and remote port. SO_REUSEADDR only indicates that the local address and port can be reused. The entire quintuple is unique. Therefore, the restarted service program may receive unexpected data. The SO_REUSEADDR option must be used with caution. 5. public final static int SO_BROADCAST = 0x0020; this parameter is used to control broadcast. Currently, this parameter is only supported in DatagramSocket. 6. public final static int IP_MULTICAST_IF = 0x10; used to control multicast Parameter options. Currently, only the MulticastSocket supports setting multicast in the source code of MulticastSocket: public void setInterface (InetAddress inf) throws SocketException {if (isClosed () {throw new SocketException ("Socket is closed");} checkAddress (inf, "setInterface "); synchronized (infLock) {getImpl (). setOption (SocketOptions. IP_MULTICAST_IF, inf); infAddress = inf ;}} 7. public f Inal static int IP_MULTICAST_IF2 = 0x1f; the effect of this field is the same as above, but the extension supports IPV6 8 and public final static int IP_MULTICAST_LOOP = 0x12; this interface is used to set the multicast feature of the local loop interface. Related methods are available in the MulticastSocket source code: /*** Disable/Enable local loopback of multicast into rams * The option is used by the platform's networking code as a hint * for setting whether multicast data will be looped back to * local socket. ** <p> Because this option is a h Int, applications that want to * verify what loopback mode is set to shocould call * {@ link # getLoopbackMode ()} * @ param disable <code> true </code> to disable the LoopbackMode * @ throws SocketException if an error occurs while setting the value * @ since 1.4 * @ see # getLoopbackMode */public void setLoopbackMode (boolean disable) throws SocketException {getImpl (). setOption (SocketOptions. IP_MULTICAST_L OOP, Boolean. valueOf (disable);} 9, public final static int IP_TOS = 0x3; this parameter is used to control the TOS field in the IP header, is used to control and optimize the path of the IP package. There is a setting method in the Socket source code: /*** Sets traffic class or type-of-service octet in the IP * header for packets sent from this Socket. * As the underlying network implementation may ignore this * value applications shocould consider it a hint. ** <P> The tc <B> must </B> be in the range <code> 0 <= tc <= * 255 </code> or an IllegalArgumentException will be thrown. * <p> Notes: * <p> For Internet Protocol v4 the value consists of an octet * with precedence and TOS fields as detailed in RFC 1349. the * TOS field is bitset created by bitwise-or 'ing values such * the following: -* <p> * <UL> * <LI> <CODE> IPTOS_LOWCOST (0x02) </CODE> </LI> * <LI> <CODE> IPTOS_RELIABILITY (0x04) </CODE> </LI> * <LI> <CODE> IP TOS_THROUGHPUT (0x08) </CODE> </LI> * <LI> <CODE> IPTOS_LOWDELAY (0x10) </CODE> </LI> * </UL> * The last low order bit is always ignored as this * corresponds to the MBZ (must be zero) bit. * <p> * Setting bits in the precedence field may result in a * SocketException indicating that the operation is not * permitted. * <p> * As RFC 1122 section 4.2.4.2 indicates, a compliant TCP * implementation shoshould, But is not required to, let application * change the TOS field during the lifetime of a connection. * So whether the type-of-service field can be changed after the * TCP connection has been established depends on the implementation * in the underlying platform. applications shocould not assume that * they can change the TOS field after the connection. * <p> * For Internet Protocol v6 <code> tc </code> Is the value that * wocould be placed into the sin6_flowinfo field of the IP header. ** @ param tc an <code> int </code> value for the bitset. * @ throws SocketException if there is an error setting the * traffic class or type-of-service * @ since 1.4 * @ see # getTrafficClass */public void setTrafficClass (int tc) throws SocketException {if (tc <0 | tc> 255) throw new IllegalArgumentException ("tc I S not in range 0 -- 255 "); if (isClosed () throw new SocketException (" Socket is closed "); getImpl (). setOption (SocketOptions. IP_TOS, new Integer (tc);} according to the source code comment, whether the TOS settings take effect depends on the implementation of the underlying operating system. The application cannot guarantee that the change of TOS will affect the socket connection. I personally think that TOS is generally not used. 10. public final static int SO_LINGER = 0x0080; check the Socket source code:/*** Enable/disable SO_LINGER with the specified linger time in seconds. * The maximum timeout value is platform specific. ** The setting only affects socket close. ** @ param on whether or not to linger on. * @ param linger how long to linger for, if on is true. * @ exception SocketException if there is an error * in the underlying proto Col, such as a TCP error. * @ exception IllegalArgumentException if the linger value is negative. * @ since JDK1.1 * @ see # getSoLinger () */public void setSoLinger (boolean on, int linger) throws SocketException {if (isClosed ()) throw new SocketException ("Socket is closed"); if (! On) {getImpl (). setOption (SocketOptions. SO_LINGER, new Boolean (on);} else {if (linger <0) {throw new IllegalArgumentException ("invalid value for SO_LINGER");} if (linger> 65535) linger = 65535; getImpl (). setOption (SocketOptions. SO_LINGER, new Integer (linger) ;}} this field has an impact on the Socket close method. When this field is set to false, close will be executed immediately and return, if there are still unsent packets, these packets will be discarded. If it is set to True, a delay time can be set. The delay time is the time for close to actually execute all the Waits, up to 65535. 11. public final static int SO_TIMEOUT = 0x1006;/*** Enable/disable SO_TIMEOUT with the specified timeout, in * milliseconds. with this option set to a non-zero timeout, * a read () call on the InputStream associated with this Socket * will block for only this amount of time. if the timeout expires, * a <B> java.net. socketTimeoutException </B> is raised, though the * Socket is still valid. the optio N <B> must </B> be enabled * prior to entering the blocking operation to have effect. the * timeout must be> 0. * A timeout of zero is interpreted as an infinite timeout. * @ param timeout the specified timeout, in milliseconds. * @ exception SocketException if there is an error * in the underlying protocol, such as a TCP error. * @ since JDK 1.1 * @ see # getSoTimeout () */public synchronized void setS OTimeout (int timeout) throws SocketException {if (isClosed () throw new SocketException ("Socket is closed"); if (timeout <0) throw new IllegalArgumentException ("timeout can't be negative"); getImpl (). setOption (SocketOptions. SO_TIMEOUT, new Integer (timeout);} this parameter is used to control the timeout time for the client to read socket data. If timeout is set to 0, it will be blocked all the time, otherwise, the system directly throws a timeout exception after the timeout. 12. public final static int SO_SNDBUF = 0x1001; by default, the sending buffer of the output stream is 8096 bytes (8 K ). This value is the size of the output buffer recommended by Java. If the default value does not meet the requirements, you can use the setSendBufferSize method to reset the buffer size. 13. public final static int SO_RCVBUF = 0x1002; by default, the receiving buffer of the input stream is 8096 bytes (8 K ). This value is the size of the input buffer recommended by Java. If the default value does not meet the requirements, you can use the setReceiveBufferSize method to reset the buffer size. 14. public final static int SO_KEEPALIVE = 0x0008; if this parameter is set to True, the client sends a tentative data packet at intervals (generally not less than 2 hours, the server usually has three responses: 1. The server normally returns an ACK, which indicates that the remote server is okay, so the client will not close the connection, but will send a test packet in the next two hours. 2. The server returns an RST, which indicates that the remote server is down and the client closes the connection. 3. If the server does not respond to this packet, the client Socket will send another packet after about 11 minutes. If the server has not responded within 12 minutes, the client Socket will be closed. 15. public final static int SO_OOBINLINE = 0x1003; if this Socket option is enabled, you can use the sendUrgentData method of the Socket class to send a single-byte data to the server. This single-byte data is sent immediately instead of passing through the output buffer. Although the client does not use OutputStream to send data to the server, the single-byte data in the server program is mixed with other common data. Therefore, the server program does not know whether the data sent by the client is sent by OutputStream or sendUrgentData.