getsockopt/setsockopt函数说明(一）

关注

转载最新推荐文章于 2026-02-05 00:06:32 发布 1.5k 阅读 AI 写同款· GEO 优化 ›

通过setsockopt设置SO_SNDBUF、SO_RCVBUF这连个默认缓冲区的值，再用getsockopt获取设置的值，发现返回值是设置值的两倍。修改发送和接收的buffer: SEND_BUF_SIZE = 2501 RECV_BUF_SIZE = 2502 node1:/root/test#python t2.py Buffer size [Before]: 16384 Buffer size [Before]: 87380 alter---------------- 5002 5004 通过setsockopt设置SO_SN... 阅读详情

功能描述：
获取或者设置与某个套接字关联的选项。选项可能存在于多层协议中，它们总会出现在最上面的套接字层。当操作套接字选项时，选项位于的层和选项的名称必须给出。为了操作套接字层的选项，应该将层的值指定为SOL_SOCKET。为了操作其它层的选项，控制选项的合适协议号必须给出。例如，为了表示一个选项由TCP协议解析，层应该设定为协议号TCP。

用法：
int getsockopt(int sock, int level, int optname, void *optval, socklen_t *optlen);

int setsockopt(int sock, int level, int optname, const void *optval, socklen_t optlen);

参数：
sock：将要被设置或者获取选项的套接字。
level：选项所在的协议层。
optname：需要访问的选项名。
optval：对于getsockopt()，指向返回选项值的缓冲。对于setsockopt()，指向包含新选项值的缓冲。
optlen：对于getsockopt()，作为入口参数时，选项值的最大长度。作为出口参数时，选项值的实际长度。对于setsockopt()，现选项的长度。

返回说明：

成功执行时，返回0。失败返回-1，errno被设为以下的某个值
EBADF：sock不是有效的文件描述词
EFAULT：optval指向的内存并非有效的进程空间
EINVAL：在调用setsockopt()时，optlen无效
ENOPROTOOPT：指定的协议层不能识别选项
ENOTSOCK：sock描述的不是套接字

参数详细说明：

level指定控制套接字的层次.可以取三种值:
1)SOL_SOCKET:通用套接字选项.
2)IPPROTO_IP:IP选项.
3)IPPROTO_TCP:TCP选项.
optname指定控制的方式(选项的名称),我们下面详细解释

optval获得或者是设置套接字选项.根据选项名称的数据类型进行转换

选项名称说明数据类型
========================================================================
SOL_SOCKET
------------------------------------------------------------------------
SO_BROADCAST 允许发送广播数据 int
SO_DEBUG 允许调试 int
SO_DONTROUTE 不查找路由 int
SO_ERROR 获得套接字错误 int
SO_KEEPALIVE 保持连接 int
SO_LINGER 延迟关闭连接 struct linger
SO_OOBINLINE 带外数据放入正常数据流 int
SO_RCVBUF 接收缓冲区大小 int
SO_SNDBUF 发送缓冲区大小 int
SO_RCVLOWAT 接收缓冲区下限 int
SO_SNDLOWAT 发送缓冲区下限 int
SO_RCVTIMEO 接收超时 struct timeval
SO_SNDTIMEO 发送超时 struct timeval
SO_REUSERADDR 允许重用本地地址和端口 int
SO_REUSEPORT ?http://blog.chinaunix.net/uid-26851094-id-3318435.html int

SO_TYPE 获得套接字类型 int
SO_BSDCOMPAT 与BSD系统兼容 int
========================================================================
IPPROTO_IP
------------------------------------------------------------------------
IP_HDRINCL 在数据包中包含IP首部 int
IP_OPTINOS IP首部选项 int
IP_TOS 服务类型
IP_TTL 生存时间 int
========================================================================
IPPRO_TCP
------------------------------------------------------------------------
TCP_MAXSEG TCP最大数据段的大小 int
TCP_NODELAY 不使用Nagle算法 int
========================================================================

