socket之select模型中各函数杂谈

inet_aton()是一个改进的方法来将一个字符串IP地址转换为一个32位的网络序列IP地址。

    if (inet_aton("127.0.0.1", (struct in_addr *) &dest.sin_addr.s_addr) == 0) {        perror("127.0.0.1");        exit(errno);    }

   

在最开始接触bind的时候，只是在写基于tcp的server端的时候，知道在listen之前需要先bind一下，用来确保socket能在某个固定的端口监听。而bind的时候，函数参数中的端口填自己将要绑定的端口就行；而IP地址，需要填本机的IP，但是也可以用一个宏INADDR_ANY代替，用这个宏就可以不用查找本机的IP，它就可以代替本机的IP。当时只觉得这个INADDR_ANY比较神奇，但是由于当时觉得用起来很方便，也没出啥问题，也就没有再深究。
　　但是最近在做RTSP服务器的时候，有种特殊的应用，导致我不得不对bind这个函数仔细地看一下。
　　我们知道无论是UDP还是TCP，socket都会与一个本地的IP和端口想对应，我们往往把这个IP和端口称之为socket的源地址和源端口。当我们作为客户端利用socket去发送数据时，很少会去考虑这个源地址和源端口到底是什么，我们更关心的是它的目的地址和端口。我们往往只有在监听的时候，才去考虑这个源端口，所以我们在监听的时候会去用bind。当我们bind之后，内核就会将这个socket的源端口锁定到我们设定的端口上。但是这就有一个问题，这个bind绑定端口，是将本来没有源端口的socket绑定到我们指定的端口上，还是将一个已经分配了端口的socket重定向到我们指定的端口上呢？
　　在《UNIX网络编程》这本书中提到：“如果一个TCP客户或者服务器未曾调用bind捆绑一个端口，当调用connect或listen时，内核就要为相应的套接字选择一个临时接口。”从这句话中可以判断出，其实在调用socket函数创建socket时，内核还并未给socket分配源地址和源端口。而对于UDP，我猜测在调用sendto发送数据时，在未捆绑端口的情况下，内核也会随机分配端口。
　　而我遇到的特殊应用要求我在用UDP发送数据之前要告诉对方我的发送端口，这也就意味着我在sendto之前必须要捆绑端口，因此我在发送数据之前就得调用bind函数绑定一下端口了。但是我就在想内核既然有随机分配端口的能力，而我需要的也只是让它绑定一下而不用绑定在固定端口的业务，socket中应该能够提供这种业务。然后果然我发现bind就具备这种能力，当bind的参数中端口地址为0的时候，这时候就是由内核分配端口。这样我就不用考虑端口地址重复的问题，而放心的把这个问题交给内核处理了。
　　就在发现bind的这个机制的同时，我发现其实bind对于源地址也同样具备这种处理方式，当系统具有多IP（多网卡）的情况，当我们把bind函数中的ip参数置0时，就是由内核自己选择分配IP。而之前一直觉得很神奇的INADDR_ANY其实一点也不神奇，它的值其实就是0。所以当我们只有单一IP的时候，我们就可以用INADDR_ANY去代替那个单一的IP，因为内核分配的时候只能选择这一个IP。从而造成了INADDR_ANY就是本机IP的现象。

    if (bind(sockfd, (struct sockaddr *) &my_addr, sizeof(struct sockaddr))        == -1) {        perror("bind");        exit(1);    }

waitpid（）是会阻塞的，当然它可以设置成非阻塞模式，通过设置WNOHANG选项

static void sigchld_handler(){pid_t PID;intstatus;/**/while(PID=waitpid(-1, &status, WNOHANG)>0){printf("child %d is ended!\n",PID);}/**/signal(SIGCHLD,sigchld_handler);} 

listen函数

摘要:listen函数使用主动连接套接口变为被连接套接口，使得一个进程可以接受其它进程的请求，从而成为一个服务器进程。在TCP服务器编程中listen函数把进程变为一个服务器，并指定相应的套接字变为被动连接。

listen函数在一般在调用bind之后-调用accept之前调用，它的函数原型是：

int listen(int sockfd, int backlog)

参数sockfd

被listen函数作用的套接字，sockfd之前由socket函数返回。在被socket函数返回的套接字fd之时，它是一个主动连接的套接字，也就是此时系统假设用户会对这个套接字调用connect函数，期待它主动与其它进程连接，然后在服务器编程中，用户希望这个套接字可以接受外来的连接请求，也就是被动等待用户来连接。由于系统默认时认为一个套接字是主动连接的，所以需要通过某种方式来告诉系统，用户进程通过系统调用listen来完成这件事。

参数backlog

这个参数涉及到一些网络的细节。进程处理一个一个连接请求的时候，可能还存在其它的连接请求。因为TCP连接是一个过程，所以可能存在一种半连接的状态，有时由于同时尝试连接的用户过多，使得服务器进程无法快速地完成连接请求。如果这个情况出现了，服务器进程希望内核如何处理呢？内核会在自己的进程空间里维护一个队列以跟踪这些完成的连接但服务器进程还没有接手处理或正在进行的连接，这样的一个队列内核不可能让其任意大，所以必须有一个大小的上限。这个backlog告诉内核使用这个数值作为上限。

毫无疑问，服务器进程不能随便指定一个数值，内核有一个许可的范围。这个范围是实现相关的。很难有某种统一，一般这个值会小30以内。

accept函数

摘要:accept()用来接受参数s的socket连接，它的函数原型是：

int  accept(int s,struct sockaddr * addr,int * addrlen)；

服务程序调用accept函数从处于监听状态的流套接字s的客户连接请求队列中取出排在最前的一个客户请求，并且创建一个新的套接字来与客户套接字创建连接通道，如果连接成功，就返回新创建的套接字的描述符，以后与客户套接字交换数据的是新创建的套接字；如果失败就返回 INVALID_SOCKET。该函数的第一个参数指定处于监听状态的流套接字；操作系统利用第二个参数来返回新创建的套接字的地址结构；操作系统利用第三个参数来返回新创建的套接字的地址结构的长度。