Getsockopt/setsockopt function description (2)

This operation mode of so_linger is controlled by the linger structure:
Struct linger {
Int l_onoff;
Int l_linger;
};
Rochelle off is a Boolean value. A non-zero value indicates true, while a zero value indicates false. The three values of this option are described as follows:

1. If l_onoff is set to false, the member l_linger is ignored and the default close behavior is used. That is to say, the close call will be immediately returned to the caller, and if possible, any unsent data will be transmitted.
2 setting Rochelle off to true makes the value of member Rochelle linger important. When l_linger is not zero, this indicates the timeout time in seconds for the application to call the close function. If unsent data exists before the timeout occurs and is disabled successfully, the function returns a success response. Otherwise, an error is returned, and the variable errno is set to ewouldblock.
3. If l_onoff is set to true and l_linger is set to zero, the connection is aborted. When close is called, any data sent is discarded.

We may want some suggestions to use the so_linger option in our program and provide a reasonable timeout period. Then, you can check the return value of the close function to determine whether the connection is successfully closed. If an error is returned, the remote program may not be able to receive all the data sent by us. Relatively, it may only mean that the connection is closed.

However, we must stay awake. This method will lead to new problems in some server design. When the so_linger option is configured as a timeout (linger) in the call to the close function, other clients are blocked when the close function call times out. This problem occurs if we are serving multiple client processes in a process. It may be more appropriate to use the default behavior, because this allows the close function to return immediately. Any unsent data will be sent to the kernel.

Finally, if the program or server knows when the connection should be terminated, the stop action can be used. This may apply when the server considers that the user is not authorized to access the server and is trying to access the server. In this case, customers will not receive special attention.

 

The following code uses the so_linger option as an example, with a 30-second timeout period:
# Define true 1
# Define false 0
Int Z;/* Status Code
*/INT s;/* socket S */
Struct linger so_linger;
...
So_linger.l_onoff = true;
So_linger.l_linger = 30;
Z = setsockopt (S,
Sol_socket,
So_linger,
& So_linger,
Sizeof so_linger );
If (z)
Perror ("setsockopt (2 )");

The following example shows how to set the value of so_linger to stop the current connection on interface s:
# Define true 1
# Define false 0
Int Z;/* Status Code */
Int s;/* socket S */
Struct linger so_linger;
...
So_linger.l_onoff = true;
So_linger.l_linger = 0;
Z = setsockopt (S,
Sol_socket,
So_linger,
& So_linger,
Sizeof so_linger );
If (z)
Perror ("setsockopt (2 )");
Close (s);/* abort connection */

In the preceding example, when the close function is called, the set interface S is immediately suspended. The meaning of abort is achieved by setting the timeout value to 0.

Set so_kkepalive

When using the connection, sometimes they will be idle for a long time. For example, create a telnet session to access the stock trading service. He may execute some initial queries and leave the connection to keep the service open, because he wants to return to query more content. However, the idle state of simultaneous connection processing may be one hour at a time.

Any server will assign resources to a connected customer. If the server is a derived type (fork), the entire Linux Process and its corresponding memory are allocated to this customer. If everything goes well, this scenario will not cause any problems. However, when the network crashes, the difficulty arises. All of our 578 customers will lose connection from our stock trading service.

After the network service is restored, 578 customers will try to connect to our server and rebuild the connection. This is a real problem for us, because our server did not realize that it had lost its idle client-so_kkepalive to solve this problem.

The following example shows how to use the so_kkepalive option on the set interface s, so that a disconnected idle connection can be detected:
# Define true 1
# Define false 0
Int Z;/* Status Code */INT s;/* socket S */
Int so_keepalive;
...
So_keepalive = true;
Z = setsockopt (S,
Sol_socket,
So_keepalive,
& So_keepalive,
Sizeof so_keepalive );
If (z)
Perror ("setsockopt (2 )");

In the above example, the so_keepalive option is set, so that when the set of interface connection is idle for a long time, a probe message will be sent to the remote end. This is usually completed after two hours of no activity. There are three possible responses to the detection information of a persistence activity. They are:
The first end will return an appropriate response to indicate that everything is normal. No indication is returned to the program because this is the beginning of the program's assumption.
The 2-end response indicates that he has no idea about the connection. This indicates that the client has reconnected to the host since the last communication. In this way, the econnreset error code will be returned to the program in the next interface operation.
The third end has no response. In this case, the kernel may have made several attempts to connect. If the request is not responded, TCP usually gives up in about 11 minutes. In this case, the etimeout error is returned in the next interface operation. Other errors, such as ehostunreach, are returned when the network no longer reaches the host.

The time framework called by so_keepalive limits its common use. The probe information is sent only after about two hours of inactivity. Then, when there is no response, it will take another 11 minutes for the connection to return an error. In any case, this option does allow detection of idle connectionless interfaces and is then disabled by the server. Correspondingly, servers supporting long idle connections should allow this feature.

Set so_broadcast options

We have not discussed topics that use UDP for broadcast. However, we are easily aware of the misuse of broadcast functions and the resulting network disasters. To avoid broadcasting when no broadcast is scheduled, the broadcast function is disabled for the set interface. If broadcast is required, the C programmer must handle the corresponding troubles for this function of the Set interface.

So_broadcast is a Boolean flag that is set by the int data type. The following example shows how to set the so_broadcast option:
# Define true 1
# Define false 0
Int Z;/* Status Code */
Int s;/* socket S */
Int so_broadcast;
...
So_broadcast = true;

Z = setsockopt (S,
Sol_socket,
So_broadcast,
& So_broadcast,
Sizeof so_broadcast );
If (z)
Perror ("setsockopt (2 )");
If you want the setsockopt function to return zero, set interface s to allow broadcasting. However, it is important to note that the selected set of interface types must have broadcast functions, such as UDP sets of interfaces.

Set so_oobinline

In some cases, the amount of data sent may exceed the limit. Generally, these out-of-bounds data are received by different data receiving functions. However, sometimes they prefer to use the usual method to receive the cross-border data. When this method is selected, the out-of-boundary data arrives before the normal data as part of the normal data flow.

To use this feature, we can use the following code:
# Define true 1
# Define false 0
Int Z;/* Status Code */
Int s;/* socket S */
Int so_oobinline;
...
So_oobinline = true;
Z = setsockopt (S,
Sol_socket,
So_oobinline,
& So_oobinline,
Sizeof so_oobinline );
If (z)
Perror ("setsockopt (2 )");
After the so_oobinline option is set, the out-of-bounds data will be received together with the normal data. In this way, the received cross-border data is the same as the normal data.

So_passcred and so_peercred options

These options are only applicable to the pf_unix (pf_local) interface. These options are used to control and pass creden。 on the local interface of the current host. This may be the most difficult topic to grasp. For now, we just need to note that we may be interested in these two options if we want to write service programs that serve local host customers.

From: http://ffwmxr.blog.163.com/blog/static/66372722201192214651351/