套接字

套接字

套接字是一種通信機制,憑藉這種機制,客戶/伺服器系統的開發工作既可以在本地單機上進行,也可以跨網路進行,Linux所提供的功能(如列印服務,ftp等)通常都是通過套接字來進行通信的,套接字的創建和使用與管道是有區別的,因為套接字明確地將客戶和伺服器區分出來,套接字可以實現將多個客戶連接到一個伺服器。

簡介


套接字
套接字
套接字,也稱為BSD套接字,是支持TCP/IP的網路通信的基本操作單元,可以看做是不同主機之間的進程進行雙向通信的端點,簡單的說就是通信的兩方的一種約定,用套接字中的相關函數來完成通信過程。應用層通過傳輸層進行數據通信時,TCP和UDP會遇到同時為多個應用程序進程提供併發服務的問題。
簡單的舉例說明:Socket=Ip address+ TCP/UDP + port。

具體流程


套接字
套接字
1、創建套接字――socket()
功能:使用前創建一個新的套接字
格式:SOCKET PASCAL FAR socket(int af,int type,int procotol);
參數:af: 通信發生的區域
type: 要建立的套接字類型
procotol: 使用的特定協議
2、指定本地地址――bind()
功能:將套接字地址與所創建的套接字型大小聯繫起來。格式:int PASCAL FAR bind(SOCKET s,const struct sockaddr FAR * name,int namelen);
參數:s: 是由socket()調用返回的並且未作連接的套接字描述符(套接字型大小)。
其它:沒有錯誤,bind()返回0,否則SOCKET_ERROR。
3、建立套接字連接――connect()和accept()功能:共同完成連接工作格式:int PASCAL FAR connect(SOCKET s,const struct sockaddr FAR * name,int namelen);SOCKET PASCAL FAR accept(SOCKET s,struct sockaddr FAR * name,int FAR * addrlen);參數:同上4、監聽連接――listen()功能:用於面向連接伺服器,表明它願意接收連接。格式:int PASCAL FAR listen(SOCKET s, int backlog);5、數據傳輸――send()與recv()功能:數據的發送與接收格式:int PASCAL FAR send(SOCKET s,const char FAR * buf,int len,int flags);int PASCAL FAR recv(SOCKET s,const char FAR * buf,int len,int flags);參數:buf:指向存有傳輸數據的緩衝區的指針6、多路復用――select()功能:用來檢測一個或多個套接字狀態。格式:int PASCAL FAR select(int nfds,fd_set FAR * readfds,fd_set FAR * writefds,fd_set FAR * exceptfds,const struct timeval FAR * timeout);參數:readfds:指向要做讀檢測的指針writefds:指向要做寫檢測的指針exceptfds:指向要檢測是否出錯的指針timeout:最大等待時間7、關閉套接字――closesocket()功能:關閉套接字s格式:BOOL PASCAL FAR closesocket(SOCKET s);基本分類
套接字
套接字
常用的TCP/IP協議的3種套接字類型如下所示。流套接字(SOCK_STREAM):流套接字用於提供面向連接、可靠的數據傳輸服務。該服務將保證數據能夠實現無差錯、無重複發送,並按順序接收。流套接字之所以能夠實現可靠的數據服務,原因在於其使用了傳輸控制協議,即TCP(The Transmission Control Protocol)協議。數據報套接字(SOCK_DGRAM):數據報套接字提供了一種無連接的服務。該服務並不能保證數據傳輸的可靠性,數據有可能在傳輸過程中丟失或出現數據重複,且無法保證順序地接收到數據。數據報套接字使用UDP(User Datagram Protocol)協議進行數據的傳輸。由於數據報套接字不能保證數據傳輸的可靠性,對於有可能出現的數據丟失情況,需要在程序中做相應的處理。原始套接字(SOCK_RAW):原始套接字(SOCKET_RAW)允許對較低層次的協議直接訪問,比如IP、 ICMP協議,它常用於檢驗新的協議實現,或者訪問現有服務中配置的新設備,因為RAW SOCKET可以自如地控制Windows下的多種協議,能夠對網路底層的傳輸機制進行控制,所以可以應用原始套接字來操縱網路層和傳輸層應用。比如,我們可以通過RAW SOCKET來接收發向本機的ICMP、IGMP協議包,或者接收TCP/IP棧不能夠處理的IP包,也可以用來發送一些自定包頭或自定協議的IP包。網路監聽技術很大程度上依賴於SOCKET_RAW原始套接字與標準套接字(標準套接字指的是前面介紹的流套接字和數據報套接字)的區別在於:原始套接字可以讀寫內核沒有處理的IP數據包,而流套接字只能讀取TCP協議的數據,數據報套接字只能讀取UDP協議的數據。因此,如果要訪問其他協議發送數據必須使用原始套接字。主要參數
套接字
套接字
區分不同應用程序進程間的網路通信和連接,主要有3個參數:通信的目的IP地址、使用的傳輸層協議(TCP或UDP)和使用的埠號。Socket原意是“插座”。通過將這3個參數結合起來,與一個“插座”Socket綁定,應用層就可以和傳輸層通過套接字介面,區分來自不同應用程序進程或網路連接的通信,實現數據傳輸的併發服務。Socket可以看成在兩個程序進行通訊連接中的一個端點,是連接應用程序和網路驅動程序的橋樑,Socket在應用程序中創建,通過綁定與網路驅動建立關係。此後,應用程序送給Socket的數據,由Socket交給網路驅動程序向網路上發送出去。計算機從網路上收到與該Socket綁定IP地址和埠號相關的數據后,由網路驅動程序交給Socket,應用程序便可從該Socket中提取接收到的數據,網路應用程序就是這樣通過Socket進行數據的發送與接收的。

