IPC（プロセス間通信） | SOCKET-MANAGER Framework For PHP

SOCKET-MANAGER Framework は、TCP / UDP / WebSocket / 独自プロトコルといった異なる通信方式を同一プロセス内で共存させる という特徴的なアーキテクチャを持っています。

この構造は単なる「複数プロトコル対応」ではなく、IPC（プロセス間通信）を特別扱いせずに自然に実現できるという大きな利点につながります。

本ページでは、SOCKET-MANAGER Framework の基盤思想の一部であるIPC（プロセス間通信）とモジュール構造の関係について解説します。
フレームワーク全体の構成や主要機能については、▶フレームワークのご紹介をご覧ください。

フレームワーク本体は以下の 3 モジュールで構成されています。

SocketManager（プロトコル部＋コマンド部）
RuntimeManager（ランタイムUNITのみ）
SimpleSocket（TCP/UDP の軽量通信）

これらはすべて、UNIT（処理単位）とキュー（状態遷移） による共通のステートマシン上で動作します。

そのため、異なるモジュールを同一プロセス内で自由に組み合わせることができる という柔軟性が生まれます。
この「モジュールの共存性」こそが IPC の基盤になっています。

一般的なフレームワークでは、IPC は以下のように「別世界」として扱われがちです。

専用の IPC ライブラリ
専用のメッセージング層
専用のプロトコル
専用のハンドラ

しかし SOCKET-MANAGER Framework では、IPC も単なる「通信モジュールの一つ」 として扱います。

つまり、IPC 専用の仕組みを作らなくても、通常の通信モジュールを複数プロセスに配置するだけで IPC が成立する という構造になっています。

IPC（プロセス間通信）は CUEI アーキテクチャにおける I（IPC） の役割を担う要素です。

SOCKET-MANAGER Framework では、プロトコル部とコマンド部が CycleDrivenManager により統一インターフェースで扱われるため、 IPC も通常の通信モジュールと同じ抽象モデルで実現できます。

また、イベント駆動アーキテクチャ（E）の上で動作するため、 サーバー本体のモジュールと IPC モジュールを同じイベントループ内で共存させる ことが可能です。

C（Communication）：プロトコル部が抽象化され、IPC も通常通信と同じモデルで扱える
U（Union）：共有基盤（UNITパラメータ）がプロセス間でも統一的に利用される
E（Event）：複数モジュールを同一イベントループで安全に共存させる
I（IPC）：追加の仕組みなしでプロセス間通信を構成できる

このように、IPC は CUEI の I を担いながら、 C・U・E の要素と統合されることで高い柔軟性と拡張性を実現しています。

イベントループとステートマシンによる E（Event）の詳細については、 ▶イベント駆動アーキテクチャを参照してください。

フレームワーク本体は、ストラテジーパターンを基盤とした依存性注入（DI） を採用しています。

これにより、以下のような柔軟な構成が可能になります。

プロトコル部・コマンド部をクラス単位で自由に差し替え
同一インターフェースで複数モジュールを共存
IPC 用モジュールを必要なプロセスにだけ注入

この DI 構造は、IPC を「後付けの特殊機能」ではなく、モジュール構成の一部として自然に扱える という大きな利点を生みます。

なお、依存性注入（DI）やインターフェース設計の思想については、PHP-FIG が策定する PSR-11（Container Interface）も参考になります：
https://www.php-fig.org/psr/psr-11/

モジュールをプロセス単位で自由に構成できるため、SOCKET-MANAGER Framework はマイクロサービスアーキテクチャと非常に相性が良い という特徴があります。

サービスごとに異なるプロトコルを採用可能
IPC モジュールを介してサービス間通信を統一
プロセス単位でスケールアウトが容易
Launcher による複数サーバーの一元管理

これらはすべて、UNIT / キュー / モジュール という統一抽象モデルがあるからこそ成立する設計です。

