Linux Socket编程注意事项
Socket API 是网络应用程序开发中实际应用的标准 API。虽然该 API 简单。可是开发新手可能会经历一些常见的问题。本文识别一些最常见的隐患并向您显示怎样避免它们。
隐患 1.忽略返回状态
第一个隐患非常明显,但它是开发新手最easy犯的一个错误。
假设您忽略函数的返回状态,当它们失败或部分成功的时候,您或许会迷失。
反过来。这可能传播错误。使定位问题的源头变得困难。
捕获并检查每个返回状态。而不是忽略它们。考虑清单 1 显示的样例,一个套接字 send 函数。
清单 1. 忽略 API 函数返回状态
int status, sock, mode; /* Create a new stream (TCP) socket */ sock = socket( AF_INET, SOCK_STREAM, 0 ); ... status = send( sock, buffer, buflen, MSG_DONTWAIT ); if (status == -1) { /* send failed */ printf( "send failed: %s\n", strerror(errno) ); } else { /* send succeeded -- or did it? */ }
清单 1 探究一个函数片断,它完毕套接字 send 操作(通过套接字发送数据)。函数的错误状态被捕获并測试,但这个样例忽略了 send 在无堵塞模式(由 MSG_DONTWAIT 标志启用)下的一个特性。
send API 函数有三类可能的返回值:
· 假设数据成功地排到传输队列。则返回 0。
· 假设排队失败。则返回 -1(通过使用 errno 变量能够了解失败的原因)。
· 假设不是全部的字符都可以在函数调用时排队,则终于的返回值是发送的字符数。
因为 send 的 MSG_DONTWAIT 变量的无堵塞性质,函数调用在发送全然部的数据、一些数据或没有发送不论什么数据后返回。在这里忽略返回状态将导致不全然的发送和随后的数据丢失。
隐患 2.对等套接字闭包
UNIX 有趣的一面是您差点儿能够把不论什么东西看成是一个文件。文件本身、文件夹、管道、设备和套接字都被当作文件。
这是新颖的抽象,意味着一整套的 API 能够用在广泛的设备类型上。
考虑 read API 函数,它从文件读取一定数量的字节。
read 函数返回读取的字节数(最高为您指定的最大值);或者 -1,表示错误;或者 0,假设已经到达文件末尾。
假设在一个套接字上完毕一个 read 操作并得到一个为 0 的返回值,这表明远程套接字端的对等层调用了 close API 方法。该指示与文件读取同样 —— 没有多余的数据能够通过描写叙述符读取(參见 清单 2)。
清单 2.适当处理 read API 函数的返回值
int sock, status; sock = socket( AF_INET, SOCK_STREAM, 0 ); ... status = read( sock, buffer, buflen ); if (status > 0) { /* Data read from the socket */ } else if (status == -1) { /* Error, check errno, take action... */ } else if (status == 0) { /* Peer closed the socket, finish the close */ close( sock ); /* Further processing... */ }
相同,能够用 write API 函数来探測对等套接字的闭包。
在这样的情况下,接收 SIGPIPE 信号,或假设该信号堵塞,write 函数将返回 -1 并设置 errno 为 EPIPE。
隐患 3.地址使用错误(EADDRINUSE)
您能够使用 bind API 函数来绑定一个地址(一个接口和一个port)到一个套接字端点。能够在server设置中使用这个函数,以便限制可能有连接到来的接口。也能够在client设置中使用这个函数,以便限制应当供出去的连接所使用的接口。bind 最常见的使用方法是关联port号和server,并使用通配符地址(INADDR_ANY),它同意不论什么接口为到来的连接所使用。
bind 普遍遭遇的问题是试图绑定一个已经在使用的port。
该陷阱是或许没有活动的套接字存在,但仍然禁止绑定port(bind 返回EADDRINUSE)。它由 TCP 套接字状态 TIME_WAIT 引起。该状态在套接字关闭后约保留 2 到 4 分钟。
在 TIME_WAIT 状态退出之后。套接字被删除,该地址才干被又一次绑定而不出问题。
等待 TIME_WAIT 结束可能是令人恼火的一件事,特别是假设您正在开发一个套接字server,就须要停止server来做一些修改,然后重新启动。幸运的是,有方法能够避开 TIME_WAIT 状态。能够给套接字应用 SO_REUSEADDR 套接字选项,以便port能够立即重用。
考虑清单 3 的样例。在绑定地址之前,我以 SO_REUSEADDR 选项调用 setsockopt。
为了同意地址重用,我设置整型參数(on)为 1 (不然。能够设为 0 来禁止地址重用)。
清单 3.使用 SO_REUSEADDR 套接字选项避免地址使用错误
int sock, ret, on; struct sockaddr_in servaddr; /* Create a new stream (TCP) socket */ sock = socket( AF_INET, SOCK_STREAM, 0 ): /* Enable address reuse */on = 1; ret = setsockopt( sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on) ); /* Allow connections to port 8080 from any available interface */ memset( &servaddr, 0, sizeof(servaddr) );servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl( INADDR_ANY ); servaddr.sin_port = htons( 45000 ); /* Bind to the address (interface/port) */ ret = bind( sock, (struct sockaddr *)&servaddr, sizeof(servaddr) );
在应用了 SO_REUSEADDR 选项之后,bind API 函数将同意地址的马上重用。
隐患 4.TCP 中的帧同步假定
TCP 不提供帧同步,这使得它对于面向字节流的协议是完美的。这是 TCP 与 UDP(User Datagram Protocol,用户数据报协议)的一个重要差别。UDP 是面向消息的协议,它保留发送者和接收者之间的消息边界。TCP 是一个面向流的协议,它假定正在通信的数据是无结构的,如图 1 所看到的。
图 1.UDP 的帧同步能力和缺乏帧同步的 TCP
图 1 的上部说明一个 UDP client和server。左边的对等层完毕两个套接字的写操作,每一个 100 字节。
协议栈的 UDP 层追踪写的数量,并确保当右边的接收者通过套接字获取数据时,它以相同数量的字节到达。换句话说。为读者保留了写者提供的消息边界。
如今,看图 1 的底部.它为 TCP 层演示了同样粒度的写操作。两个独立的写操作(每一个 100 字节)写入流套接字。
但在本例中,流套接字的读者得到的是 200 字节。协议栈的 TCP 层聚合了两次写操作。这样的聚合能够发生在 TCP/IP 协议栈的发送者或接收者中不论什么一方。
重要的是,要注意到聚合或许不会发生 —— TCP 仅仅保证数据的有序发送。
对大多数开发者来说,该陷阱会引起困惑。
您想要获得 TCP 的可靠性和 UDP 的帧同步。除非改用其它的传输协议,比方流传输控制协议(STCP),否则就要求应用层开发者来实现缓冲和分段功能。