2

私は、通信層のいくつかのオプションを評価しているクライアント/サーバーアプリケーションを開発しています。

この通信フレームワークの一部として、私は、独自のバイナリ構造を再発明する代わりに、トランスポートデータの表現にGoogleのプロトコルバッファ(PB)を使用することを検討しています。

さて、実際のトランスポートについてですが、これらのバイナリメッセージを送受信するためにプレーンソケットを使用するべきか、それとも何らかのミドルウェアを使用するべきか疑問に思っています。ミドルウェアを使用すると、ソケットに比べて明らかな利点があります。私が気にかけているのは、コミュニケーションモデル-パブリッシュ/サブスクライブ、リクエスト/レスポンス、フェイルオーバーです。

一方、ソケットを使用すると、ミドルウェアアプローチと比較してオーバーヘッドが低くなり、パフォーマンスが向上するという利点があります。

また、プロトコルバッファ(Googleのプロトコルバッファwikiのサードパーティアドオン)で利用可能なRPCライブラリを使用して、クライアントとサーバー間で通信することも考えられます。低レベルのソケットから抽象化しますが、それでもミドルウェア機能をサポートしていません。

現在、私のクライアントはAdobe Flex GUIと2つのサーバー側プロセス(1つはJava、もう1つはC ++)です。将来的には、クライアント側とサーバー側で、.NETなどの他の言語で開発された他のサービスを利用できるようになる可能性があります。

専門家はこれらの選択について、そしてパフォーマンスを損なうことなくうまく機能することを経験からどのように感じていますか。開発者が使用する他の選択肢はありますか?

ありがとうDece

4

2 に答える 2

4

学習演習でない限り、絶対に、積極的にミドルウェアを使用する必要があります。AMQP、ZeroMQ、XMPP、Comet/Bayeuxなどの選択肢がたくさんあります。

シナリオでは、おそらくWebベースのものが必要なので、XMPPoverHTTPが適切なオプションになる可能性があります。しかし、私はコメットに部分的です(バイユーは私のニーズには複雑すぎることがわかりましたが)。

于 2010-10-31T06:24:43.847 に答える
0

どのプラットフォーム?

Windows の場合、ここから入手できる WASP と呼ばれる無料のシンプルで高性能な IO 完了ベースのプラグ可能なサーバー プラットフォームがあります。

DLL を 1 つまたは 2 つ作成してプラグインするだけで、ネットワークの設定は完了です。

現在、プロトコル バッファ ベースのプラグインの例はありませんが、やるべきことのリストに載っています...

于 2010-10-31T09:16:07.913 に答える