Share via

3.1.4.1 Creating a RunspacePool

  • Article

The higher-layer triggers the RunspacePool creation on the client. The following activities happen as part of the RunspacePool creation. During the RunspacePool creation time, the client sends PSRP messages to a server and receives PSRP messages back from the server. The client expects certain specific PSRP messages from the server at each stage, as described later in this section. If the client does not receive expected messages at each stage, the client terminates the RunspacePool creation and notifies the higher-layer. If a wxf:Fault message is received at any stage, the client reports the failure to the higher-layer, closes the RunspacePool as specified in section 3.1.5.3.13, and terminates the RunspacePool creation.

  1. The client creates a new RunspacePool, assigns a unique GUID to this RunspacePool as described in section 3.1.1.2.1, and initializes the RunspacePool state to Opening as described in section 3.1.1.2.2.

  2. The client constructs a SESSION_CAPABILITY message (as specified in section 2.2.2.1) and an INIT_RUNSPACEPOOL message (section 2.2.2.2). The client then constructs fragmented messages for these PSRP messages using the rules specified in section 3.1.5.1.1.

  3. The client MUST use wxf:Create (section 3.1.4.5.2) to create a RunspacePool on the server. While sending the wxf:Create message, the client sends as many fragments as possible from step 2, along with the wxf:Create message, using the <open content> portion, as specified in section 3.1.5.3.1. If all fragments of the SESSION_CAPABILITY message have been sent, then the client changes the RunspacePool state (section 3.1.1.2) to NegotiationSent; otherwise, the RunspacePool state change is delayed until step 6.

  4. If the client receives a wxf:ResourceCreated message, the client stores the ShellID from the response (sections 3.1.1.1.1 and 3.1.1.2.4), as specified in section 3.1.5.3.1. If the client receives a wxf:Fault message, the client reports the failure to the higher-layer and terminates RunspacePool creation.

  5. At this point, the client has a ShellID associated with the remote RunspacePool and MUST send a wxf:Receive message (section 3.1.5.3.7) to the server to start receiving data from the server.

    After each received wxf:ReceiveResponse message, the client MUST send another wxf:Receive if the RunspacePool is not in a Closed or Broken state.

  6. If there are any fragments left in step 3, the remaining fragments MUST be sent using one or more wxf:Send messages (as specified in section 3.1.5.3.5). If the RunspacePool state (section 3.1.1.2) was not changed to NegotiationSent in step 3, then it is changed after sending the last fragment of the SESSION_CAPABILITY message.

  7. The client expects a SESSION_CAPABILITY message (section 2.2.2.1) from the server at this stage. If a SESSION_CAPABILITY message is received, then the client hands over the Session Capability to the higher-layer.

  8. The client changes the RunspacePool state (section 3.1.1.2) to NegotiationSucceeded.

  9. The client expects an APPLICATION_PRIVATE_DATA message (section 2.2.2.13) from the server at this stage. If an APPLICATION_PRIVATE_DATA message is received, then the client hands over the application private data to the higher-layer.

  10. The client expects the RUNSPACEPOOL_STATE message (section 2.2.2.9) from the server at this stage. If a RUNSPACEPOOL_STATE message is received, then the client extracts the State from the message and changes the RunspacePool state (section 3.1.1.2) to Opened.

When the RunspacePool state is in Opened state, the higher-layer can trigger other events, such as Executing a pipeline (section 3.1.4.3) or Closing the RunspacePool (section 3.1.4.2).