socket 编程

流程如下：

socket是应用层和传输层之间的桥梁

套接字连接过程：服务器监听<处于等待连接状态，实时监控网络状态>，客户端请求，确认连接

 

int select( int nfds, fd_set FAR* readfds,　fd_set * writefds, fd_set * exceptfds,　const struct timeval * timeout);

        在默认的阻塞模式下的套接字里，recv会阻塞，直到套接字连接上有数据可读，把数据读到buffer里后recv函数才会返回，不然就会一直阻塞在那里。在单线程的程序里出现这种情况会导致主线程（单线程程序里只有一个默认的主线程）被阻塞,这样整个程序被锁死在这里，如果永 远没数据发送过来，那么程序就会被永远锁死。用ioctlsocket设置成非阻塞模式后recv的调用不管套接字连接上有没有数据可以接收都会马上返回。重复调用recv并检查返回值，直到成功为止，但是这样做效率很成问题，开销太大。select模型的出现就是为了解决上述问题。

select模型的关键是使用一种有序的方式，对多个套接字进行统一管理与调度 。

        用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在同一个线程内同时处理多个IO请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。 

        用于确定一个或多个套接口的状态，对每一个套接口，调用者可查询它的可读性、可写性及错误状态信息，用fd_set结构来表示一组等待检查的套接口，在调用返回时，这个结构存有满足一定条件的套接口组的子集，并且select()返回满足条件的套接口的数目。有一组宏可用于对fd_set的操作

        select()调用返回处于就绪状态并且已经包含在fd_set结构中的描述字总数；如果超时则返回0；否则的话，返回SOCKET_ERROR错误，应用程序可通过WSAGetLastError获取相应错误代码。

        当返回为-1时，所有描述符集清0。

        当返回为0时，表示超时。

        当返回为正数时，表示已经准备好的描述符数。

        select返回后，在3个描述符集里，依旧是1的位就是准备好的描述符。这也就是为什么，每次用select后都要用FD_ISSET的原因。

 

 

转自百科