返回说明：
成功执行时，返回0。失败返回-1，errno被设为以下的某个值
EBADF：sock不是有效的文件描述词
EFAULT：optval指向的内存并非有效的进程空间
EINVAL：在调用setsockopt()时，optlen无效
ENOPROTOOPT：指定的协议层不能识别选项
ENOTSOCK：sock描述的不是套接字

SO_RCVBUF和SO_SNDBUF：每个套接口都有一个发送缓冲区和一个接收缓冲区，使用这两个套接口选项可以改变缺省缓冲区大小。

//接收缓冲区
int nRecvBuf=32*1024; //设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

//发送缓冲区
int nSendBuf=32*1024;//设置为32K

setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int));

注意：

当设置TCP套接口接收缓冲区的大小时，函数调用顺序是很重要的，因为TCP的窗口规模选项是在建立连接时用SYN与对方互换得到的。对于客户，O_RCVBUF选项必须在connect之前设置；对于服务器，SO_RCVBUF选项必须在listen前设置。

结合原理说明：

1.每个套接口都有一个发送缓冲区和一个接收缓冲区。接收缓冲区被TCP和UDP用来将接收到的数据一直保存到由应用进程来读。 TCP：TCP通告另一端的窗口大小。TCP套接口接收缓冲区不可能溢出，因为对方不允许发出超过所通告窗口大小的数据。这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。 UDP：当接收到的数据报装不进套接口接收缓冲区时，此数据报就被丢弃。UDP是没有流量控制的；快的发送者可以很容易地就淹没慢的接收者，导致接收方的 UDP丢弃数据报。
2.我们经常听说tcp协议的三次握手，但三次握手到底是什么，其细节是什么，为什么要这么做呢?
第一次:客户端发送连接请求给服务器，服务器接收;
第二次:服务器返回给客户端一个确认码,附带一个从服务器到客户端的连接请求,客户机接收,确认客户端到服务器的连接.
第三次:客户机返回服务器上次发送请求的确认码,服务器接收,确认服务器到客户端的连接.
我们可以看到:
1. tcp的每个连接都需要确认.
2. 客户端到服务器和服务器到客户端的连接是独立的.
我们再想想tcp协议的特点:连接的,可靠的,全双工的,实际上tcp的三次握手正是为了保证这些特性的实现.

3.setsockopt的用法

1.closesocket（一般不会立即关闭而经历TIME_WAIT的过程）后想继续重用该socket：
BOOL bReuseaddr=TRUE;
setsockopt(s,SOL_SOCKET ,SO_REUSEADDR,(const char*)&bReuseaddr,sizeof(BOOL));

2. 如果要已经处于连接状态的soket在调用closesocket后强制关闭，不经历TIME_WAIT的过程：
BOOL bDontLinger = FALSE;
setsockopt(s,SOL_SOCKET,SO_DONTLINGER,(const char*)&bDontLinger,sizeof(BOOL));

3.在send(),recv()过程中有时由于网络状况等原因，发收不能预期进行,而设置收发时限：
int nNetTimeout=1000;//1秒
//发送时限
setsockopt(socket，SOL_S0CKET,SO_SNDTIMEO,(char *)&nNetTimeout,sizeof(int));
//接收时限
setsockopt(socket，SOL_S0CKET,SO_RCVTIMEO,(char *)&nNetTimeout,sizeof(int));

4.在send()的时候，返回的是实际发送出去的字节(同步)或发送到socket缓冲区的字节(异步);系统默认的状态发送和接收一次为 8688字节(约为8.5K)；在实际的过程中发送数据和接收数据量比较大，可以设置socket缓冲区，而避免了send(),recv()不断的循环收发：
// 接收缓冲区
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
//发送缓冲区
int nSendBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int));

5. 如果在发送数据的时侯，希望不经历由系统缓冲区到socket缓冲区的拷贝而影响程序的性能：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_SNDBUF，(char *)&nZero,sizeof(nZero));

