プロセス間通信

  • [アーティクル]

Windows オペレーティング システムでは、アプリケーション間の通信とデータ共有ができるようになるメカニズムを提供しています。 これらのメカニズムによって使用できるようになるアクティビティは全体としてプロセス間通信 (IPC) と呼ばれます IPC のいくつかの形態は、複数の特殊なプロセスにおける操作の分割を容易にします。 IPCの他の形態は、ネットワーク上のコンピュータにおける操作の分割を容易にします。

通常、アプリケーションはクライアントまたはサーバーとして分類された IPC を使用できます。 クライアントとは、他のアプリケーションまたはプロセスからサービスを要求するアプリケーションまたはプロセスです。 サーバーとは、クライアント要求に応答するアプリケーションまたはプロセスです。 多くのアプリケーションは、状況に応じて、クライアントとサーバーの両方として機能します。 たとえば、ワード プロセス アプリケーションは、サーバーとして機能するスプレッドシート アプリケーションから製造コストの概要テーブルを要求するクライアントとして機能することがあります。 そしてスプレッドシート アプリケーションは、自動化された在庫管理アプリケーションから最新のインベントリ レベルを要求するクライアントとして機能することがあります。

アプリケーションで IPC を利用することを決定したら、使用できる IPC メソッドを決定する必要があります。 アプリケーションでは複数の IPC メカニズムを使用する可能性があります。 これらの質問に対する回答によって、アプリケーションが 1 つまたは複数の IPC メカニズムを使用して活用できるかが決まります。

  • アプリケーションは、ネットワーク上の他のコンピューターで実行されている他のアプリケーションと通信できることが必要ですか、それともローカル コンピューター上のアプリケーションとのみ通信するだけで十分ですか。
  • アプリケーションは、異なるオペレーティング システム (16 ビット Windows や UNIX など) で実行されている可能性がある他のコンピューターで実行されているアプリケーションと通信できることが必要ですか。
  • アプリケーションのユーザーがアプリケーションが通信する他のアプリケーションを選択する必要がありますか、それとも、アプリケーションが協力するパートナーを暗黙的に見つけることができますか。。
  • アプリケーションは、他のアプリケーションとの切り取りと貼り付けの操作を許可するなど、一般的な方法で多くの異なるアプリケーションと通信する必要がありますか。それとも、通信要件は特定の他のアプリケーションとの一連の対話のみに制限する必要がありますか。
  • パフォーマンスはアプリケーションの重要な要素ですか。 すべての IPC メカニズムには、ある程度のオーバーヘッドが含まれます。
  • アプリケーションは、GUI アプリケーションですか、それともコンソール アプリケーションですか。 一部の IPC メカニズムには GUI アプリケーションが必要です。

Windows では、次の IPC メカニズムがサポートされています。

IPC にクリップボードを使用

クリップボードは、アプリケーション間でのデータ共有の中心的な保管所として機能します。 ユーザーがアプリケーションで切り取りまたはコピーの操作を実行すると、アプリケーションは選択したデータを 1 つ以上の標準形式またはアプリケーション定義形式でクリップボードに配置します。 そして、他のアプリケーションは理解できる使用可能な形式から選択してクリップボードからデータを取得できます。 クリップボードはとても緩く結合した交換媒体であり、アプリケーションはデータ形式に同意するだけで済みます。 アプリケーションは、同じコンピューター上に配置することも、ネットワーク上の別のコンピューター上に配置することもできます。

重要なポイント: すべてのアプリケーションは、理解できるデータ形式のクリップボードをサポートする必要があります。 たとえば、テキスト エディターやワード プロセッサでは、少なくとも純粋なテキスト形式でクリップボード データを生成して受け入れることができるようにする必要があります。 詳細については、「クリップボード」を参照してください。

IPC で COM を使用

OLE を使用するアプリケーションは、複合ドキュメント (さまざまなアプリケーションのデータで構成されるドキュメント) を管理します。 OLE は、アプリケーションがデータ編集のために他のアプリケーションの呼び出しを簡単にするサービスを提供します。 たとえば、OLE を使用するワード プロセッサでは、スプレッドシートからグラフを埋め込むことができます。 ユーザーは、編集用の埋め込みグラフを選択することで、ワード プロセッサ内からスプレッドシートを自動的に開始できます。 OLE は、スプレッドシートを起動し、編集するグラフを表示します。 ユーザーがスプレッドシートを終了すると、グラフは元のワード プロセッサ ドキュメントで更新されます。 スプレッドシートはワード プロセッサの拡張機能のように見えます。

OLE の基盤となるのは、コンポーネント オブジェクト モデル (COM) です。 COM を使用するソフトウェア コンポーネントは、まだ記述されていないコンポーネントであっても、さまざまな他のコンポーネントと通信できます。 コンポーネントは、オブジェクトおよびクライアントとしてやり取りします。 分散した COM は、ネットワーク全体で動作するように COM プログラミング モデルを拡張します。

