プロセス間通信
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 を引き続き使用できます。 詳細については、「動的データ交換 と動的 Data Exchange 管理ライブラリの を する」を参照してください。
IPC のファイル マッピングの使用
ファイル マッピング を使用すると、プロセスはファイルの内容をプロセスのアドレス空間内のメモリ ブロックであるかのように処理できます。 このプロセスでは、単純なポインター操作を使用して、ファイルの内容を調べて変更できます。 2 つ以上のプロセスが同じファイル マッピングにアクセスすると、各プロセスは、ファイルの内容の読み取りまたは変更に使用できる独自のアドレス空間内のメモリへのポインターを受け取ります。 プロセスでは、マルチタスク環境でのデータの破損を防ぐために、セマフォなどの同期オブジェクトを使用する必要があります。
ファイル マッピングの特殊なケースを使用して、プロセス間で名前付き共有メモリ を提供できます。 ファイル マッピング オブジェクトの作成時にシステム スワップ ファイルを指定した場合、ファイル マッピング オブジェクトは共有メモリ ブロックとして扱われます。 他のプロセスは、同じファイル マッピング オブジェクトを開くことで、同じメモリ ブロックにアクセスできます。
ファイル マッピングは非常に効率的であり、承認されていないデータの破損を防ぐのに役立つオペレーティング システムでサポートされるセキュリティ属性も提供します。 ファイル マッピングは、ローカル コンピューター上のプロセス間でのみ使用できます。ネットワーク経由では使用できません。
重要な点: ファイル マッピングは、同じコンピューター上の複数のプロセスでデータを共有するための効率的な方法ですが、プロセス間の同期を提供する必要があります。 詳細については、「ファイル マッピングの と 同期」を参照してください。
IPC 用 Mailslot の使用
Mailslots は一方向の通信を提供します。 mailslot を作成するプロセスは、mailslot サーバーです。 mailslot クライアント 呼ばれる他のプロセスは、mailslot にメッセージを書き込むことで、mailslot サーバーにメッセージを送信します。 受信メッセージは常に mailslot に追加されます。 mailslot は、mailslot サーバーがメッセージを読み取るまでメッセージを保存します。 プロセスは mailslot サーバーと mailslot クライアントの両方にできます。そのため、複数の mailslot を使用して双方向通信を行うことができます。
mailslot クライアントは、ローカル コンピューター上の mailslot、別のコンピューター上の mailslot、または指定したネットワーク ドメイン内のすべてのコンピューターで同じ名前を持つすべての mailslot にメッセージを送信できます。 ドメイン上のすべての mailslot にブロードキャストされるメッセージは 400 バイトを超えることはできませんが、1 つの mailslot に送信されるメッセージは、mailslot サーバーが mailslot を作成したときに指定された最大メッセージ サイズによってのみ制限されます。
重要なポイント: Mailslots は、アプリケーションが短いメッセージを簡単に送受信する方法を提供します。 また、ネットワーク ドメイン内のすべてのコンピューターにメッセージをブロードキャストする機能も提供します。 詳細については、「Mailslots」を参照してください。
IPC 用パイプの使用
双方向通信用のパイプには、匿名パイプと名前付きパイプの 2 種類があります。 匿名パイプ、関連するプロセスが相互に情報を転送できるようにします。 通常、匿名パイプは、親プロセスとデータを交換できるように、子プロセスの標準入力または出力をリダイレクトするために使用されます。 双方向 (双方向の操作) でデータを交換するには、2 つの匿名パイプを作成する必要があります。 親プロセスは書き込みハンドルを使用して 1 つのパイプにデータを書き込みますが、子プロセスは読み取りハンドルを使用してそのパイプからデータを読み取ります。 同様に、子プロセスは他のパイプにデータを書き込み、親プロセスはデータをそのパイプから読み取ります。 匿名パイプは、ネットワーク経由で使用することも、関連のないプロセス間で使用することもできません。
名前付きパイプ は、関連のないプロセス間および異なるコンピューター上のプロセス間でデータを転送するために使用されます。 通常、名前付きパイプ サーバー プロセスは、既知の名前またはクライアントに通信する名前を持つ名前付きパイプを作成します。 パイプの名前を認識する名前付きパイプ クライアント プロセスは、名前付きパイプ サーバー プロセスで指定されたアクセス制限に従って、もう一方の端を開くことができます。 サーバーとクライアントの両方がパイプに接続した後、パイプに対して読み取り操作と書き込み操作を実行することで、データを交換できます。
重要な点: 匿名パイプは、標準の入力または出力を同じコンピューター上の子プロセスに効率的にリダイレクトする方法を提供します。 名前付きパイプは、2 つのプロセス間でデータを転送するための単純なプログラミング インターフェイスを提供します。同じコンピューター上に存在する場合でも、ネットワーク経由でも同様です。 詳細については、「パイプ」を参照してください。
RPC for IPC の使用
RPC を使用すると、アプリケーションは関数をリモートで呼び出します。 したがって、RPC を使用すると、関数を呼び出すのと同じくらい簡単に IPC が作成されます。 RPC は、1 台のコンピューター上またはネットワーク上の別のコンピューター上のプロセス間で動作します。
Windows によって提供される RPC は、Open Software Foundation (OSF) Distributed Computing Environment (DCE) に準拠しています。 つまり、RPC を使用するアプリケーションは、DCE をサポートする他のオペレーティング システムと実行されているアプリケーションと通信できます。 RPC では、異なるハードウェア アーキテクチャと、異なる環境間のバイトオーダーを考慮したデータ変換が自動的にサポートされます。
RPC クライアントとサーバーは密接に結合されていますが、高いパフォーマンスを維持します。 このシステムでは、RPC を広範に使用して、オペレーティング システムのさまざまな部分間のクライアントとサーバーの関係を容易にします。
重要なポイント: RPC は、自動データ変換と他のオペレーティング システムとの通信をサポートする関数レベルのインターフェイスです。 RPC を使用すると、高パフォーマンスで密結合された分散アプリケーションを作成できます。 詳細については、「Microsoft RPC Components」を参照してください。
IPC 用 Windows ソケットの使用
Windows ソケットは、プロトコルに依存しないインターフェイスです。 基になるプロトコルの通信機能を利用します。 Windows ソケット 2 では、標準のファイル I/O 関数を持つファイル ハンドルとして、必要に応じてソケット ハンドルを使用できます。
Windows ソケットは、バークレイ ソフトウェア ディストリビューション (BSD) によって最初に普及したソケットに基づいています。 Windows ソケットを使用するアプリケーションは、他の種類のシステム上の他のソケット実装と通信できます。 ただし、すべてのトランスポート サービス プロバイダーが使用可能なすべてのオプションをサポートしているわけではありません。
重要なポイント: Windows ソケットは、現在および新しいネットワーク機能をサポートできるプロトコルに依存しないインターフェイスです。 詳細については、「Windows ソケット 2」を参照してください。
Windows の unix ソケット (AF_UNIX) 関数
Windows Insider Build 17063 以降では、Windows 上の unix ソケット (AF_UNIX) アドレス ファミリを使用して、Win32 プロセス間で通信できます。 Unix ソケットを使用すると、同じコンピューター上のプロセス間のプロセス間通信 (IPC) が可能になります。 詳細については、Windows に関するブログ記事AF_UNIX 参照してください。
リモート Mailslot プロトコルの廃止
Windows 11 Insider Preview Build 25314 および Windows Server Preview Build 25314 の時点で、既定でリモート Mailslot プロトコルの無効化を開始しました。 これは、Windows からの非推奨化と最終的な削除の前兆です。 詳細については、Windows Insider の一部として、リモート メールスロットの終わりの始まりブログ記事を参照してください。