6.同上在recv()完成上述功能(默认情况是将socket缓冲区的内容拷贝到系统缓冲区)：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_RCVBUF，(char *)&nZero,sizeof(int));

7.一般在发送UDP数据报的时候，希望该socket发送的数据具有广播特性：
BOOL bBroadcast=TRUE;
setsockopt(s,SOL_SOCKET,SO_BROADCAST,(const char*)&bBroadcast,sizeof(BOOL));

8.在client连接服务器过程中，如果处于非阻塞模式下的socket在connect()的过程中可以设置connect()延时,直到accpet()被呼叫(本函数设置只有在非阻塞的过程中有显著的作用，在阻塞的函数调用中作用不大)
BOOL bConditionalAccept=TRUE;
setsockopt(s,SOL_SOCKET,SO_CONDITIONAL_ACCEPT,(const char*)&bConditionalAccept,sizeof(BOOL));

9.如果在发送数据的过程中(send()没有完成，还有数据没发送)而调用了closesocket(),以前我们一般采取的措施是"从容关闭"shutdown(s,SD_BOTH),但是数据是肯定丢失了，如何设置让程序满足具体应用的要求(即让没发完的数据发送出去后在关闭socket)？
struct linger {
u_short l_onoff;
u_short l_linger;
};
linger m_sLinger;
m_sLinger.l_onoff=1;//(在closesocket()调用,但是还有数据没发送完毕的时候容许逗留)
//如果m_sLinger.l_onoff=0;则功能和2.)作用相同;
m_sLinger.l_linger=5;//(容许逗留的时间为5秒)
setsockopt(s,SOL_SOCKET,SO_LINGER,(const char*)&m_sLinger,sizeof(linger));

--------------------------------------------------------------------------------------------------------------------

转载自：http://www.easewe.com/Article/document/674.htm

套接口选项

在前面的几章中，我们讨论了使用套接口的基础内容。现在我们要来探讨一些可用的其他的特征。在我们掌握了这一章的概念之后，我们就为后面的套接口的高级主题做好了准备。在这一章，我们将会专注于下列主题：
如何使用getsockopt(2)函数获得套接口选项值
如何使用setsockopt(2)函数设置套接口选项值
如何使用这些常用的套接口选项

得到套接口选项

有时，一个程序需要确定为当前为一个套接口进行哪些选项设置。这对于一个子程序库函数尤其如此，因为这个库函数并不知道为这个套接口进行哪些设置，而这个套接口需要作为一个参数进行传递。程序也许需要知道类似于流默认使用的缓冲区的大小。

允许我们得到套接口选项值的为getsockopt函数。这个函数的概要如下：
#include <sys/types.h>
#include <sys/socket.h>
int getsockopt(int s,
int level,
int optname,
void *optval,
socklen_t *optlen);
函数参数描述如下：
1 要进行选项检验的套接口s
2 选项检验所在的协议层level
3 要检验的选项optname
4 指向接收选项值的缓冲区的指针optval
5 指针optlen同时指向输入缓冲区的长度和返回的选项长度值
当函数成功时返回0。当发生错误时会返回-1，而错误原因会存放在外部变量errno中。

协议层参数指明了我们希望访问一个选项所在的协议栈。通常我们需要使用下面中的一个：
SOL_SOCKET来访问套接口层选项
SOL_TCP来访问TCP层选项

我们在这一章的讨论将会专注于SOL_SOCKET层选项的使用。

参数optname为一个整数值。在这里所使用的值首先是由所选用的level参数来确定的。在一个指定的协议层，optname参数将会确定我们希望访问哪一个选项。下表列出了一些层与选项的组合值：

协议层选项名字
SOL_SOCKET SO_REUSEADDR
SOL_SOCKET SO_KKEPALIVE
SOL_SOCKET SO_LINGER
SOL_SOCKET SO_BROADCAST
SOL_SOCKET SO_OOBINLINE
SOL_SOCKET SO_SNDBUF
SOL_SOCKET SO_RCVBUF
SOL_SOCKET SO_TYPE
SOL_SOCKET SO_ERROR
SOL_TCP SO_NODELAY

