MANUAL NAVIGATION: Preceding Page - Next Page - Table of Contents - Reference

This page concerns advanced high-level situations wherein three or more applications are engaging in IPC; that is at least one application talks to at least two other applications. So far we've limited discussion to a server application Ap talking to a client application Bp (Ap-Bp split) while merely mentioning that, e.g., Ap could also be talking to client Cp (Ap-Cp split). It can get fancier: Ap could be server in Ap-Bp split while being the client in a Cp-Ap split. From there, it can grow as complex as you need it to be.

(Or go back to preceding page: Safety and Permissions. Sessions: Setting Up an IPC Context, particularly the parts about the ipc::session::App hierarchy, would also be a natural immediate pre-requisite for the current page.)

The rules are a direct extension of what we've covered:

One IPC universe description. All Apps, Client_apps, and Server_apps of all the applications form one description, built by the same code in every application, as described in Sessions: Setting Up an IPC Context. MASTER_APPS_AS_CLI lists every application that acts as a session-client in any split.
Roles are per split. An application that is a session-server in one split and a session-client in another has both a Server_app and a Client_app (each containing the same App).
A session-server serves all its splits with one Session_server. If Ap is the server in both Ap-Bp and Ap-Cp, its ipc::session::Server_app::m_allowed_client_apps lists both Bp and Cp. A single Session_server accepts sessions from either; ipc::session::Server_session::client_app() tells you which one connected (see Sessions: Teardown; Organizing Your Code for one way to dispatch on it).
A session-client opens one Client_session per split. If Ap is also the client in a Cp-Ap split, it constructs a Client_session, as in Sessions: Setting Up an IPC Context, giving it Ap's Client_app and Cp's Server_app. (A process may hold a Session_server and Client_sessions at the same time.)
Sessions are independent. Each session, in each split, has its own channels and per-session SHM arena. Nothing is shared across splits except app-scope data, which belongs to a particular session-server and client application; see Sessions: Teardown; Organizing Your Code.

Everything else in this Manual applies to each split as-is.

The next page is: Structured Message Transport (Structured Channels).

MANUAL NAVIGATION: Preceding Page - Next Page - Table of Contents - Reference