また、イベント駆動型のサービス連携という観点では、PSR-14（Event Dispatcher）も関連する設計思想として参考になります：
https://www.php-fig.org/psr/psr-14/

SOCKET-MANAGER Launcher は、フレームワーク本体と同じく UNIT / キューを基盤としたステートマシン構造 を採用しています。

そのため、サービス群を Launcher から統一的に管理でき、システム全体をステータス管理対象として扱える という強みがあります。

各サービスの起動・停止・再起動を一元管理
サービスごとのステータスを統一フォーマットで監視
IPC を利用したサービス間連携を俯瞰的に把握
サービス群を「統合ステートマシン」として運用可能

なお、SOCKET-MANAGER Launcher は、アーキテクチャページで説明しているCUEI/O アーキテクチャにおける “/O（Operation）” に該当する要素でもあります。
CUEI が示す「通信・共有基盤・非同期処理・サーバー間通信」を開発フェーズで統合する思想に対し、Launcher はそれらを 運用フェーズで統合的に管理する役割 を担います。

そのため、IPC を含む複数サービスの起動・停止・監視・再起動といった運用レベルの制御を、CUEI の抽象モデルと同じ思想で扱える点が大きな特徴です。

CUEI/O 全体の構造や、CUEI の各要素がどのように統合されるかについては、 ▶アーキテクチャのページで詳しく解説しています。

SimpleSocket は以下の 2 つの使い方ができます。

1. 独立モジュールとして動作

Launcher のカスタムモニタリング機能がこの例です。

2. 他モジュールの UNIT 内で動作

$ctx->simple_socket（プロパティ）により、SocketManager や RuntimeManager の UNIT 内から SimpleSocket の送受信機能を直接利用できます。

これにより、プロトコル部の処理中に IPC を行う といった柔軟な構成も可能になります。

フレームワークのデモでは、Minecraft 統合版（Bedrock Edition）との連携を含む以下の IPC 構成を実現しています。

TCP 版 IPC
UDP 版 IPC
Web ブラウザ同士の宛先指定メッセージ送受信
Web ブラウザ ⇔ Minecraft 統合版間の宛先指定メッセージ送受信

Minecraft 側では、ゲーム内の 「/w（whisper）」 機能を利用してプレイヤーへ通知を行っています。

Minecraft 統合版の公式ドキュメントはこちら：
Minecraft 統合版クリエイタードキュメント

これらはすべて、IPC 専用の仕組みではなく、通常の通信モジュールを複数プロセスに配置しただけ で成立しています。

IPC をモジュールとしてカプセル化できるため、ビジネスロジック側は以下のメリットを得ます。

IPC の実装がアプリロジックに混ざらない
モジュール単位で差し替え可能
テストや保守が容易
プロトコル変更にも強い

これは UNIT / キュー / モジュール という統一された抽象モデルがあるからこそ実現できる設計です。

REST-API 環境では、SocketManager の特定構成をプリセット化しているため、IPC の実装方法は REST-API 側の ▶Parallelクラス実装ページで説明しています。

本ページでは、フレームワーク本体としての IPC の思想と構造 を扱います。

IPC は SOCKET-MANAGER Framework のアーキテクチャから自然に導かれる仕組みであり、特別な実装を必要としない点が大きな特徴です。

モジュールを複数プロセスに配置するだけで IPC が成立し、SimpleSocket による横断的な通信も可能です。

より高度な構成（マルチサーバー構成や Launcher 連携）については、ADVANCED カテゴリの各ページをご参照ください。

【IPC（プロセス間通信）】

はじめに

モジュール構造と IPC の関係

IPC を“特別扱いしない”という設計思想

CUEI各要素との相関関係

依存性注入と戦略パターン

マイクロサービスとの親和性

Launcher 統合管理

SimpleSocket の横断利用

1. 独立モジュールとして動作

2. 他モジュールの UNIT 内で動作

IPC の実例

ビジネスロジックが汚れない理由

REST-API との関係

おわりに