上表所列的大多数选项为套接口选项，其中的层是由SOL_SOCKET指定的。为了比较的目的包含了一个TCP层套接口选项，其中的层是由SOL_TCP指定的。

大多数套接口选项获得后存放在int数据类型中。当查看手册页时，数据类型int通常会有一些假设，除非表明了其他东西。当使用一个布尔值时，当值为非零时，int表示TRUE，而如果为零，则表示FALSE。

应用getsockopt(2)

在这一部分，我们将会编译并运行一个getsndrcv.c的程序，这个程序会获得并报告一个套接口的发送以及接收缓冲区的大小尺寸。
/*getsndrc.v
*
* Get SO_SNDBUF & SO_RCVBUF Options:
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>

/*
* This function report the error and
* exits back to the shell:
*/
static void bail(const char *on_what)
{
if(errno != 0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('\n',stderr);
exit(1);
}

int main(int argc,char **argv)
{
int z;
int s=-1; /* Socket */
int sndbuf=0; /* Send buffer size */
int rcvbuf=0; /* Receive buffer size */
socklen_t optlen; /* Option length */

/*
* Create a TCP/IP socket to use:
*/
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");

/*
* Get socket option SO_SNDBUF:
*/
optlen = sizeof sndbuf;
z = getsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,&optlen);

if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");

assert(optlen == sizeof sndbuf);

/*
* Get socket option SON_RCVBUF:
*/

optlen = sizeof rcvbuf;
z = getsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_RCVBUF)");

assert(optlen == sizeof rcvbuf);

/*
* Report the buffer sizes:
*/
printf("Socket s: %d\n",s);
printf("Send buf: %d bytes\n",sndbuf);
printf("Recv buf: %d bytes\n",rcvbuf);

close(s);
return 0;
}
程序的运行结果如下：
$ ./getsndrcv
socket s : 3
Send buf: 65535 bytes
Recv buf: 65535 bytes

设置套接口选项

如果认为套接口的默认发送以及接收缓冲区的尺寸太大时，作为程序设计者的我们可以将其设计为一个小的缓冲区。当我们程序一个程序的几个实例同时运行在我们的系统上时，这显得尤其重要。

可以通过setsockopt(2)函数来设计套接口选项。这个函数的概要如下：
#include <sys/types.h>
#include <sys/socket.h>
int setsockopt(int s,
int level,
int optname,
const void *optval,
socklen_t optlen);

这个函数与我们在上面所讨论的getsockopt函数类似，setsockopt函数的参数描述如下：
1 选项改变所要影响的套接口s
2 选项的套接口层次level
3 要设计的选项名optname
4 指向要为新选项所设置的值的指针optval
5 选项值长度optlen

这个函数参数与上面的getsockopt函数的参数的区别就在于最后一个参数仅是传递参数值。在这种情况下只是一个输入值。

应用setsockopt函数

下面的例子代码为一个套接口改变了发送以及接收缓冲区的尺寸。在设置完这些选项以后，程序会得到并报告实际的缓冲区尺寸。

/*setsndrcv.c
*
* Set SO_SNDBUF & SO_RCVBUF Options:
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>

/*
* This function report the error and
* exits back to the shell:
*/
static void bail(const char *on_what)
{
if(errno!=0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('\n',stderr);
exit(1);
}

int main(int argc,char **argv)
{
int z;
int s=-1; /* Socket */
int sndbuf=0; /* Send buffer size */
int rcvbuf=0; /* Receive buffer size */
socklen_t optlen; /* Option length */

/*
* Create a TCP/IP socket to use:
*/
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");

/*
* set the SO_SNDBUF size :
*/
sndbuf = 5000; /* Send buffer size */
z = setsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,sizeof sndbuf);
if(z)
bail("setsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");

/*
* Set the SO_RCVBUF size:
*/
rcvbuf = 8192; /* Receive buffer size */
z = setsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,sizeof rcvbuf);
if(z)
bail("setsockopt(s,SOL_SOCKET,"
"SO_RCVBUF)");

