【IPC（プロセス間通信 / Inter-Process Communication）】

IPC の位置づけ（CUEI の I が求めるもの）

CUEI アーキテクチャにおける I（IPC） は、 「複数プロセス間での通信を、通常の通信方式と同じ抽象モデルで扱えること」 を指針としています。

CUEI の I が求めるのは、専用ミドルウェアや特別なプロトコルではなく、 既存の通信抽象化（C）とイベント駆動（E）をそのままプロセス間に拡張できる構造 です。

この指針は技法を縛るものではありませんが、以下の要件を満たすことが求められます。

• IPC を通常の通信モジュールと同じ抽象モデルで扱えること
• プロセス間通信のために特別な仕組みを追加しなくてよいこと
• イベント駆動アーキテクチャ（E）の上で自然に動作すること
• 共有基盤（U）のコンテキスト設計と矛盾しないこと

SOCKET-MANAGER Framework における実装方針

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

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

本フレームワークでは、この CUEI の指針を UNIT / Queue / Module の統一モデルをそのままプロセス間に拡張する という形で具現化しています。

本ページでは、CUEI の I（IPC）に相当するこのプロセス間通信が SOCKET-MANAGER Framework の中でどのように設計されているかを解説します。

フレームワーク全体の構成や主要機能については、 ▶フレームワークのご紹介 をご覧ください。

SOCKET-MANAGER Framework は、 イベント駆動アーキテクチャで説明しているように UNIT（処理単位）／Queue（状態遷移）／Module（機能単位） の三層構造で成り立っています。

この三層構造の上で、フレームワーク本体には次の 「モジュール管理クラス」 が存在します。

• SocketManager（プロトコル部・コマンド部を統合管理）
• RuntimeManager（ランタイム UNIT 群を管理）
• SimpleSocketGenerator（SimpleSocket 系列を生成）

これらは「Module」そのものではなく、 複数の UNIT / Queue を束ねて管理する上位レイヤーのクラス です。

UNIT / Queue を利用する管理クラスと、利用しない管理クラス

SocketManager
・プロトコル部：プロトコル処理を担う Queue の集合
・コマンド部：サーバーコンテンツ処理を担う Queue の集合
→ UNIT / Queue を前提としたステートマシン構造

RuntimeManager
・ランタイム UNIT：常駐型アプリの処理を担う Queue の集合
→ UNIT / Queue を前提としたステートマシン構造

SimpleSocketGenerator
・SimpleSocketTcpServer / SimpleSocketTcpClient / SimpleSocketUdp を生成
→ UNIT / Queue を必要としない軽量通信モジュールを生成

このように、 SocketManager と RuntimeManager はステートマシン上で動作する UNIT / Queue の集合体 であり、 SimpleSocket 系列はステートマシンに依存しない軽量通信モジュール です。

これらの管理クラスが生成するモジュールは 同一プロセス内で自由に組み合わせて動作 できるため、
IPC（プロセス間通信）も「特別な仕組み」ではなく、 必要なモジュールを複数プロセスに配置するだけで自然に成立する通信形態 として扱えます。

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

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

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

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

この設計により、外部ミドルウェアに依存せず INET ベースの軽量な通信経路をそのまま利用できるため、プロセス間で高速かつ低レイテンシなデータ転送が可能 になります。

専用ブローカーやメッセージング層を経由しないため遅延要因が少なく、 リアルタイム性が求められる用途にも適した IPC 基盤 を実現しています。

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

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

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

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

IPC が INET ベースで動作するため、 CUEI の I はリアルタイム性の高い通信基盤として機能 します。

イベントループとステートマシンによる 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 / Queue / Module という統一抽象モデルがあるからこそ成立する設計です。

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

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

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

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

Launcher は CUEI/O アーキテクチャにおける “/O（Operation）” に該当し、 開発フェーズで統合された CUEI の要素を 運用フェーズで統合的に管理する役割 を担います。

CUEI/O 全体の構造については、 ▶アーキテクチャ を参照してください。

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

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

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

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

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

SimpleSocket は UNIT / Queue を必要としないためオーバーヘッドが少なく、 IPC の高速化や軽量な補助通信に適したモジュール として利用できます。

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

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

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

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

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

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

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

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

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

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

IPC は SOCKET-MANAGER Framework のアーキテクチャから自然に導かれる仕組みであり、 特別なミドルウェアや専用プロトコルを必要としない点が大きな特徴です。

モジュールを複数プロセスに配置するだけで IPC が成立し、 SimpleSocket を利用した軽量かつ高速な通信も同一イベントループ内で実現できます。

さらに、IPC は「通信モジュールの一つ」として扱えるため、 ハイパフォーマンスモード（FFI + 独自 IO ドライバ）と組み合わせることで、 プロセス間通信でもネイティブ IO による高速性をそのまま享受できます。
これは、外部ブローカーを経由しない INET ベース IPC の強みと相性が良く、 大量接続・高頻度メッセージングでも低レイテンシを維持できる構造です。

ハイパフォーマンスモードの詳細は ▶ハイパフォーマンスモード をご覧ください。

また、CUEI/O アーキテクチャや Launcher による統合管理と組み合わせることで、 マルチサーバー構成・サービス連携・リアルタイム処理など、 より高度なシステム構築にも柔軟に対応できます。

追加の構成例や応用的な設計については、 ADVANCED カテゴリの各ページをご参照ください。