Split Deployment Modes

The ADP can run as one execution plane or as a server/client pair. In both cases the use-case application owns participant coordination and the control plane drives dataflow lifecycle signaling.

Standalone mode

Standalone runs registration, dataflow signaling, job execution, event delivery, and the operator API in one process. Use it for local experiments or when the workload and dataspace-facing network can share an environment.

split:
  mode: standalone

Server mode

The server runs in the network that can reach the control plane and other participants. It receives execution submissions and dataflow callbacks, maintains the execution metadata, and bridges job-control messages to the paired client. It does not run the local analytics job.

split:
  mode: server

Client mode

The client runs where the data and workload must remain. It receives an algorithm instance and its data-source bindings over the bridge, starts the local job, and sends status and event messages back to the server. It has no direct DSP registration or transfer-management surface.

split:
  mode: client
  bridgePeerWsUrl: wss://server.example.com

The client does not upload files or negotiate transfers. The use-case application establishes the dataflows at the server side and the server relays only the execution metadata required by the client.

Bridge messages

Server to client:

• algorithm instance created, updated, or deleted;
• local start request;
• remote algorithm event metadata and payloads.

Client to server:

• local job status;
• locally created event metadata and payloads;
• large event data chunks when the payload is too large for one WebSocket message.

Configuration

split:
  mode: client
  bridgePeerWsUrl: wss://server.example.com
  bridgeChunkSize: 524288

Parameter	Type	Description	Default
mode	string	standalone, client, or server	standalone
bridgePeerWsUrl	string	Server WebSocket URL for a client runner	—
bridgeChunkSize	number	Maximum event-data chunk size in bytes	524288