遠程VS插座

Question

就是把差異，優勢和遠程處理和插座之間......其缺點是服務器 - 客戶端的功能....

Answer 1

套接字是兩個端點之間的原始二進制流最好的辦法。您需要封裝自己的RPC（etc）層來處理消息，並處理大量的基礎架構代碼。但是，由於它們非常接近金屬，所以它非常非常高效。它不受限於任何特定的體系結構，只要兩端使用相同的消息格式即可。像protobuf-net這樣的工具可以幫助您爲流構建二進制消息（而不是滾動您自己的序列化代碼）。

遠程處理是一個.NET特定的工具，並且非常脆弱的重新版本控制。我不會建議客戶端/服務器的遠程處理 - 使用像WCF這樣的東西來代替。

WCF是一個更靈活的通信堆棧 - 功能和複雜性很高，但可以說有點臃腫（XML，複雜的安全性等）。它是基於數據合同的，因此大致上是 open（客戶端/服務器可以不同），但仍然有點關注.NET。

---

編輯有關信息，protobuf-net提供了一個RPC堆棧太多;目前只提供了HTTP實現，但在某些時候我會添加原始TCP/IP。

Answer 2

我的第二大馬克格雷維爾寫道 - 特別是遠程處理和內部序列化是「容易」，但很容易打破，往往不能很好地擴展到公共網絡（我不熟悉.net遠程處理，但我想它需要一個衆所周知的註冊表服務，這在清理實驗室環境時經常會遇到問題）。

從長遠來看，實現一個標準甚至是滾動你自己的RPC是比較困難但更安全的：你沒有代碼修訂問題（或者它們更容易控制），縮放完全由你自己的代碼控制，並且易於使用各種技術開發組件。

有許多許多工具可以幫助您輕鬆地在套接字上構建RPC機制，但我真的很喜歡使用普通的舊HTTP--在服務器進程中獲取一個運行在內部的簡單HTTP嵌入式服務器，並且客戶端只需要一個HTTP客戶端發送消息。如果你開發自己的簡單的RESTful調用語義（而不是使用像SOAP或XML-RPC這樣的一些臃腫的消息格式），那麼真的幾乎沒有任何事情要做:-)

Answer 3

我會說，選擇之間的套接字和遠程處理更好地考慮你正在開發什麼類型的應用程序。套接字絕對適用於您自己的協議實現，低層次編程以及必須與其他tcp/ip應用程序通信的唯一途徑。遠程處理是開發新的.NET通信應用程序的一種優先方式，在這種應用程序中，您不需要使用tcp/ip堆棧，並確保您的應用程序與其他應用程序（可能是傳統應用程序）進行對話。如果你只能使用.NET，最好選擇.NET 3.5和WCF框架而不是.net 2.0遠程處理，最後一種是死的和不支持的技術。

Answer 4

與Remoting或WCF相比，直接套接字操作可以爲您提供更多的功能，靈活性和性能，並且不幸的是複雜性。但是，如果您需要低級別TCP/IP（如非阻塞IO和自定義協議）的好處，則可以使用諸如Ragel之類的工具和Mina之類的框架來減輕複雜性。我建議首先嚐試像WCF這樣的更高級別的API，如果這些API不能滿足您的需求，則只能使用直接套接字。