重要な点: OLE は複合ドキュメントをサポートし、アプリケーションに埋め込まれたデータみまたはリンクされたデータを含めることができます。このデータを選択すると、データを編集するために別のアプリケーションが自動的に起動します。 これにより、OLE を使用する他のアプリケーションによってアプリケーションが拡張されます。 COM オブジェクトは、インターフェイスと呼ばれる 1 つ以上の関連する一連の関数を介して、オブジェクトのデータへのアクセスを提供します。 詳細については、「COM および ActiveX オブジェクト サービス」を参照してください。

IPC でデータ コピーを使用する

データ コピーを使用すると、アプリケーションは WM_COPYDATA メッセージを使用して別のアプリケーションに情報を送信できます。 このメソッドには、送信側アプリケーションと受信側アプリケーションの連携が必要です。 受信側アプリケーションは、情報の形式を認識し、送信者を識別できることが必要です。 送信側アプリケーションは、ポインターが参照するメモリを変更できません。

重要なポイント: データ コピーを使用すると、Windows メッセージングを使用して別のアプリケーションに情報をすばやく送信できます。 詳しくは、「データのコピー」を参照してください。

IPC で DDE を使用

DDE は、アプリケーションがさまざまな形式でデータを交換できるようにするプロトコルです。 アプリケーションは、1 回限りのデータ交換や新しいデータが使用可能になったときにアプリケーションが相互に更新する継続的な交換に DDE を使用できます。

DDE が使用するデータ形式は、クリップボードが使用するものと同じです。 DDE は、クリップボード メカニズムの拡張と考えることができます。 ほとんどの場合、クリップボードは、メニューから貼り付けコマンドを選択するなど、ユーザー コマンドに対する 1 回限りの応答に使用されます。 また DDE は通常、ユーザー コマンドによって起動されますが、多くの場合、それ以上のユーザー操作なしで機能し続けます。 また、より緊密に結合した通信要件を持つアプリケーション間で特殊目的の IPC 用のカスタム DDE データ形式を定義することもできます。

DDE 交換は、同じコンピューター上で実行されているアプリケーション間、またはネットワーク上の異なるコンピューター上で実行されているアプリケーション間で行うことができます。

重要なポイント: DDE は、より新しいテクノロジーほどには効率的ではありません。 ただし、他の IPC メカニズムが適していない場合やDDE のみをサポートする既存のアプリケーションとインターフェイスで接続する必要がある場合は、DDE を引き続き使用できます。 詳細については、「動的データ交換」および「動的データ交換管理ライブラリ」を参照してください。

IPC でファイル マッピングを使用する

ファイル マッピング を使用すると、プロセスはファイルの内容をプロセスのアドレス空間内のメモリ ブロックであるかのように処理できます。 このプロセスでは、シンプルなポインター操作を使用して、ファイルの内容を調べて変更できます。 2 つ以上のプロセスが同じファイル マッピングにアクセスすると、各プロセスはファイルの内容の読み取りまたは変更に使用できる独自のアドレス空間内のメモリへのポインターを受け取ります。 プロセスでは、マルチタスク環境でのデータの破損を防ぐために、セマフォなどの同期オブジェクトを使用する必要があります。

ファイル マッピングの特殊なケースを使用して、プロセス間で名前付き共有メモリを提供できます。 ファイル マッピング オブジェクトの作成時にシステム スワップ ファイルを指定する場合、ファイル マッピング オブジェクトは共有メモリ ブロックとして扱われます。 他のプロセスは、同じファイル マッピング オブジェクトを開くことで、同じメモリ ブロックにアクセスできます。

ファイル マッピングは非常に効率的であり、また、承認されていないデータの破損を防ぐために便利なオペレーティング システムでサポートされるセキュリティ属性を提供します。 ファイル マッピングは、ローカル コンピューター上のプロセス間でのみ使用できます。ネットワーク経由では使用できません。

重要なポイント: ファイル マッピングは、同じコンピューター上の 2 つ以上のプロセスでデータを共有するために効率的な方法ですが、プロセス間の同期を提供する必要があります。 詳しくは、「ファイル マッピング」および「同期」を参照してください。

IPC でメールスロットを使用する

メールスロットは一方向の通信を提供します。 メールスロットを作成するすべてのプロセスは、メールスロット サーバーです。 メールスロット クライアントと呼ばれる他のプロセスは、メールスロット にメッセージを書き込むことでメールスロット サーバーにメッセージを送信します。 受信メッセージは常にメールスロットに追加されます。 メールスロットは、メールスロット サーバーがメッセージを読み取るまでメッセージを保存します。 プロセスは、メールスロット サーバーとメールスロット クライアントの両方にできます。そのため、複数のメールスロットを使用して双方向通信を行うことができます。

メールスロット クライアントは、ローカル コンピューター上のメールスロット、別のコンピューター上のメールスロット、または指定したネットワーク ドメイン内のすべてのコンピューターで同じ名前のすべてのメールスロットにメッセージを送信できます。 ドメインのすべてのメールスロットにブロードキャストされるメッセージは 400 バイト以下にできますが、1 つのメールスロットに送信されるメッセージは、メールスロット サーバーがメールスロットを作成するときに指定する最大メッセージ サイズによってのみ制限されます。