分類介紹


Host A上的程序A將一段信息寫入Socket中,Socket的內容被Host A的網路管理軟體訪問,並將這段信息通過Host A的網路介面卡發送到Host B,Host B的網路介面卡接收到這段信息后,傳送給Host B的網路管理軟體,網路管理軟體將這段信息保存在Host B的Socket中,然後程序B才能在Socket中閱讀這段信息。假設在網路中添加第三個主機Host C,那麼Host A怎麼知道信息被正確傳送到Host B而不是被傳送到Host C中了呢?基於TCP/IP網路中的每一個主機均被賦予了一個唯一的IP地址,IP地址是一個32位的無符號整數,由於沒有轉變成二進位,因此通常以小數點分隔,如:198.163.227.6,正如所見IP地址均由四個部分組成,每個部分的範圍都是0-255,以表示8位地址。值得注意的是IP地址都是32位地址,這是IP協議版本4(簡稱Ipv4)規定的,目前由於IPv4地址已近耗盡,所以IPv6地址正逐漸代替Ipv4地址,Ipv6地址則是128位無符號整數。假設第二個程序被加入的網路的Host B中,那麼由Host A傳來的信息如何能被正確的傳給程序B而不是傳給新加入的程序呢?這是因為每一個基於TCP/IP網路通訊的程序都被賦予了唯一的埠和埠號,埠是一個信息緩衝區,用於保留Socket中的輸入/輸出信息,埠號是一個16位無符號整數,範圍是0-65535,以區別主機上的每一個程序(埠號就像房屋中的房間號),低於256的埠號保留給標準應用程序,比如pop3的埠號就是110,每一個套接字都組合進了IP地址、埠、埠號,這樣形成的整體就可以區別每一個套接字。
相關分析Host A上的程序A將一段信息寫入Socket中,Socket的內容被Host A的網路管理軟體訪問,並將這段信息通過Host A的網路介面卡發送到Host B,Host B的網路介面卡接收到這段信息后,傳送給Host B的網路管理軟體,網路管理軟體將這段信息保存在Host B的Socket中,然後程序B才能在Socket中閱讀這段信息。假設在圖1的網路中添加第三個主機Host C,那麼Host A怎麼知道信息被正確傳送到Host B而不是被傳送到Host C中了呢?基於TCP/IP網路中的每一個主機均被賦予了一個唯一的IP地址,IP地址是一個32位的無符號整數,由於沒有轉變成二進位,因此通常以小數點分隔,如:198.163.227.6,正如所見IP地址均由四個部分組成,每個部分的範圍都是0-255,以表示8位地址。值得注意的是IP地址都是32位地址,這是IP協議版本4(簡稱Ipv4)規定的,目前由於IPv4地址已近耗盡,所以IPv6地址正逐漸代替Ipv4地址,Ipv6地址則是128位無符號整數。假設第二個程序被加入圖1的網路的Host B中,那麼由Host A傳來的信息如何能被正確的傳給程序B而不是傳給新加入的程序呢?這是因為每一個基於TCP/IP網路通訊的程序都被賦予了唯一的埠和埠號,埠是一個信息緩衝區,用於保留Socket中的輸入/輸出信息,埠號是一個16位無符號整數,範圍是0-65535,以區別主機上的每一個程序(埠號就像房屋中的房間號),低於256的短口號保留給標準應用程序,比如pop3的埠號就是110,每一個套接字都組合進了IP地址、埠、埠號,這樣形成的整體就可以區別每一個套接字。

