一.走進udp協議：
udp（user datagram protocol）協議就是「使用者資料報協議」，它是一種無連線的協議，無連線主要是和tcp協議相比較的。我們知道當利用tcp協議傳送資料的時候，首先必須先建立連線（也就是所謂的握手）才可以傳輸資料。而當計算機利用udp協議進行資料傳輸的時候，傳送方只需要知道對方的ip位址和埠號就可以傳送資料，而並不需要進行連線。當然如果你非要進行連線，通過visual c＃也是可以實現的，但前提是要確定連線的遠端主機的埠號處於監聽狀態，否則程式會出現不必要的錯誤，但這是種畫蛇添足的做法，不僅丟失了udp協議的無連線傳送資料的特點和優點，而且還給程式執行帶來了不安定的因素。所以這種方法並不值得提倡。
由於udp協議並不需要進行確定的連線，所以編寫基於udp協議的應用程式比起編寫基於tcp協議的應用程式要簡單些（程式中可以不需要考慮連線和一些異常的捕獲工作）。但同時也給基於udp協議編寫的程式帶來了乙個致命的缺點，udp由於不提供可靠資料的傳輸，當計算機之間利用udp協議傳送資料的時候，傳送方只管傳送資料，而並不確認資料是否被對方接收。這樣就會導致某些udp協議資料報在傳送的過程中丟失，尤其網路質量不令人滿意的情況下，丟失資料報的現象會更嚴重。這就是為什麼在網路上傳輸重要資料不採用udp協議的原因。
總結一下上面的內容，可見udp是一種不面向連線的網路協議，既有其優點，也有其不足，具體如下：
1.基於udp協議的網路應用程式，實現起來比較簡單，並且基於udp協議的網路應用程式在執行時，由於受到環境影響較小，所以不容易出錯。
2.udp協議占用網路資源較少，資料處理較快，所以在網路中傳送對安全性要求不是十分高資料時，其優點比較明顯。所謂對安全性要求不高的資料，是指那些不重要的資料，或者是即使丟失若干資料，也不影響其整體的資料，如音訊資料等。目前很多流行的網路應用程式都是基於udp協議的，如oicq、icq等。
3.由於其不是面向連線的網路協議，其缺點也是非常明顯的，有些時候甚至是致命的。因為使用udp協議來傳送資料，在資料傳送後，在傳送方並不確認對方是否接收到。這樣就可能導致傳送的資料在網路中丟失，尤其在網路條件並不很好的情況下，丟失資料報的現象就更多。所以傳送重要資料一般不採用udp協議。
二．簡介visual c＃傳送、接收udp資料報使用的主要類及其用法:
用visual c＃實現udp協議，最為常用，也是最為關鍵的類就是udpclient，udpclient位於命名空間system.net.sockets中，visual c＃傳送、接收udp資料報都是通過udpclient類的。表01和表02是udpclient類中常用方法和屬性及其簡要說明。
方法 說明 close 關閉 udp 連線 connect 建立與遠端主機的連線 dropmulticastgroup 退出多路廣播組 joinmulticastgroup 將 udpclient 新增到多路廣播組 receive 返回已由遠端主機傳送的 udp 資料文報 send 將 udp 資料文報傳送到遠端主機
表01：udpclient類中常用方法及其說明。
屬性 說明 active 獲取或設定乙個值，該值指示是否已建立了與遠端主機的連線 client 獲取或設定基礎網路套接字 表02：udpclient類中常用方法及其說明。
1.visual c＃使用udpclient類傳送udp資料報：
在具體使用中，一般分成二種情況：
"send"方法的呼叫語法如下：
public int send ( byte dgram , int bytes , ipendpoint endpoint ) ;
引數說明：
dgram 要傳送的 udp 資料文報（以位元組陣列表示）。
bytes 資料文報中的位元組數。
endpoint 乙個 ipendpoint，它表示要將資料文報傳送到的主機和埠。
返回值 已傳送的位元組數。
下面使用udpclient傳送udp資料報的具體的呼叫例子：
ipaddress hostip = new ipaddress.parse ( "遠端計算機ip位址" ) ;ipendpoint host = new ipendpoint ( hostip , 8080 ) ;udpclient.send ( "傳送的位元組" , "傳送的位元組長度" , host ) ;
（2）. 知道遠端計算機名稱:：
知道遠端計算機名稱後，利用"send"方法直接把udp資料報傳送到遠端主機的指定埠號上了，這種呼叫方式也是最容易的，語法如下：
public int send ( byte[ ] dgram , int bytes , string hostname , int port ) ;
引數說明：
dgram 要傳送的 udp 資料文報（以位元組陣列表示）。
bytes 資料文報中的位元組數。
hostname 要連線到的遠端主機的名稱。
port 要與其通訊的遠端埠號。
返回值 已傳送的位元組數。
2.visual c＃使用udpclient類接收udp資料報：
接收udp資料報使用的是udpclient中的「receive」方法。此方法的呼叫語法如下：
public byte receive ( ref ipendpoint remoteep ) ;
引數 remoteep 是乙個 ipendpoint類的例項，它表示網路中傳送此資料報的節點。
如果指定了遠端計算機要傳送到本地機的埠號，也可以通過偵聽本地埠號來實現對資料的獲取，下面就是通過偵聽本地埠號「8080」來獲取資訊**：
server = new udpclient ( ) ;receivepoint = new ipendpoint (new ipaddress ( "127.0.0.1" ) , 8080 ) ;byte recdata = server.receive ( ref receivepoint ) ;
三．visual c＃實現udp協議之網路對時系統的體系結構及功能簡介：
在區域網中有很多應用軟體為了協同工作，需要保證客戶機上時間統一，而為了實現這一點，通常的做法是客戶機從乙個時間相對正確的伺服器讀取時間，以此來校正本地時間。如經常看到的gps對時系統等。本節編寫的區域網上對時系統的主要的功能是保證區域網上計算機時間、日期的統一。網路對時程式是體系結構分成伺服器端程式和客戶端程式二個部分，具體的作法是：在同乙個網段上，固定一台計算機作為對時的伺服器，在這個網段的所有計算機都可以讀取這台伺服器上的時間和日期，並依此伺服器上的時間和日期為基準，來確定本地的時間和日期。在伺服器端程式需要達到以下功能：
能夠接收區域網中任一台客戶機的請求
記錄請求客戶機的計算機名稱，和請求時間
準確傳送伺服器端的時間和日期
端程式要達到以下功能：
能夠設定伺服器的主機或者ip位址
能夠接收伺服器端傳送的時間、日期資訊
能夠以接收的伺服器端時間、日期為基準，校正本地時間
因此在具體用visual c＃實現網路對時系統時就包括二個部分：伺服器端程式和客戶端程式。下面首先介紹visual c＃實現網路對時系統中伺服器端程式的具體步驟。
四．visual c＃實現網路對時系統之伺服器端程式的具體步驟：
伺服器端程式比客戶端程式相對要簡單，主要因是伺服器端程式的工作比較簡單，就
是接收客戶端的對時請求、傳送伺服器端的時間資料。而於客戶端不僅要傳送和接收資料，還要把伺服器端的時間提取出來，並以此來修改本地計算機的時間、日期。下面是用visual c＃實現網路對時系統之伺服器端程式的具體步驟步驟。
1.啟動visual studio .net。
2.選擇選單【檔案】|【新建】|【專案】後，彈出【新建專案】對話方塊。
3.將【專案型別】設定為【visual c＃專案】。
4.將【模板】設定為【windows應用程式】。
5.在【名稱】文字框中輸入【udp對時伺服器端】。
6.在【位置】的文字框中輸入【e:/vs.net專案】，然後單擊【確定】按鈕
7.在【解決方案資源管理器】視窗中，雙擊form1.cs檔案，進入form1.cs檔案的編輯介面。
8.在form1.cs檔案的開頭，用下列匯入命名空間**替代系統預設的匯入命名空間**。
using system ;using system.drawing ;using system.collections ;using system.componentmodel ;using system.windows.forms ;using system.data ;usi
本文**
Linux目錄管理全面掌握
當前目錄 上一層目錄 前乙個目錄 當前賬戶的主資料夾 chai chai這個賬戶的主資料夾 ps 使用tab進行檔案補齊，是一種好習慣，能夠避免輸錯檔名。cd 切換目錄 pwd 顯示當前所在的目錄 pwd print working directory pwd 輸出當前工作目錄 pwd p 輸出當前...
全面掌握ISO8583報文
我剛進入金融行業時，就知道了is08583報文協議，我想可能我還沒進入這個行業都已經聽過了，可知iso8583的影響力有多大了。最初剛接觸它時，確實對其中的一些細節概念不是很清晰，對有些地方比較迷惑。鑑於此，我想很多同行也必然會經歷同樣得階段，所以我寫下本文，以便大家能夠少走一些彎路。同時，我在網上...
全面掌握SOA 認清SOA面臨的挑戰
面型服務的架構 soa 是一種用於建立和使用業務流程的 計算機系統的架構風格。在其整個生命週期內，soa允許企業應用之間相互交換資料，並且成為業務流程不可或缺的一部分。soa不能單純地只從技術角度看成是一種服務架構，它還是一種策略 做法和框架。使用它我們可以確保所提供的服務是正確的並且被正確使用了。...