12

現在、私は Windows でマルチプロセス デスクトップ アプリケーションに取り組んでいます。このアプリケーションは、世界中のクライアント マシンに展開されるシュリンク ラップされたアプリケーションになります。.Net 4.0 CF を搭載した Windows XP SP3 など、マシンの幅広い仕様を設定できますが、それらを制御することはできません。また、マシンの構成を具体的に指定することはできません。たとえば、マシンに cuda 1.4 対応のグラフィック プロセッサが必要であるとは指定できません。等

これらのプロセスには、管理されているもの (.Net 4.0) と管理されていないもの (C++ Win32) があります。プロセスはデータを共有する必要があります。これまでに評価したオプションは次のとおりです。

  • TCP ソケット
  • 名前付きパイプ

パイプの方が少しパフォーマンスが良いように見えますが、私たちのニーズでは、どちらのパフォーマンスも許容範囲内です。また、ソケットは、将来、マシン (およびオペレーティング システム - 最終的には Microsoft 以外の OS をサポートしたいと考えています) の境界を越える柔軟性を提供するため、ソケットを使用することを好みます。

ただし、私の主な懸念は次のとおりです。Tcp ソケットを使用する場合、ファイアウォールで問題が発生する可能性はありますか? IPC に TCP を使用するデスクトップ アプリケーション/プログラムを展開し、問題を経験した人はいますか? もしそうなら - どんな種類の？

これはかなりオープンエンドの質問であることは承知しており、喜んで言い換えます。しかし、どのような潜在的な問題に遭遇する可能性があるかを知りたいです。

編集:もう少し光を当てるために - 少数の POD、int、float、および string のみを転送しています。リクエスト/レスポンスとサブスクリプションという 2 つのパラダイムを提供する抽象化のレイヤーを構築しました。トランスポート層は抽象化されており、現在、パイプ ベースと TCP ベースの 2 つの実装があります。

4

3 に答える 3

8

多くの場合、パイプのパフォーマンスは高速な LAN で優れていますが、TCP は低速のネットワークや WAN で優れています。以下の msdn ポイントを参照してください。

TPC は、より構成可能でもあります。ファイアウォールに関しては、通信ポートを開閉できます。それがオプションまたは懸念事項でない場合、代わりに http (REST/json、Web サービス、xml rpc など) を使用できますが、http のオーバーヘッドが許容できるかどうかを検討する必要があります。実世界のデータセットで試してみてください (テストで些細なデータを渡すと、オーバーヘッドが不合理に見えますが、これは実世界のデータセットでは非常に合理的です)。

msdnからのその他の情報:

高速なローカル エリア ネットワーク (LAN) 環境では、伝送制御プロトコル/インターネット プロトコル (TCP/IP) ソケット クライアントと名前付きパイプ クライアントは、パフォーマンスの点で同等です。ただし、TCP/IP ソケット クライアントと名前付きパイプ クライアントのパフォーマンスの違いは、ワイド エリア ネットワーク (WAN) やダイヤルアップ ネットワークなど、低速のネットワークでは明らかになります。これは、プロセス間通信 (IPC) メカニズムがピア間で通信する方法が異なるためです。

名前付きパイプの場合、ネットワーク通信は通常、よりインタラクティブです。ピアは、別のピアが読み取りコマンドを使用してデータを要求するまで、データを送信しません。通常、ネットワーク読み取りには、データの読み取りを開始する前に、一連の名前付きパイプ メッセージのピークが含まれます。これらは、低速のネットワークでは非常にコストがかかり、過剰なネットワーク トラフィックを引き起こし、他のネットワーク クライアントに影響を与える可能性があります。

ローカル パイプとネットワーク パイプのどちらについて話しているのかを明確にすることも重要です。サーバー アプリケーションが、Microsoft® SQL Server™ 2000 のインスタンスを実行しているコンピュータ上でローカルに実行されている場合、ローカルの名前付きパイプ プロトコルはオプションです。ローカルの名前付きパイプはカーネル モードで実行され、非常に高速です。

