【共有基盤（Union）】

共有基盤（Union）は、CUEI アーキテクチャにおける 「処理全体を束ねる共通の土台」 を表す概念です。
SOCKET-MANAGER Framework では、この共有基盤が コンテキスト管理 として具現化されており、各セッションの状態や通信データを安全かつ効率的に扱うための中心的な役割を担います。

Queue や UNIT が「いつ・どの順番で処理するか」を管理するのに対して、共有基盤は 「何を共有し、どのように受け渡すか」 を管理します。
つまり、通信抽象化が「プロトコルやビジネスロジックの振る舞い」を構造化するのに対し、共有基盤はそれらの振る舞いを支える コンテキストの構造 を提供します。

CUEI は技法を縛るものではなく、Union は「どのような実装方式であっても、処理全体を支える共通基盤を設計できること」を指針としています。

本ページでは、CUEI の U（Union）に相当するこの共有基盤が、SOCKET-MANAGER Framework の中でどのように設計されているかを解説します。

本フレームワークでは、共有基盤の中心となる要素として コンテキスト（Context） を定義しています。
コンテキストとは一般的に「処理の前提となる状態や環境」を指し（参考：MDN Web Docs）、本フレームワークではこれを UNIT 間で共有するための基盤として活用します。

コンテキストは、モジュール管理クラスごとに 1 つだけ割り当てられ、各 UNIT の引数として渡されることで、UNIT 間で共有される共通の基盤となります。

特徴を整理すると次の通りです。

• モジュール管理クラス 1 つにつき、コンテキスト 1 つ
• コンテキストは各 UNIT の引数として渡され、UNIT 間で共有される
• コンテキストの中身は、処理対象のセッションに応じて動的に入れ替わる

これにより、開発者は「どの UNIT から見ても同じコンテキストインターフェース」を扱いながら、実際には セッションごとに中身が切り替わる という柔軟な構造を利用できます。
この基盤は、共有されるコンテキストでありながら、実際には「現在処理中のセッション専用の状態」を扱える構造になっています。

コンテキストの中でも、特にセッション固有の情報は ディスクリプタ（Descriptor） として分離されています。
ディスクリプタとは OS が管理する「リソース識別子」の一種であり（参考：Linux man-pages）、本フレームワークではこれを「クライアント接続子」として扱います。

ディスクリプタには、主に次のような情報が含まれます。

• ソケット情報（接続 ID、接続状態など）
• 受信データの FIFO バッファ
• 送信データの FIFO バッファ
• ユーザー定義エリア（任意のプロパティを保持する領域）

UNIT が実行されるたびに、「現在処理中のセッションのディスクリプタ」だけがコンテキストに差し替わる ため、開発者は常に「そのセッション専用のコンテキスト」を扱うことができます。
これにより、複数セッションが同時に存在していても、各 UNIT の実装は「自分が今扱っているセッション」にだけ集中できます。

ゼロコピー（Zero-copy）とは、データを複製せずに参照だけを共有する仕組みを指します（参考：Zero-copy - Wikipedia）。
共有基盤としてのコンテキストは、単なる状態保持のためのオブジェクトではなく、ゼロコピーでデータを受け渡すための領域 として設計されています。

具体的には、次のような特徴があります。

• 各 UNIT の引数として同じコンテキストインスタンスが渡される
• プロトコルUNITとコマンドUNITの間で、送受信データをコピーせずに共有できる
• 大量接続時でも、不要なメモリコピーを抑えた高効率な処理が可能

例えば、プロトコルUNITで受信したデータをスタックに積み、コマンドUNIT側でそのデータを取り出して処理する場合でも、コンテキストを介して同じバッファを参照するだけで済みます。
このゼロコピー構造は、SOCKET-MANAGER Framework の高パフォーマンスとスケーラビリティを支える重要な要素です。

共有基盤は、フレームワークが提供する標準コンテキストだけでなく、開発者が独自のコンテキストクラスを定義できるように設計されています。
これにより、モジュール管理クラス単位で必要なグローバルエリアや、プロジェクト固有の状態管理を柔軟に組み込むことができます。

オリジナルコンテキストは、専用のスキャフォールディングコマンドによって生成します。

• SocketManager 用： craft:parameter
• RuntimeManager 用： runtime:parameter

これらのコマンドで生成されるクラスは、フレームワークが提供する基底コンテキストクラスを継承しており、
例えば次のような用途に利用できます。

• チャットサーバーにおけるユーザーリストや部屋情報の管理
• IPC 利用時のデータ交換媒体としての共有バッファ
• サーバー間通信で利用するメタ情報の保持
• プロトコル独自の状態や統計情報の蓄積

このように、共有基盤は「フレームワーク内部の仕組み」であると同時に、開発者が自分の設計思想を反映させるための拡張ポイントとしても機能します。

共有基盤としてのコンテキストは、SocketManager と RuntimeManager で役割が少し異なります。

• SocketManager： セッション単位のディスクリプタを持ち、各接続ごとの状態をコンテキスト経由で扱う
• RuntimeManager： ディスクリプタを持たず、プロセス全体で共有されるコンテキストとして機能する

SocketManager では「セッション固有のコンテキスト」が中心となるのに対し、RuntimeManager では「プロセス全体の共有状態」を扱う用途に向いています。
例えば、バックグラウンド処理やバッチ処理のように、接続という概念を持たない処理では、RuntimeManager のコンテキストを使って 軽量な共有基盤 を構築できます。

IPC（プロセス間通信）は、SocketManager と RuntimeManager を連携させる際に重要な役割を持ちます。
共有基盤としてのコンテキストは、この IPC 連携において「どの情報をどのプロセス間で共有するか」を決める基準となります。
CUEI の U（Union）は、単一プロセス内だけで完結するものではなく、IPC（プロセス間通信）を通じてプロセス間の連携にも拡張可能です。
SOCKET-MANAGER Framework では、共有基盤としてのコンテキストを、IPC のデータ交換媒体としても利用できます。

例えば、次のような構成が考えられます。

• フロント側 SocketManager が受信したデータを、IPC を通じてバックエンドの RuntimeManager に引き渡す
• バックエンド側で処理した結果を、再び IPC 経由でフロント側に戻し、クライアントへ送信する

このとき、共有基盤としてのコンテキストは、
「どの情報をどのプロセス間で共有するか」 を設計するための基準となります。
通信抽象化が「プロトコルやコマンドの振る舞い」を統一するのに対し、共有基盤は「プロセスやレイヤーをまたいだデータの持ち方」を統一する役割を担います。

共有基盤（Union）は、CUEI アーキテクチャにおける U を、SOCKET-MANAGER Framework の中で具体的な形にしたものです。

• モジュール管理クラスごとに 1 つのコンテキストが割り当てられる
• セッション固有の情報はディスクリプタとして分離され、処理対象セッションに応じて差し替えられる
• コンテキストは UNIT 間のゼロコピーなデータ受け渡しの基盤となる
• オリジナルコンテキストを定義することで、プロジェクト固有の共有領域を柔軟に設計できる
• SocketManager と RuntimeManager で、コンテキストの役割を使い分けられる
• IPC を通じて、プロセス間の共有基盤としても機能を拡張できる

このように、共有基盤は単なる「便利なヘルパー」ではなく、
CUEI の設計思想に基づいて、通信抽象化・イベント駆動・IPC・マルチサーバー構成などを横断的に支える中核コンポーネントとして位置づけられています。
具体的なメソッドや実装例については、UNIT パラメータクラスや関連ドキュメントを参照しながら、自身のプロジェクトに最適な共有基盤の形を設計してみてください。