為什么會(huì)出現(xiàn)select模型？
先看一下下面的這句代碼：
int iResult = recv(s, buffer,1024);
這是用來接收數(shù)據(jù)的，在默認(rèn)的阻塞模式下的套接字里，recv會(huì)阻塞在那里，直到套接字連接上有數(shù)據(jù)可讀，把數(shù)據(jù)讀到buffer里后recv函數(shù)才會(huì)返
回，不然就會(huì)一直阻塞在那里。在單線程的程序里出現(xiàn)這種情況會(huì)導(dǎo)致主線程（單線程程序里只有一個(gè)默認(rèn)的主線程）被阻塞,這樣整個(gè)程序被鎖死在這里，如果永
遠(yuǎn)沒數(shù)據(jù)發(fā)送過來，那么程序就會(huì)被永遠(yuǎn)鎖死。這個(gè)問題可以用多線程解決，但是在有多個(gè)套接字連接的情況下，這不是一個(gè)好的選擇，擴(kuò)展性很差。
再看代碼：
int iResult = ioctlsocket(s, FIOBIO, (unsigned long *)&ul);
iResult = recv(s, buffer,1024);
這一次recv的調(diào)用不管套接字連接上有沒有數(shù)據(jù)可以接收都會(huì)馬上返回。原因就在于我們用ioctlsocket把套接字設(shè)置為非阻塞模式了。不過
你跟蹤
一下就會(huì)發(fā)現(xiàn)，在沒有數(shù)據(jù)的情況下，recv確實(shí)是馬上返回了，但是也返回了一個(gè)錯(cuò)誤：WSAEWOULDBLOCK，意思就是請求的操作沒有成功完成。
看到這里很多人可能會(huì)說，那么就重復(fù)調(diào)用recv并檢查返回值，直到成功為止，但是這樣做效率很成問題，開銷太大。
select模型的出現(xiàn)就是為了解決上述問題。
select模型的關(guān)鍵是使用一種有序的方式，對多個(gè)套接字進(jìn)行統(tǒng)一管理與調(diào)度。
看核心代碼：（這里只給出服務(wù)端的)
while ( 1 )
{
// 初始化fdset
FD_ZERO( &fdsRead );
// 將server套接字添加到可讀集合中
FD_SET( sockServer, &fdsRead );
// 調(diào)用select
select( 0, &fdsRead, NULL, NULL, &tv );
// 判斷server套接字的狀態(tài)，如果套接字還在可讀集合中，
// 說明有數(shù)據(jù)可以讀入，則建立套接字可以成功
if ( FD_ISSET( sockServer, &fdsRead ) )
{
sockAccept = accept( sockServer, (sockaddr*)&addr, &nLen );
// 有數(shù)據(jù)可讀，進(jìn)行相關(guān)處理
}
當(dāng)然了，這里演示的只是最基礎(chǔ)的select的用法。網(wǎng)絡(luò)通信中的I/O復(fù)用的相關(guān)問題還很多，還需要慢慢學(xué)習(xí)與深入。