/*
* As a check on the above ....
* Get socket option SO_SNDBUF:
*/
optlen = sizeof sndbuf;
z = getsockopt(s,SOL_SOCKET,SO_SNDBUF,&sndbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_SNDBUF)");

assert(optlen == sizeof sndbuf);

/*
* Get socket option SO_RCVBUF:
*/
optlen = sizeof rcvbuf;
z = getsockopt(s,SOL_SOCKET,SO_RCVBUF,&rcvbuf,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET"
"SO_RCVBUF)");
assert(optlen == sizeof rcvbuf);

/*
* Report the buffer sizes:
*/
printf("Socket s: %d\n",s);
printf(" Send buf: %d bytes\n",sndbuf);
printf(" Recv buf: %d bytes\n",rcvbuf);

close(s);
return 0;
}

程序的运行结果如下：
$ ./setsndrcv
Socket s : 3
Send buf: 10000 bytes
Recv buf: 16384 bytes
$

在这里我们要注意程序所报告的结果。他们看上去似乎是所指定的原始尺寸的两倍。这个原因可以由Linux内核源码模块net/core/sock.c中查到。我们可以查看一下SO_SNDBUF以及SO_RCVBUF的case语句。下面一段是由内核模块sock.c中摘录的一段处理SO_SNDBUF的代码：
398 case SO_SNDBUF:
399 /* Don't error on this BSD doesn't and if you think
400 about it this is right. Otherwise apps have to
401 play 'guess the biggest size' games. RCVBUF/SNDBUF
402 are treated in BSD as hints */
403
404 if (val > sysctl_wmem_max)
405 val = sysctl_wmem_max;
406 set_sndbuf:
407 sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
408 if ((val * 2) < SOCK_MIN_SNDBUF)
409 sk->sk_sndbuf = SOCK_MIN_SNDBUF;
410 else
411 sk->sk_sndbuf = val * 2;
412
413 /*
414 * Wake up sending tasks if we
415 * upped the value.
416 */
417 sk->sk_write_space(sk);
418 break;

由这段代码我们可以看到实际发生在SO_SNDBUF上的事情：
1 检测SO_SNDBUF选项值来确定他是否超过了缓冲区的最大值
2 如果步骤1中的SO_SNDBUF选项值没有超过最大值，那么就使用这个最大值，而不会向调用者返回错误代码
3 如果SO_SNDBUF选项值的2倍小于套接口SO_SNDBUF的最小值，那么实际的SO_SNDBUF则会设置为SO_SNDBUF的最小值，否则则会SO_SNDBUF选项值则会设置为SO_SNDBUF选项值的2倍

从这里我们可以看出SO_SNDBUF的选项值只是所用的一个提示值。内核会最终确定为SO_SNDBUF所用的最佳值。

查看更多的内核源码，我们可以看到类似的情况也适用于SO_RCVBUF选项。如下面的一段摘录的代码：
427 case SO_RCVBUF:
428 /* Don't error on this BSD doesn't and if you think
429 about it this is right. Otherwise apps have to
430 play 'guess the biggest size' games. RCVBUF/SNDBUF
431 are treated in BSD as hints */
432
433 if (val > sysctl_rmem_max)
434 val = sysctl_rmem_max;
435 set_rcvbuf:
436 sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
437 /*
438 * We double it on the way in to account for
439 * "struct sk_buff" etc. overhead. Applications
440 * assume that the SO_RCVBUF setting they make will
441 * allow that much actual data to be received on that
442 * socket.
443 *
444 * Applications are unaware that "struct sk_buff" and
445 * other overheads allocate from the receive buffer
446 * during socket buffer allocation.
447 *
448 * And after considering the possible alternatives,
449 * returning the value we actually used in getsockopt
450 * is the most desirable behavior.
451 */
452 if ((val * 2) < SOCK_MIN_RCVBUF)
453 sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
454 else
455 sk->sk_rcvbuf = val * 2;
456 break;

