Edit TCP/IP sockets: Usar SO_LINGER, close(), shutdown() y SIOCOUTQ

Title:

Last edited: 11:50:54 am on 21 May 2015 by n003-000-000-000.static.ge.com

- *The ultimate SO_LINGER page, or: why is my tcp not reliable>http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable*
- *UNIX Socket FAQ: 4.6 - What exactly does SO_LINGER do?>http://developerweb.net/viewtopic.php?id=2982*
- *Linux Socket Programming by Example - Warren Gay: Setting the SO_LINGER Option>http://alas.matf.bg.ac.rs/manuals/lspe/snode=105.html*

Cito el tercer enlace (que es el más claro):

===CUT===
<b>Setting the <tt>SO_LINGER</tt> Option</b>

Another commonly applied socket option is the <tt>SO_LINGER</tt> option. This option differs from the <tt>SO_REUSEADDR</tt> option in that the data structure used is not a simple int data type.

The purpose of the <tt>SO_LINGER</tt> option is to control how the socket is shut down when the function <tt>close(2)</tt> is called. This option applies only to connection-oriented protocols such as TCP.

The default behavior of the kernel is to allow the <tt>close(2)</tt> function to return immediately to the caller. Any unsent TCP/IP data will be transmitted and delivered if possible, but no guarantee is made. Because the <tt>close(2)</tt> call returns control immediately to the caller, the application has no way of knowing whether the last bit of data was actually delivered.

The <tt>SO_LINGER</tt> option can be enabled on the socket, to cause the application to block in the <tt>close(2)</tt> call until all final data is delivered to the remote end. Furthermore, this assures the caller that both ends have acknowledged a normal socket shutdown. Failing this, the indicated option timeout occurs and an error is returned to the calling application.

One final scenario can be applied, by use of different <tt>SO_LINGER</tt> option values. If the calling application wants to abort communications immediately, appropriate values can be set in the linger structure. Then, a call to <tt>close(2)</tt> will initiate an abort of the communication link, discarding all pending data and immediately close the socket.

The modes of operation for <tt>SO_LINGER</tt> are controlled by the structure <tt>linger</tt>:

<code>
struct linger {
    int   l_onoff;
    int   l_linger;
};
</code>

The member <tt>l_onoff</tt> acts as a Boolean value, where a nonzero value indicates <tt>TRUE</tt> and zero indicates <tt>FALSE</tt>. The three variations of this option are specified as follows:

<ol>
<li>Setting <tt>l_onoff</tt> to <tt>FALSE</tt> causes member <tt>l_linger</tt> to be ignored and the default <tt>close(2)</tt> behavior implied. That is, the <tt>close(2)</tt> call will return immediately to the caller, and any pending data will be delivered if possible.</li>
<li>Setting <tt>l_onoff</tt> to <tt>TRUE</tt> causes the value of member <tt>l_linger</tt> to be significant. When <tt>l_linger</tt> is nonzero, this represents the time in seconds for the timeout period to be applied at <tt>close(2)</tt> time (the <tt>close(2)</tt> call will "linger"). If the pending data and successful close occur before the timeout occurs, a successful return takes place. Otherwise, an error return occur and <tt>errno</tt> is set to the value of <tt>EWOULDBLOCK</tt>.</li>
<li>Setting <tt>l_onoff</tt> to <tt>TRUE</tt> and setting <tt>l_linger</tt> to zero causes the connection to be aborted and any pending data is immediately discarded upon close(2).</li>
</ol>

You are probably well advised to write your applications so that the option <tt>SO_LINGER</tt> is enabled and a reasonable timeout is provided. Then, the return value from <tt>close(2)</tt> can be tested to see whether the connection was mutually shut down successfully. If an error is returned instead, this tells your application that it is probable that the remote application was unable to receive all the data that you sent. Alternatively, it might just mean that problems occurred when the connection was closed (after the data was successfully received by the peer).

You must be aware, however, that lingering in some server designs will create new problems. When the <tt>SO_LINGER</tt> option is configured to linger upon <tt>close(2)</tt>, this will prevent other clients from being serviced while your server execution lingers within the <tt>close(2)</tt> function call. This problem exists if you are serving many clients within one process (usually a server that uses <tt>select(2)</tt> or <tt>poll(2)</tt>). Using the default behavior might be more appropriate because it will allow <tt>close(2)</tt> to return immediately. Any pending written data will still be delivered by the kernel, if it is able to.

Finally, using the abort behavior (mode number 3 listed previously) is appropriate if the application or server knows that the connection should be aborted. This might be applied when the server has determined that someone without access privilege is attempting to gain access. The client in this situation deserves no special care and so minimum overhead is expended in dispensing of the culprit.
===CUT===

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: