remoting vsソケット

Question

リモートとソケットの間の差分、長所と短所は何ですか...サーバクライアント機能のための最良の方法です....

Answer 1

ソケットは2つのエンドポイント間の生のバイナリストリームです。メッセージを処理するために独自のRPC（etc）レイヤーをラップし、多くのインフラストラクチャコードを処理する必要があります。しかし、それらは金属に非常に近いので、これは非常に、非常に効率的であり得る。両方のエンドが同じメッセージフォーマットを話す限り、特定のアーキテクチャーに結びついていません。 protobuf-netのようなツールは、独自のシリアライゼーションコードを動かすのではなく、ストリームのバイナリメッセージを構築するのに役立ちます。

Remotingは.NET固有のツールであり、非常に脆弱なバージョン管理です。代わりに、WCFのようなクライアント/サーバー用のものをリモーティングすることはお勧めしません。

WCFは、より柔軟性の高い通信スタックです。多くの電力と複雑さがありますが、間違いなく膨らんでいます（xml、複雑なセキュリティなど）。それはデータコントラクトベースなので、おおよそ（クライアント/サーバは異なる可能性があります）ですが、まだ.NETに焦点を当てています。詳細については

---

編集、protobuf-netがあまりにもRPCスタックを提供します。現時点ではHTTP実装のみが提供されていますが、ある時点では未処理のTCP/IPを追加します。

Answer 2

Marc Gravellが書いているのは、リモーティングと内部シリアル化が「簡単」ですが、非常に簡単ですが、パブリックネットワークにはうまく適合しません（ネットリモーティングはあまりよくありませんがクリーンなラボ環境から外出するときによく問題となるよく知られたレジストリサービスが必要だと思います）。

標準的なRPCを実装することは難しくなりますが、長期的にはより安全です。コードリビジョンに問題がない（または制御しやすくなります）スケーリングは独自のコードで完全に制御され、さまざまな技術を使用したコンポーネントの開発が容易です。

ソケットを介してRPCメカニズムを簡単に構築するのに役立つ多くのツールがありますが、普通のHTTPを使用するのが本当に好きです。サーバープロセス内で実行される単純なHTTP組み込みサーバーを取得し、クライアントにはHTTPメッセージを送信するクライアント。

Answer 3

私は、ソケットとリモーティングを選択することで、あなたのRESTfulなコールセマンティクスを（SOAPやXML-RPCのような膨大なメッセージフォーマットを使用する代わりに）開発する場合、実際にはほとんど何もしません。どのタイプのアプリケーションを開発しているかをよく検討してください。ソケットは、独自のプロトコル実装、低レベルプログラミング、そして他のtcp/ipアプリケーションと通信する必要がある場合には唯一の方法です。 Remotingは、tcp/ipスタックに落ちる必要がなく、アプリケーションが他のアプリケーション（おそらくレガシーアプリケーション）と通信する必要がない、新しい.NET通信アプリケーションを開発するための好ましい方法です。 .NETでしか動かない場合は、.net 2.0の代わりに.NET 3.5とWCFフレームワークを選択する方がいいです。最後の1つは死んでサポートされていないテクノロジです。

Answer 4

RemotingまたはWCFと比較して、ダイレクトソケット操作により、より多くの消費電力、柔軟性、パフォーマンス、および残念ながら複雑さがもたらされます。しかし、ノンブロッキングIOやカスタムプロトコルなどの低レベルTCP/IPの利点が必要な場合は、RagelなどのツールとMinaなどのフレームワークを使用すると、複雑さが軽減されます。 WCFのような上位レベルのAPIを最初に試しておき、あなたのニーズを満たしていない場合は直接ソケットを使うことをお勧めします。