3

ターミナル サーバー セッションでは、必要なリソースが仮想化されていないため、一部の標準 IPC テクノロジはシングル ユーザー環境のように機能しない場合があります。

たとえば、TCP/IP ポートは仮想化されていないため、異なるセッション内のアプリケーションが同じポートでリッスンしようとすると、ポートの競合が発生します。

同じユーザー セッションで実行されているアプリケーションが対話する必要があるターミナル サーバー環境で機能する IPC テクノロジはどれですか?

  • メッセージ (WM_COPYDATA)?
  • 名前付きパイプ?
  • DDE?
  • メモリマップファイル?
4

2 に答える 2

4

メッセージは正常に機能します。DDEもメッセージに基づいているため、そうなります。名前付きパイプはシステムごとであり、セッションごとではないため、そうではありません。COMまたはOLEを検討することもできます。

于 2009-05-19T11:27:56.880 に答える
2

すべての IPC は TS 環境で使用できます。必要な最終結果を得るには、オブジェクトの命名を賢くする必要があります。ソケットの使用はよりトリッキーですが、実行できます。以下にいくつかの方法をリストしました。

名前を付けることができる IPC オブジェクト (Pipe、Event、Mutex、Memory Mapped File など) の場合、セッション ID をオブジェクトの名前に組み込むことで、必要な仮想化を実現できます。IPC オブジェクトをさらにロックダウンするには、オブジェクトのセキュリティ属性を使用して、他のユーザーが IPC オブジェクトにアクセスできないようにします。これは、バグの結果として偶発的に発生したり、ターミナル サーバー上の別のユーザーから悪意を持って発生したりする可能性があります。

同様に、ログオンしているユーザーの認証 ID を IPC オブジェクトの名前に使用します。C++ では、GetTokenInformation の MSDN を参照してください。TokenInformationClass にTokenStatisticsを使用します。同等の .NET メソッドがあると確信しています。再び IPC オブジェクトを保護します。

TS でソケットを使用する必要がある場合 (個人的には、TS 上のアプリケーション間で通信する別の方法を選択します)、ポート番号を使用します。ベース ポート番号を選択し、セッション番号を追加して、セッションに使用されるポートを取得します。正しいアプリケーションが通信していることを確認するには、データを転送する前に認証方法やハンドシェイクを使用します。理論的には、セッションには最大 65535 の番号を付けることができるため、たとえば 2000 のベース ポート番号を使用し、アプリケーションがセッション 65500 で実行されているセッションを使用すると、動けなくなる可能性があります。本当にソケットを使用したい場合は、ブローカー サービスが役立つでしょう。

于 2009-06-13T00:01:49.067 に答える