流式套接字


套接字
套接字
它是兩種可用的 Windows Sockets 類型中的一種。(另一種類型是數據文報套接字。)
流式套接字提供沒有記錄邊界的數據流:可以是雙向的位元組流(應用程序是全雙工:可以通過套接字同時傳輸和接收)。可依賴流傳遞有序的、不重複的數據。(“有序”指數據包按發送順序送達。“不重複”指一個特定的數據包只能獲取一次。)這能確保收到流消息,而流非常適合處理大量數據。網路傳輸層可將數據拆分為分組或若干個大小適當的數據包。CSocket 類將為您處理打包和解包。流基於顯式連接:套接字A請求與套接字B建立連接;套接字B接受或拒絕此連接請求。打電話的情況與流非常相似:正常情況下,接聽方聽到您的話和您講話時的順序一樣,沒有重複和遺漏。流套接字適合文件傳輸協議(FTP) 這類實現,此協議有利於傳輸任意大小的 ASCII 或二進位文件。如果必須保證數據送達而且數據大小很大時,流式套接字優於數據文報套接字。有關流式套接字的更多信息,請參見 Windows Sockets 規範。該規範可在 Platform SDK 中獲得。MFC 示例 CHATTER 和 CHATSRVR 都使用流式套接字。這些示例可能已經設計為使用數據文報套接字向網路上的所有接收套接字廣播。而目前的設計更好,這是因為:廣播模型受制於網路“洪水”(或“風暴”)問題。後來採用的客戶端-伺服器模型更有效。流式模型提供可靠的數據傳輸,數據文報模型則未提供。最終模型利用在 CArchive 類借給 CSocket 類的 Unicode 和 ANSI 套接字應用程序之間通信的能力。注意事項如果使用 CSocket 類,則必須使用流。如果將套接字類型指定為 SOCK_DGRAM ,則 MFC 斷言失敗Windows Sockets 示例列表下列 MFC 示常式序闡釋了 Windows Sockets 功能:CHATTERCHATTER 是一個 Windows 套接字客戶端示例應用程序。它是一個具有拆分窗口的單文檔界面 (SDI) 應用程序,允許用戶將消息發送到討論伺服器(CHATSRVR),討論伺服器然後將消息同時發送給其他多個 CHATTER 用戶。通過使 CHATTER 應用程序向伺服器發送廣播數據文報包而不是消息流,可以在不使用客戶端/伺服器模型的情況下編寫 CHATTER 和 CHATSRVR。然而,與流式套接字不同,數據文報套接字不能保證一定會被傳送;因此,一些消息可能不會到達討論中的所有其他用戶。運行示例生成並運行 CHATTER 示例打開解決方案 chatter.sln。在“生成”菜單上單擊“生成”。在“調試”菜單上單擊“開始執行(不調試)”。運行 CHATTER 時,有一個“Setup”對話框請求輸入以下內容:Handle用來定址所有消息的名稱。例如,可以選擇“”。發送的所有消息的前面都會自動加上名稱“”。Server運行 CHATSVR 示例的計算機的 IP 地址。Channel標識要加入的討論的數字(一台計算機可以運行多個討論伺服器)。提供了所有這些信息並單擊“OK”后,主應用程序窗口隨即出現。若要發送消息,請在下部窗格中鍵入消息。按 ENTER 鍵發送消息。若要發送多行消息,請按 CTRL+ENTER 鍵。關鍵字示例此示例說明了以下關鍵字:AfxGetApp、AfxMessageBox、CArchive::Flush、CArchive::IsStoring、CControlBar::EnableDocking、CControlBar::GetBarStyle、CControlBar::SetBarStyle、CDialog::DoModal、CDocument::DeleteContents、CDocument::GetFirstViewPosition、CDocument::GetNextView、CDocument::OnNewDocument、CEditView::GetEditCtrl、CEditView::SerializeRaw、CFrameWnd::DockControlBar、CFrameWnd::EnableDocking、CFrameWnd::OnCreateClient、CFrameWnd::SetActiveView、CObject::AssertValid、CObject::Dump、CObject::IsKindOf、CObject::Serialize、CRect::Size、CSplitterWnd::CreateView、CSplitterWnd::GetPane、CStatusBar::Create、CStatusBar::SetIndicators、CString::GetBuffer、CString::GetLength、CString::IsEmpty、CString::LoadString、CString::ReleaseBuffer、CToolBar::Create、CToolBar::LoadBitmap、CToolBar::SetButtons、CView::GetDocument、CView::OnDraw、CWinApp::AddDocTemplate、CWinApp::InitInstance、CWinApp::LoadStdProfileSettings、CWinApp::OnFileNew、CWnd::DestroyWindow、CWnd::DoDataExchange、CWnd::GetClientRect、CWnd::GetWindowText、CWnd::GetWindowTextLength、CWnd::KillTimer、CWnd::OnChar、CWnd::OnCreate、CWnd::OnTimer、CWnd::PreCreateWindow、CWnd::SetTimer、CWnd::SetWindowText、SetWindowText、rand、wsprintf注意一些示例(如此示例)尚未經過修改以反映 Visual C++ 嚮導、庫和編譯器的變化,但仍說明了如何完成所需的任務。參見MFC 示例CHATSRVRCHATSRVR 是 Windows 套接字伺服器示例應用程序,它是一個單文檔界面 (SDI) 應用程序,用於為 CHATTER 示例的客戶端實現討論伺服器。通過使 CHATTER 應用程序向伺服器發送廣播數據文報包而不是消息流,可以在不使用客戶端/伺服器模型的情況下編寫 CHATTER和 CHATSRVR。然而,與流式套接字不同,數據文報套接字不能保證一定會被傳送;因此,一些消息可能不會到達討論中的所有其他用戶。生成並運行示例生成並運行 CHATSRVR 示例打開解決方案 chatsrvr.sln。在“生成”菜單上單擊“生成”。在“調試”菜單上單擊“開始執行(不調試)”。運行 CHATSRVR 時會顯示一個請求輸入“Channel”的“Discussion”對話框。“Channel”是標識要支持的討論的數字(一台計算機可以運行多個討論伺服器)。提供了此信息並單擊“OK”后,主應用程序窗口隨即出現。關鍵字通信要通過Internet進行通信,至少需要一對套接字,其中一個運行在客戶端,稱之為ClientSocket,另一個運行於伺服器端面,稱為ServerSocket。根據連接啟動的方式以及本地要連接的目標,套接字之間的連接過程可以分為三個步驟:伺服器監聽、客戶端請求、連接確認。伺服器監聽是指服務端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網路狀態。客戶端請求是由客戶端的套接字提出連接請求,要連接的目標是伺服器端套接字。為此,客戶端的套接字必須首先描述它要連接的伺服器的套接字,指出伺服器套接字的地址和埠號,然後再向伺服器端套接字提出連接請求。連接確認是當伺服器端套接字監聽到或者說接收到客戶端套接字的連接請求時,它就響應客戶端套接字的請求,建立一個新的線程,把伺服器端套接字的信息發送給客戶端,一旦客戶端確認了此連接,連接即可建立。而伺服器端繼續處於監聽狀態,繼續接收其他客戶端的連接請求。使用套接字進行數據處理有兩種基本模式:同步和非同步。同步模式:同步模式的特點是在通過Socket進行連接、接收、發送數據時,客戶機和伺服器在接收到對方響應前會處於阻塞狀態,即一直等到收到對方請求進才繼續執行下面的語句。可見,同步模式只適用於數據處理不太多的場合。當程序執行的任務很多時,長時間的等待可能會讓用戶無法忍受。非同步模式:非同步模式的特點是在通過Socket進行連接、接收、發送操作時,客戶機或伺服器不會處於阻塞方式,而是利用callback機制進行連接、接收、發送處理,這樣就可以在調用發送或接收的方法后直接返回,並繼續執行下面的程序。可見,非同步套接字特別適用於進行大量數據處理的場合。使用同步套接字進行編程比較簡單,而非同步套接字編程則比較複雜。