取得套接口类型

实际上我们只可以得到一些套接口选项。SO_TYPE就是其中的一例。这个选项会允许传递套接口的一个子函数来确定正在处理的是哪一种套接口类型。

如下面是一段得到套接口s类型的示例代码：
/*gettype.c
*
* Get SO_TYPE Option:
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <assert.h>

/*
* This function report the error and
* exits back to the shell:
*/
static void bail(const char *on_what)
{
if(errno!=0)
{
fputs(strerror(errno),stderr);
fputs(": ",stderr);
}
fputs(on_what,stderr);
fputc('\n',stderr);
exit(1);
}

int main(int argc,char **argv)
{
int z;
int s = -1; /* Socket */
int so_type = -1; /* Socket type */
socklen_t optlen; /* Option length */

/*
* Create a TCT/IP socket to use:
*/
s = socket(PF_INET,SOCK_STREAM,0);
if(s==-1)
bail("socket(2)");

/*
* Get socket option SO_TYPE:
*/
optlen = sizeof so_type;
z = getsockopt(s,SOL_SOCKET,SO_TYPE,&so_type,&optlen);
if(z)
bail("getsockopt(s,SOL_SOCKET,"
"SO_TYPE)");
assert(optlen == sizeof so_type);
/*
* Report the result:
*/
printf("Socket s: %d\n",s);
printf(" SO_TYPE : %d\n",so_type);
printf(" SO_STREAM = %d\n",SOCK_STREAM);

close(s);
return 0;
}
程序的运行结果如下：
$./gettype
Socket s: 3
SO_TYPE : 1
SO_STREAM = 1

设置SO_REUSEADDR选项

在第11章，"并发客户端服务器"的第一部分中，提供并测试了一个使用fork系统调用设计的服务器。图12.1显示了在一个telnet命令与服务器建立连接之后的三个步骤。
这些步骤如下：
1 启动服务器进程(PID 926)。他监听客户端连接。
2 启动客户端进程(telnet命令)，并且连接到服务器进程(PID 926)。
3 通过fork调用创建服务器子进程，这会保留的原始的父进程(PID 926)并且创建一个新的子进程(PID 927)。
4 连接的客户端套接口由于服务器父进程(PID 926)关闭，仅在子进程(PID 927)中保持连接的客户端套接口处理打开状态。
5 telnet命令与服务器子进程(PID 927)随意交互，而独立于父进程(PID 926)。

在步骤5，有两个套接口活动：
服务器(PID 926)监听192.168.0.1：9099
客户端由套接口192.168.0.1：9099进行服务(PID 927)，他连接到客户端地址192.168.0.2：1035

客户端由进程ID 927进行服务。这意味着我们可以杀掉进程ID 926，而客户端仍可以继续被服务。然而，却不会有新的连接连接到服务器，因为并没有服务器监听新的连接(监听服务器PID 926已被杀死)

现在如果我们重启服务器来监听新的连接，就会出现问题。当新的服务器进程试着绑定IP地址192.168.0.1：9099时，bind函数就会返回 EADDRINUSE的错误代码。这个错误代码表明IP已经在9099端口上使用。这是因为进程PID 927仍然在忙于服务一个客户端。地址192.168.0.1：9099仍为这个进程所使用。

这个问题的解决办法就是杀掉进程927,这个关闭套接口并且释放IP地址和端口。然而，如果正在被服务的客户是我们所在公司的CEO，这样的做法似乎不是一个选择。同时，其他的部门也会抱怨我们为什么要重新启动服务器。

这个问题的一个好的解决办法就是使用SO_REUSEADDR套接口选项。所有的服务器都应使用这个选项，除非有一个更好的理由不使用。为了有效的使用这个选项，我们应在监听连接的服务器中执行下面的操作：
1 使用通常的socket函数创建一个监听套接口
2 调用setsockopt函数设置SO_REUSEADDR为TRUE
3 调用bind函数

