循环及并发服务器比较.doc

循环和并发服务器的比较及应用

摘要：本文阐述循环和并发服务器的工作原理，给出了循环和并发服务器的算法，从工作原理、工作流程等方面进行了阐述了两者的区别，并给出了循环和并发服务器具体程序实例代码进行分析比较两者的不同

1、循环和并发服务器的工作原理
1.1循环服务器的工作原理
循环服务器在一个时刻只处理一个请求
迭代服务器比较原始，它的原型可以描述成：

while(1)
{
new_fd = 服务器accept客户端的连接(
new_fd = accept(listenfd, XX, XX))
逻辑处理
在这个new_fd上给客户端发送消息
关闭new_fd
}

也就是说，这个进程是一个一个处理各个客户端发来的连接的，比如一个客户端发来一个连接，那么只要它还没有完成自己的任务，那么它就一直会占用服务器的进程直到处理完毕后服务器关闭掉这个socket。

1.2并发服务器的工作原理
　　不同于顺序服务器，并发服务器就要能在一个时间为多个客户端提供服务。 例如，一个聊天服务器可能服务一个特定的客户端数小时 ──在停止为这个客户端服务之前服务器不能等待， 除非是在等待一下个客户端到来之前的间隙才能等待。
　　我们将提供服务从 守护进程移至它自己的服务进程。 然而，因为每个子进程都继承所有打开的文件(套接字被像文件一样处理)， 新进程不仅继承“accept()返回的句柄，” 那是指调用accept返回的套接字；新进程也继承 顶级套接字，这是顶级进程一开始打开的套接字。
　　然而，服务进程不需要这个套接字， 应该立即关闭(close)它。同样的， 守护进程不再需要 accept()返回的套接字， 不仅应该，还必须 关闭(close)它──否则， 那迟早会耗尽可用的文件描述符。
　　在服务进程完成服务之后， 它将关闭accept()返回的套接字。 它不会返回到accept，而是退出进程。
　　在UNIX®上，一个进程并不真正的退出， 而是返回至父进程。典型情况中， 父进程等待(wait)子进程， 并取得一个返回值。但是，我们的守护进程 不能简单的停止或等待，那有违建立其它进程的整个目的。 但是如果从不使用wait， 它的子进程可能会成为僵尸── 不再有功用可仍然徘徊着。
　　出于那样的原因，守护进程 需要在初始化守护进程阶段设置 信号处理程序。 至少要处理信号SIGCHLD， 这样守护进程可以从系统清除僵尸返回值并释放僵尸占用的系统资源。
　　这是现在我们的流程图包含一个进程信号框的原因， 它不与任何其它框相连接。顺便说一句，许多服务器程序也处理SIGHUP， 作为超级用户发出的要求重读配置文件的信号。 这允许我们不必终止或重启服务器程序就改变设置。

2、循环和并发服务器的工作流程
2.1循环服务器的工作流程
面向连接的循环服务器算法
　　1)、创建套接字并将其绑定到它所提供服务的熟知端口上；
　　2)、将该端口设置为被动模式，使其准备为服务器所用；
　　3)、从该套接字上接收下一个连接请求，获得该连接的新的套接字；
　　4)、重复地读取来自客户的请求，构造响应，按照应用协议向客户发回响应；
　　5)、当某个特定客户完成交互时，关闭连接，并返回步骤3以接受新的连接
无连接的循环服务器算法
　　1)、创建套接字并将其绑定到所提供服务的熟知端口上；
2)、重复读取来自客户的请求，构造响应，按照应用协议向客户发回响应。

2.2并发服务器的工作流程
面向连接的并发服务器算法
　　主1、创建套接字并将其绑定到所提供服务的熟知地址上。让该套接字保持为面向连接
　　主2、将该端口设置为被动模式
　　主3、反复调用accept以便接收来自客户的下一个连接请求，并创建新的从线程或者进程来处理响应
　　从1、由主线程传递来的连接请求开始
　　从2、用该连接与客户进行交互；读取请求并发回响应
　　从3、关闭连接并退出
无连接的并发服务器算法
　　主1、创建套接字并将其绑定到所提供服务的熟知地址上。让该套接字保持为未连接的
　　主2、反复调用recvfrom接收来自客户的下一个请求，创建一个新的从线程来处理响应
　　从1、从来自主进程的特定请求以及到该套接字的访问开始
　　从2、根据应用协议构造应答，并用sendto将该应答发回给客户
从3、退出（即：从线程处理完一个请求后就终止）

3、循环和并发服务器的应用场景及程序实例
　　循环服务器容易构建，但是性能差；并发服务器难以构建和设计，但是性能好
3.1、循环服务器的应用场景及程序实例
用于DAYTIME服务的服务器:

Int main(int argc, char *argv[])
{
Struct sockaddr_in fsin;
char *service = “daytime”;
int msock, ssock;
unsigned int alen;
switch(argc)
{
case 1:
break;
case 2:
service = argv[1];
break;
default:
errexit(“usage: TCPdaytmed [port]\n”);
}
msock = passiveTCP(service, QLEN);
while(1)
{
alen = sizeof(fsin);
if((sock = accept(msock, (struct sockaddr *) &fsin, &alen)) < 0)
errexit(“accept failed: %s\n”, strerror(errno));
TCPdaytemed(ssock);
close(ssock);
}
}
passiveTCP隐藏了很多套接字分配和绑定的细节
QLEN:客户连接请求等待队列长度
在循环中，使用accept从主套接字得到一个连接（accept完成三次握手过程）
对于新的连接服务器调用过程TCPdaytimed进行处理
处理完毕继续循环，再次调用accept阻塞
调用TCPdaytimed返回后，主程序关闭改连接的套接字
调用close是从容关闭：TCP保证所有的数据可靠交付给客户（连接终止前收到确认）

3.2、并发服务器的应用场景及程序实例
一个典型的并发服务器程序框架:

pid_t pid;
int listenfd, connfd;
listenfd = Socket(……);
Bind(listenfd, …);
Listen(listenfd, LISTENQ);
for(;;)
{
connfd = Accept(listenfd, …);
if((pid = Fork()) == 0){
Close(listenfd);
doit(connfd);
Close(connfd);
exit(0);
}
Close(connfd);
}

对TCP套接口调用close会引发一个FIN，后跟TCP连接终止序列。
为什么图中父进程connfd的close不终止它写客户的连接呢？
为了搞明白此执行过程，我们必须了解每个文件或套接口都有一个访同计数，该访同计数在文件表项中维护
，它表示当前指向该文件或套接口的打开的描述宇个数。在图中，从socket返回后，与listenfd关联的文件表项访问计数值为1，从accept返回后，与connfd关联的文件表项访问计数值也为1。但是，当fork返回后，两个描述字在父进程与子进程间共享（即复制），所以，与两个套接口相关联的文件表项访问计数值均为2。当父进程关闭connfd时，只是将访问计数值从2减为1。描述字只在访问计数值达到0时才真正关闭。

参考文献：
[1] FreeBSD 开发手册 .freebsd.org/doc/zh_CN.GB2312/books/developers-handbook/sockets-concurrent-servers.html
[2]计算机与网络/高殿武.—北京：机械工业出版社，2010.6
[3]Netscape FastTrack服务器入门到精通，[美]Robert P.Lipschutz John Garris 著，邱仲潘 译
[4]C程序设计/谭浩强著.—3版. —北京：清华大学出版社，2005（2007重印）
[5] edsionte's Linuxworld|新手区