重要なポイント: メールスロットは、アプリケーションがショート メッセージを簡単に送受信する方法を提供します。 また、ネットワーク ドメイン内のすべてのコンピューターにメッセージをブロードキャストする機能も提供します。 詳細については、「メールスロット」を参照してください。

IPC でパイプを使用する

双方向通信用のパイプには、匿名パイプと名前付きパイプの 2 種類があります。 匿名パイプを使用すると、関連するプロセスは相互に情報を転送できます。 通常、匿名パイプは、親プロセスとデータを交換できるように、子プロセスの標準入力または出力をリダイレクトするために使用されます。 双方向でデータを交換するには (デュプレックス通信)、2 つの匿名パイプを作成する必要があります。 親プロセスは書き込みハンドルを使用して 1 つのパイプにデータを書き込みますが、子プロセスは読み取りハンドルを使用してそのパイプからデータを読み取ります。 同様に、子プロセスは他のパイプにデータを書き込み、親プロセスはそのパイプからデータを読み取ります。 匿名パイプは、ネットワーク経由で使用することも、関連のないプロセス間で使用することもできません。

名前付きパイプは、関連のないプロセス間および異なるコンピューター上のプロセス間でデータを転送するために使用します。 通常、名前付きパイプ サーバー プロセスは、既知の名前またはクライアントに通信する名前を持つ名前付きパイプを作成します。 パイプの名前を認識する名前付きパイプ クライアント プロセスは、名前付きパイプ サーバー プロセスで指定されたアクセス制限に従って、もう一方を開くことができます。 サーバーとクライアントの両方がパイプに接続すると、パイプに対して読み取り操作と書き込み操作を実行することでデータを交換できます。

重要なポイント: 匿名パイプは、標準の入力または出力を同じコンピューター上の子プロセスに効率的にリダイレクトする方法を提供します。 名前付きパイプは、2 つのプロセス間（同じコンピューター上またはネットワーク経由）でデータを転送するためのシンプルなプログラミング インターフェイスを提供します。 詳しくは、「パイプ」を参照してください。

IPC で RPC を使用

RPC を使用すると、アプリケーションは関数をリモートで呼び出すことができます。 つまり、RPC によって IPC は関数の呼び出しのように簡単になります。 RPC は、1 つのコンピューター上のプロセスまたはネットワーク上の別のコンピューター上のプロセス間で動作します。

Windows によって提供される RPC は、オープン ソフトウェア財団 (OSF) の分散コンピューティング環境 (DCE) に準拠しています。 つまり、RPC を使用するアプリケーションは、DCE をサポートする他のオペレーティング システムを実行しているアプリケーションと通信できます。 RPC は、異なるハードウェア アーキテクチャのアカウントと異なる環境間のバイトオーダーのアカウントへのデータ変換をサポートしています。

RPC クライアントとサーバーは密に結合していますが、引き続き高いパフォーマンスを維持します。 このシステムでは、RPC を広範に使用して、オペレーティング システムのさまざまな部分間のクライアント / サーバー間の関係を容易にします。

重要なポイント: RPC は関数レベルのインターフェイスであり、自動データ変換と他のオペレーティング システムとの通信をサポートしています。 RPC を使用すると、高いパフォーマンスの密に結合した分散アプリケーションを作成できます。 詳しくは、「Microsoft RPC コンポーネント」を参照してください。

IPC で Windows ソケットを使用

Windows ソケットは、プロトコルに依存しないインターフェイスです。 基になるプロトコルの通信機能を活用します。 Windows ソケット 2 では、標準のファイル I/O 関数を持つファイル ハンドルとして、必要に応じてソケット ハンドルを使用できます。

Windows ソケットは、バークレイ ソフトウェア ディストリビューション (BSD) によって最初に普及したソケットに基づいています。 Windows ソケットを使用するアプリケーションは、他の種類のシステム上の他のソケット実装と通信できます。 ただし、すべてのトランスポート サービス プロバイダーが使用可能なすべてのオプションをサポートしているわけではありません。

重要な点: Windows ソケットは、現在およびこれからのネットワーク機能をサポートできるプロトコルに依存しないインターフェイスです。 詳しくは、「Windows ソケット 2」を参照してください。

Windows の unix ソケット (AF_UNIX) 関数

Windows Insider Build 17063 以降では、Win32 プロセス間で通信するために Windows 上の unix ソケット (AF_UNIX) アドレス ファミリを使用できます。 Unix ソケットを使用すると、同じマシン上のプロセス間でのプロセス間通信 (IPC) ができるようになります。 詳しくは、「Windows で AF_UNIX が可能に」を参照してください。

リモート メールスロット プロトコルの廃止

Windows 11 Insider Preview Build 25314 および Windows Server Preview Build 25314 より、デフォルトでリモート メールスロット プロトコルの無効化を開始しました。 これは、Windows からの廃止と最終的な削除の前準備です。 詳細については、ブログ記事「Windows Insider の一部として、リモート メールスロットの終焉開始」をご覧ください。