套接口现在被标记为可重用。如果监听服务器进程因为任何原因终止，我们可以重新启动这个服务器。当一个客户正为另一个服务器进程使用同一个IP和端口号进行服务时尤其如此。

为了有效的使用SO_REUSEADDR选项，需要考虑下面的情况：
在监听模式下并没有同样的IP地址和端口号的其他套接口
所有的同一个IP地址和端口号的套接口必须将SO_REUSEADDR选项设置为TRUE

这就意味着一个指定的IP地址和端口号对上只可以用一个监听器。如果这样的套接口已经存在，那么设置这样的选项将不会达到我们的目的。

只有所有存在的同一个地址和端口号的套接口有这个选项设置，将SO_REUSEADDR设置为TRUE才会有效。如果存在的套接口没有这个选项设置，那么bind函数就会继续并且会返回一个错误号。

下面的代码显示如何将这个选项设置为TRUE：

#define TRUE 1
#define FALSE 0
int z; /* Status code */
int s; /* Socket number */
int so_reuseaddr = TRUE;
z = setsockopt(s,SOL_SOCKET,SO_REUSEADDR,
&so_reuseaddr,
sizeof so_reuseaddr);
如果需要SO_REUSEADDR选项可以由getsockopt函数进行查询。

设置SO_LINGER选项

另一个常用的选项就是SO_LINGER选项。与SO_REUSEADDR选项所不同的是这个选项所用的数据类型并不是一个简单的int类型。

SO_LINGER选项的目的是控制当调用close函数时套接口如何关闭。这个选项只适用于面向连接的协议，例如TCP。

内核的默认行为是允许close函数立即返回给调用者。如果可能任何未发送的TCP/IP数据将会进行传送，但是并不会保证这样做。因为close函数会立即向调用者返回控制权，程序并没有办法知道最后一位的数据是否进行了发送。

SO_LINGER选项可以作用在套接口上，来使得程序阻塞close函数调用，直到所有最后的数据传送到远程端。而且，这会保证两端的调用知道套接口正常关闭。如果失败，指定的选项超时，并且向调用程序返回一个错误。

通过使用不同的SO_LINGER选项值，可以应用一个最后场景。如果调用程序希望立即中止通信，可以在linger结构中设置合适的值。然后，一个到close的调用会初始化一个通信中止连接，而丢弃所有未发送的数据，并立即关闭套接口。

SO_LINGER的这种操作模式是由linger结构来控制的：
struct linger {
int l_onoff;
int l_linger;
};
成员l_onoff为一个布尔值，非零值表示TRUE，而零则表示FALSE。这个选项的三个值描述如下：

1 设置l_onoff为FALSE使得成员l_linger被忽略，而使用默认的close行为。也就是说，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据。
2 设置l_onoff为TRUE将会使得成员l_linger的值变得重要。当l_linger非零时，这代表应用在close函数调用上的以秒计的超时时限。如果超时发生之前，有未发送的数据并且成功关闭，函数将会成功返回。否则，将会返回错误，而将变量errno的值设置为EWOULDBLOCK。
3 将l_onoff设置为TRUE而l_linger设置为零时使得连接中止，在调用close时任何示发送的数据都会丢弃。

我们也许希望得到一些建议，在我们的程序中使用SO_LINGER选项，并且提供一个合理的超时时限。然后，可以检测由close函数的返回值来确定连接是否成功关闭。如果返回了一个错误，这就告知我们的程序也许远程程序并不能接收我们发送的全部数据。相对的，他也许仅意味着连接关闭时发生的问题。

然而，我们必须保持清醒，这样的方法在一些服务器设计中会产生新的问题。当在close函数调用上将SO_LINGER选项配置为超时(linger)，当我们的服务器在close函数调用中执行超时时会阻止其他的客户端进行服务。如果我们正在一个进程中服务多个客户端进程时就会存在这个问题。使用默认的行为也许更为合适，因为这允许close函数立即返回。而任何未发送的数据也会为内核继续发送。

