昨天为了比较UNIX socket跟TCP/IP socket的性能,写了一个echo server简单的比较了两者的性能,通过初步不详细的结果,能够看出UNIX的网络交互性能确实要比TCP/IP性能高。但是,除了这个问题解决了之后,还遇到了自己意想不到的收获。
echo server中的处理请求示例代码如下所示,这也是从unix网络编程第五章摘抄的代码 如下:
- void str_echo(int sockfd)
-
{
-
ssize_t n;
-
char buf[MAX_LEN];
-
-
again:
-
while ((n = read(sockfd, buf, MAX_LEN)) > 0)
-
{
-
write(sockfd, buf, n);
-
}
-
-
if (n < 0 && errno == EINTR)
-
goto again;
-
else if (n < 0)
-
perror("str_echo: read error:");
-
}
这段服务器端代码其实没什么问题,只是在write函数返回的时候没有做判断,但这个小瑕疵并不影响我后续说的主要问题。
这段代码在一般的情形下能够很好的服务客户端请求,使用telnet能够看到echo回来的字符串。
但是,在客户端请求一个大字符串长度的时候(比如10000000),这段程序就会造成整个客户端与服务器之间的死锁。
在socket中,一般都会为发送与接受双方向维护缓冲区,如果发送段发送数据时,如果缓冲区有空闲的地方,那么就是将数据放入到发送缓冲区中,如果缓冲区没有空闲区域,那么根据socket的类型决定相应操作:
- 如果socket是阻塞的write,那么write将阻塞,直到发送缓冲区有数据出现。
- 如果socket是非阻塞的write,那么write将立即返回,errno = EAGAIN或者EWOULDBLOCK,由调用方决定后续操作。
如果client端使用的是阻塞write(server_fd, big_buf, 10000000),写一个巨大的buffer,client端在内核部分会将这么大的buffer分批次发送,server这端接受到被拆分的数据后直接调用自己的write函数写回给client端,数据则是先到了server的发送缓冲区,然后经过网络又到了client的接受缓冲区,但是由于client段还在write函数中,并没有read,所以数据就只能停留在自己的接收缓冲区中。
这就像一个水龙头源源不断的出水,水流向一个封着口的管子中,水龙头必须把水放完了之后,才能打开管子的封口把水放出来。管子的容量是有限的,但是水的量是不确定的。如果水的量比较少,那么这套系统可以正常工作,如果水量大于管子的容量了,那么这套系统就死锁了。
- 首先,被填满的就是client的接受缓冲区,其实也不是填满,由于TCP的滑动窗口,当达到了窗口限制之后,发送端就不再发送了。也许缓冲区会比窗口大,这个没看过具体实现,尚不做硬性关联。总之,client接受被填满了。
- 然后,server端的发送缓冲区由于数据越来越多,又不能发给client,总之慢慢的就被填满了。带来的结果就是,server的程序被阻塞到write函数中了,这样导致server就不能够read了。
- 接着,server程序被阻塞到write函数中了,那么也自然就不会read了,慢慢的,慢慢的,server端的TCP接收窗口也就满了,再也不能从client端读数据了。管子就此也就满了三截了。
- 最后,因为server端的TCP接受窗口已经满了,client端的内核就不能将数据发给server段了,就只能在自己的发送缓冲区存了,渐渐的,渐渐的,client端的发送缓冲区也满了。但是,这个时候的write还没有返回,client端也阻塞在了write中。
- 最后的最后,系统就死锁了。:-),这应该是分布式中最简单的死锁了……
昨天遇到那个问题,今天用了一天的闲暇时光总算是把这个问题想通了。其实这个死锁问题还是典型的,满足死锁发生的各种条件。最根本原因就是系统的资源无法满足,然后又没能够合理的安排。最简单的解决办法就是客户端这边发一点,读一点,这个问题也就避免了,使得不会一次请求那么多的资源,这个问题也就解决了。
阅读(7382) | 评论(0) | 转发(2) |