TCP/IP ソケットの場合、データ転送はより合理化され、オーバーヘッドが少なくなります。データ転送では、ウィンドウ処理、遅延確認応答などの TCP/IP ソケットのパフォーマンス強化メカニズムを利用することもできます。これは、低速のネットワークでは非常に有益です。アプリケーションの種類によっては、このようなパフォーマンスの違いが大きくなる可能性があります。

TCP/IP ソケットはバックログ キューもサポートします。バックログ キューは、SQL Server に接続しようとしたときにパイプ ビジー エラーを引き起こす可能性がある名前付きパイプと比較して、限られた平滑化効果を提供できます。

> 一般に、低速の LAN、WAN、またはダイヤルアップ ネットワークではソケットが好まれますが、名前付きパイプは、より多くの機能、使いやすさ、および構成オプションを提供するため、ネットワーク速度が問題でない場合に適しています。

TCP/IP の詳細については、Microsoft Windows NT® のドキュメントを参照してください。

于 2012-06-04T20:55:06.500 に答える
2

名前付きパイプ クライアントのセキュリティ資格情報を偽装する必要がある場合、実際には 1 つのオプションしかありません :) また、名前付きパイプにはより適切な名前もあります (ただし、DNS SRV レコードは TCP ポートにもそれらを提供できます)。

そうでなければ、大きな違いはありません。どちらもデータをバイト ストリームとして扱うため、メッセージの境界を自分で見つける必要があります。名前付きパイプには、メッセージ境界を保持する追加オプションがありますが、メッセージ モードでパイプを作成し、読み取りモードも明示的に設定する必要があることに注意してください。

于 2012-06-04T21:16:03.300 に答える
1

私があなたの要件を正しく理解していれば、同じコンピュータ上で実行されているプロセス間で通信する必要があります。プロセスはおそらく、対話的にログオンしているユーザーの同じセキュリティ コンテキストですべて実行されます。

その場合、ソリューションにはさまざまな側面があることに言及する必要があります。1 つの問題は、アプリケーション間でデータを共有することです。もう 1 つの問題は、共通データにアクセスして変更する方法と、プロセス間の通信方法を定義するプロトコルです。たとえば、データを提供する1 つのプロセスと、別のすべてのプロセスがデータをサブスクライブすることができます。別のケース: すべてのアプリケーションで読み取りまたは変更できる共通データを使用することができます。共有データを同時に変更したり、別の変更中にデータにアクセスしたりしないようにする必要があります。もちろん、それは他の多くの異なる通信シナリオである可能性があります。

この側面では、質問に含まれていない他の2つのオプションをお勧めします。

  • 使用メモリ マップ ファイル(こちらとこちらを参照)
  • COM インターフェイスの使用

どちらの方法も、.NET とアンマネージ C++ の両方で適切に実装できます。パフォーマンスの観点からは、メモリ マップ ファイルを使用するのが最善の方法です。一部の物理ファイルに関連付けられていないビューを作成すると、プロセス間で使用できる共通メモリのみが得られます。さらに Mutex または Event を使用して、メモリが複数のアプリケーションによって同時に使用されないように制御できます。

最も単純なシナリオでは、C++ で#pragma data_segを使用して DLL の名前付きセクションにデータを配置し、 /SECTIONオプション ( など/SECTION:.MYSEC,RWS) を使用してデータを共有することもできます。すべての .NET アプリケーションとすべてのアンマネージ C++ アプリケーションで DLL を使用して、共通データにアクセスできます。このようにして、共通データに簡単にアクセスできます。

より複雑な通信シナリオが必要な場合は、C++/.NET の COM インターフェイスを使用するアプローチが最適です。.NET でのみ COM インターフェイスを使用して Primary Interop Assembly を実装し、それを .NET と C++ COM の両方で通信​​に使用する方法を段階的に説明する記事をお勧めします。

于 2012-06-05T12:09:28.393 に答える