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