最后，如果程序或是服务器知道连接应何时中止时可以使用中止行为。这也许适用于当服务器认为没有访问权限的用户正试着进行访问的情况。这种情况下的客户并不会得到特别的关注。
SO_LINGER的这种操作模式是由linger结构来控制的：
struct linger {
int l_onoff;
int l_linger;
};
成员l_onoff为一个布尔值，非零值表示TRUE，而零则表示FALSE。这个选项的三个值描述如下：

1 设置l_onoff为FALSE使得成员l_linger被忽略，而使用默认的close行为。也就是说，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据。
2 设置l_onoff为TRUE将会使得成员l_linger的值变得重要。当l_linger非零时，这代表应用在close函数调用上的以秒计的超时时限。如果超时发生之前，有未发送的数据并且成功关闭，函数将会成功返回。否则，将会返回错误，而将变量errno的值设置为EWOULDBLOCK。
3 将l_onoff设置为TRUE而l_linger设置为零时使得连接中止，在调用close时任何示发送的数据都会丢弃。

我们也许希望得到一些建议，在我们的程序中使用SO_LINGER选项，并且提供一个合理的超时时限。然后，可以检测由close函数的返回值来确定连接是否成功关闭。如果返回了一个错误，这就告知我们的程序也许远程程序并不能接收我们发送的全部数据。相对的，他也许仅意味着连接关闭时发生的问题。

然而，我们必须保持清醒，这样的方法在一些服务器设计中会产生新的问题。当在close函数调用上将SO_LINGER选项配置为超时(linger)，当我们的服务器在close函数调用中执行超时时会阻止其他的客户端进行服务。如果我们正在一个进程中服务多个客户端进程时就会存在这个问题。使用默认的行为也许更为合适，因为这允许close函数立即返回。而任何未发送的数据也会为内核继续发送。

最后，如果程序或是服务器知道连接应何时中止时可以使用中止行为。这也许适用于当服务器认为没有访问权限的用户正试着进行访问的情况。这种情况下的客户并不会得到特别的关注。
SO_LINGER的这种操作模式是由linger结构来控制的：
struct linger {
int l_onoff;
int l_linger;
};
成员l_onoff为一个布尔值，非零值表示TRUE，而零则表示FALSE。这个选项的三个值描述如下：

1 设置l_onoff为FALSE使得成员l_linger被忽略，而使用默认的close行为。也就是说，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据。
2 设置l_onoff为TRUE将会使得成员l_linger的值变得重要。当l_linger非零时，这代表应用在close函数调用上的以秒计的超时时限。如果超时发生之前，有未发送的数据并且成功关闭，函数将会成功返回。否则，将会返回错误，而将变量errno的值设置为EWOULDBLOCK。
3 将l_onoff设置为TRUE而l_linger设置为零时使得连接中止，在调用close时任何示发送的数据都会丢弃。

我们也许希望得到一些建议，在我们的程序中使用SO_LINGER选项，并且提供一个合理的超时时限。然后，可以检测由close函数的返回值来确定连接是否成功关闭。如果返回了一个错误，这就告知我们的程序也许远程程序并不能接收我们发送的全部数据。相对的，他也许仅意味着连接关闭时发生的问题。

然而，我们必须保持清醒，这样的方法在一些服务器设计中会产生新的问题。当在close函数调用上将SO_LINGER选项配置为超时(linger)，当我们的服务器在close函数调用中执行超时时会阻止其他的客户端进行服务。如果我们正在一个进程中服务多个客户端进程时就会存在这个问题。使用默认的行为也许更为合适，因为这允许close函数立即返回。而任何未发送的数据也会为内核继续发送。

最后，如果程序或是服务器知道连接应何时中止时可以使用中止行为。这也许适用于当服务器认为没有访问权限的用户正试着进行访问的情况。这种情况下的客户并不会得到特别的关注。