TCP或UDP幫助與C＃中的服務器/客戶端？

Question

任何人都可以幫忙，我試圖弄清楚我需要做什么，我得到了用TCP（UDP）編寫服務器和客戶端的任務。 基本上，多個客戶端將連接到服務器。服務器將MESSSAGES發送到客戶端。

我在創建服務器和客戶端時沒有問題，但是使用tcp我不確定該走哪條路。 .net 3.5是否支持所有功能，還是我需要繼續尋找某些組件？

我正在尋找適用於TCP或UDP的C＃好的示例。 這就是我不確定100％的地方..據我所知，有UDP和TCP ... 1已連接，而1沒有。.那么我走哪條路，C＃可以同時支持兩者？ 優點缺點？

假設服務器必須支持多個客戶端，而我只需要打開1個端口還是我需要打開2個端口？

另外，如果客戶端崩潰，我需要它不影響服務器，因此服務器可以忽略它並在打開或超時的情況下關閉連接...如果實際上再次需要連接，請返回到tcp udp

有什么想法我應該開始嘗試並選擇我需要分配的協議和端口數量嗎？

謝謝

Answer 1

UDP缺點：

• 數據包大小限制意味着您只能發送小消息（少於約1.5k字節）。
• 流的缺乏使UDP的安全變得困難：難以進行可用於有損交換的身份驗證方案，並且難以保護單個消息的完整性和機密性（沒有密鑰狀態可依賴）。
• 沒有傳遞保證意味着您的目標必須准備好應對消息丟失。 現在很容易就認為，如果目標能夠處理消息的總損失（這是可能的），那么為什么還要把他們擺在首位？

UDP優點：

• 無需為每個客戶端在服務器上存儲系統終結點（即沒有套接字）。 這是連接到成千上萬個客戶端的MMO游戲使用UDP的主要原因之一。
• 速度：每個消息都是單獨路由的事實意味着您無法像TCP那樣遇到流擁塞。
• 廣播：UDP可以廣播給網段上的所有偵聽器。

如果您也考慮使用TCP，那么甚至不應該考慮使用UDP。 如果您正在考慮使用TCP，則意味着您在考慮流（ 按順序發送消息一次 ），而使用UDP將給您的應用帶來碎片，重試和確認，重復檢測和排序的負擔。 您將立即在您的應用程序中重塑TCP，並且所有工程師花了20年的時間才實現了這一權利（或者至少與IPv4一樣正確）。

如果您不熟悉這些主題，我建議您順其自然，並使用WCF，至少它給您帶來相對方便地切換各種傳輸和協議的優點。 如果您使用原始的.Net套接字組件選擇錯誤，則將代碼庫從TCP更改為UDP的難度將更大，反之亦然。

Answer 2

在我看來，您不清楚TCP和UDP之間的區別。

TCP是面向連接的。 即2個對等方將建立專用連接。 包傳送和訂購得到保證。 通常，一台服務器將提供一個端口，並且多個客戶端可以連接到該端口（例如HTTP服務器和瀏覽器）。

UDP是無連接的。 它不能保證數據包的交付或訂購。 您可以非常輕松地實現廣播和多播機制。 如果需要某種可靠性，則必須在UDP之上實現這一點。 有時您可能不在乎，僅發出請求並重試無響應（SNMP會這樣做）。 因為它是無連接的，所以您實際上不必擔心對等對象處於上升/下降狀態。 您只需要根據需要重試。

因此，您的協議選擇由上述決定。 例如，您的客戶端是否需要與服務器的專用連接？ 您是否正在將相同的數據傳輸到多個客戶端？ 您可以忍受丟包（例如實時價格更新等）嗎？ 將TCP和UDP都用於您應用中的不同要求也許是可行的（例如，TCP用於注冊訂單，UDP用於傳輸價格更新/事件？）

我會考慮您的要求，並熟悉TCP和UDP的局限性和功能。 那應該使事情更加清楚。

Answer 3

是否需要在如此低的級別上執行此操作？ 為什么不使用WCF？ 它使用二進制數據傳輸完全支持通過TCP / IP進行消息傳遞，但是它的抽象級別比原始套接字高得多。

Answer 4

您需要的所有內容都在.Net 3.5（可能還有以下內容）中。 在MSDN上查看有關UdpClient類的文檔和示例，以深入了解如何編寫客戶端/服務器。 一個快速的Google在www.java2s.com上找到了一些服務器和客戶端的示例代碼，以及C＃中的許多其他網絡示例。 不要被域名推遲。