3.1.4.10.3 Connecting to a RunspacePool from a New Client Session

  • Article

The following procedure specifies the sequence of interactions between a client and server when a new client connects to a disconnected RunspacePool:

  1. The client discovers the ShellID value of the RunspacePool to connect to by issuing a wsm:Enumerate message as described in section 3.1.4.10.1.

  2. The client creates a new RunspacePool, assigns the ShellID to this RunspacePool, and initializes the RunspacePool state to Connecting (section 3.1.1.2.2).

  3. The client constructs a SESSION_CAPABILITY message (section 2.2.2.1) and a CONNECT_RUNSPACEPOOL message (section 2.2.2.2). The client then constructs fragmented messages for these messages as specified in section 3.1.5.1.1.

  4. The client MUST send a wxf:Connect message (section 3.1.5.3.14) to create a RunspacePool on the server. The client sends all fragments from the preceding step along with the wxf:Connect message, using the open content portion of the wxf:Connect message. The client changes the RunspacePool state to NegotiationSent.

  5. The client receives a wxf:ConnectResponse message along with a SESSION_CAPABILITY message from the server, then passes the Session Capability to the higher layer. If the client receives a wxf:Fault message, the client reports the failure to the higher layer and terminates the RunspacePool connection.

  6. The client changes the RunspacePool state to Opened and sends a wxf:Receive message to the server.

  7. After each wxf:ReceiveResponse message the client receives from the server, the client MUST send another wxf:Receive as long as the RunspacePool is not in either the Closed or Broken state.

  8. The client waits for APPLICATION_PRIVATE_DATA messages (section 2.2.2.13) from the server and passes any application private data it receives to the higher layer.

When the RunspacePool state is in the Opened state, the higher layer can trigger other events such as closing the RunspacePool (section 3.1.4.2) or executing a pipeline (section 3.1.4.3). Once the RunspacePool is connected, the client can connect to individual pipelines as follows:

  1. The client discovers the Command identifier for the pipeline to connect to (section 3.1.4.10.2).

  2. The client creates a new pipeline, assigns the Command identifier to this pipeline, and initializes the pipeline state to Running (section 3.1.1.3.2).

  3. The client sends a wxf:Connect message (section 3.1.5.3.14) using the above ShellID and Command identifier and waits for a wxf:ConnectResponse message (section 3.1.5.3.15).

  4. When the client receives the wxf:ConnectResponse message from the server, it sends a wxf:Receive message to start receiving data from the pipeline on the server.

  5. After each received wxf:ReceiveResponse message, the client MUST send another wxf:Receive message as long as the pipeline is not in either the Completed or Stopped state.

  6. With the pipeline connected, the client interacts with the higher layer in the three ways specified in section 3.1.4.

  7. If the client receives a PIPELINE_STATE message (section 3.1.5.4.21), the client changes the pipeline state (section 3.1.1.3.2) in accordance with the message and notifies the higher layer.

  8. When the pipeline reaches either the Completed or Failed state, the client removes the pipeline instance from the global table (section 3.1.1.1.2) and from the RunspacePool's pipeline table (section 3.1.1.2.6).

  9. If a wxf:Fault message is received at any step in this procedure, the client reports the failure to the higher layer.