UC1 — Submit a workload to the grid
A Symphony client submits SOA work and a Windows compute host runs it — over the same fixed port matrix IBM has documented since 7.3.2, with nothing between client and service instance repackaged or containerized.
The connection flow
Every session follows one documented path: the client never talks to a compute host directly. It asks the master for a session, the master hands it off to a Session Director, and the Session Director hands the actual dispatch work to a Session Scheduler Manager (SSM) — the component that talks to the Windows side.
| Hop | From | To | Port | Notes |
|---|---|---|---|---|
1 |
Client |
vemkd |
7870 TCP |
First contact for every session — clients connect here to be told which Session Director to use. |
2 |
Client |
Session Director (SD) |
7874/7875 TCP |
|
3 |
Client |
SSM |
31000-31019 TCP (pinned) |
|
4 |
SSM |
SIM (compute host) |
31020-31039 TCP (pinned) |
|
5 |
SIM |
Service instance |
local |
SIM starts and manages the service instance process(es) that actually execute the task. |
IBM does not document which side initiates every one of these channels, so the grid’s
firewall rules allow bidirectional establishment on the base-port block and both SSM
sub-ranges rather than assuming client-to-server direction only
(reference-architecture.md §7).
Compute-side lifecycle: LIM starts PEM, PEM reports to LIM
The sequence above is the per-task path. Underneath it, every compute host runs a
second, always-on lifecycle that has nothing to do with any single task — it is what
keeps the host ok in egosh at all:
-
LIM is the one Windows service the Symphony MSIs register (named literally
LIM, notEGO*— a real trap during build, see the compute pool page). On start, LIM spawns PEM as a local child process — not a separate Service Control Manager entry. -
PEM reports resource utilization back to the master’s LIM continuously, over a long-lived, idle-tolerant TCP channel (
EGO_ENABLE_CHAN_KEEPALIVE=y,EGO_CHAN_KEEPALIVE_TIME >= 180s) — separate from, and prerequisite to, any SSM/SIM task traffic. -
The master’s LIM also dials back to a newly-registered compute host on 7869-7875 — an inbound rule on the compute side is required even though the host initiated registration outbound. Windows blocks unsolicited inbound by default on every profile, which made this the single costliest firewall gap found in this build (
symphony-management.md,windows-compute-pool.md).
This LIM<→PEM heartbeat, not the SSM/SIM path, is what egosh resource list is
actually reporting on: a host can be fully reachable for this heartbeat and still
never receive a task if the SSM/SIM path above is misconfigured, and vice versa.
Common data: sent once per session
Task input flows client → SSM → SIM → service instance on every task by default.
Common data — payload shared across every task in a session — is the one thing
that does not repeat: it is sent once per session via the SSM, not re-sent with
each task (reference-architecture.md §9). Direct data transfer (bypassing the SSM
entirely) is available but requires the compute host to connect back to the
client’s own listening port, which pulls clients into the firewall matrix if enabled — not used in the current build.
The demo proof point
The Phase 2 exit test for this whole use case is the Symphony sample app running
end to end: a Linux client submits work and Windows service instances execute it
(deployment-plan.md Phase 2.4). Everything on this page — vemkd, the Session
Director, the pinned SSM range, LIM/PEM — exists and is configured in the current
sym-aws build.
|
This proof point is pending the open join last-mile. The four compounding root
causes behind the Windows compute-host join (no |
Continue to UC2 — Burst to cloud, or see Symphony management and Windows compute pool for the components behind each hop.