4.2.1 Normal Scenario

  • Article

Initialization: The RDG client obtains the name of an RDG server by using an out-of-band mechanism. The RDG client creates an HTTP session as follows:

  • A proxy name is not specified.

  • Asynchronous response is requested.

  • The status continue setting is set to FALSE.

  • The redirect policy is set to never redirect.

  • The resolve timeout is set to 2 minutes.

  • The connect timeout is set to 1 minute.

  • The send timeout is set to 30 seconds.

  • The receive response timeout is set to 90 seconds.

  • The receive timeout is set to 30 seconds.

  1. The RDG client creates the OUT channel by sending a request with the RDG_OUT_DATA (section 2.2.3.1.2) custom command and the custom header RDG-Connection-Id (section 2.2.3.2.1) set to a unique identifier. A GUID generated by the RDG client is used for this purpose; (such as {0x958F92D8,0xDA20,0x467a,{0xBB,0xE3,0x65,0xE7,0xE9,0xB4,0xED,0xCF}}). The RDG client disallows caching and uses accept type as */*. The target resource used is "/remoteDesktopGateway/". The HTTP version is 1.1 as described in section 3.3.5.1.

  2. The RDG server interprets this request as a request to create an OUT channel. It returns an HTTP 401 status code (authentication required) with the supported authentication schemes in the WWW-Authenticate header as described in section 3.3.5.1.

  3. The RDG client selects an authentication method and starts the authentication exchange by setting the Authorization header. Messages are exchanged back and forth until the client is authenticated, as described in section 3.3.5.1.

  4. The server sends back the final status code 200 OK, and a random entity body of limited size (100 bytes). This enables a reverse proxy to start allowing data from the RDG server to the RDG client. The RDG server does not specify an entity length in its response, as described in section 3.3.5.1.

  5. The RDG client resends the request on the same connection. The RDG server recognizes this second request as an authenticated connection request.

  6. The RDG client creates an IN channel by sending a request with the RDG_IN_DATA (section 2.2.3.1.1) custom command and the custom header RDG-Connection-Id set to the same unique identifier and GUID used for creating the OUT channel. In the example, it is {0x958F92D8,0xDA20,0x467a,{0xBB,0xE3,0x65,0xE7,0xE9,0xB4,0xED,0xCF}}. The RDG client disallows caching and uses accept type as */*. The target resource used is "/remoteDesktopGateway/". The HTTP version is 1.1, as described in section 3.3.5.1.

  7. The RDG server interprets this as a request to create an IN channel. It sends back an HTTP 401 status code (authentication required) with the supported authentication schemes in the WWW-Authenticate header as described in section 3.3.5.1.

  8. The RDG client selects an authentication method and starts the authentication exchange by setting the Authorization header. Messages are exchanged back and forth until the client is authenticated, as described in section 3.3.5.1.

  9. The server sends back the final status code 200 OK, and a random entity body of limited size (100 bytes). This enables a reverse proxy to start allowing data from RDG server to RDG client. The RDG server does not specify an entity length in its response, as described in section 3.3.5.1.

  10. The RDG client resends the request on the same connection. The RDG server recognizes this second request as an authenticated connection request. From this point on, data communication between the RDG client and RDG server is done by using the HTTP entity body.

  11. After OUT and IN channels have been created, the RDG client sends the HTTP_HANDSHAKE_REQUEST_PACKET (section 2.2.10.10) in the HTTP entity body.

         pHandShakePacket->hdr.packetType = PKT_TYPE_HANDSHAKE_REQUEST;    pHandShakePacket->verMajor = 1;    pHandShakePacket->verMinor = 0;    pHandShakePacket->ExtendedAuth = 0;

  12. The RDG server responds back with an HTTP_HANDSHAKE_RESPONSE_PACKET (section 2.2.10.11) in the HTTP entity body, giving details of its version and the supported authentication schemes.

         pHandShakePacket->hdr.packetType = PKT_TYPE_HANDSHAKE_RESPONSE;    pHandShakePacket->verMajor = 1;    pHandShakePacket->verMinor = 0;    pHandShakePacket->ExtendedAuth = HTTP_EXTENDED_AUTH_PAA | HTTP_EXTENDED_AUTH_SC;

  13. The RDG client sends HTTP_TUNNEL_PACKET (section 2.2.10.18) to request tunnel creation.

         pTunnelPacket->hdr.packetType = PKT_TYPE_TUNNEL_CREATE;    pTunnelPacket->capsFlags = 0x3F;    pTunnelPacket->fieldsPresent = 0

  14. The RDG server responds with HTTP_TUNNEL_RESPONSE (section 2.2.10.20) and HTTP_TUNNEL_RESPONSE_OPTIONAL (section 2.2.10.21).

         HTTP_TUNNEL_RESPONSE   *pResponsePacket = (HTTP_TUNNEL_RESPONSE*)pPacket;    HTTP_TUNNEL_RESPONSE_OPTIONAL  *pResponsePacketOpt =    (HTTP_TUNNEL_RESPONSE_OPTIONAL)(pPacket + sizeof(HTTP_TUNNEL_RESPONSE));    pResponsePacket->hdr.packetType = PKT_TYPE_TUNNEL_RESPONSE;    pResponsePacket->statusCode = 0;     pResponsePacket->fieldsPresent = HTTP_TUNNEL_RESPONSE_FIELD_TUNNEL_ID |     HTTP_TUNNEL_RESPONSE_FIELD_CAPS;    pResponsePacketOpt->tunnelId = 6;    pResponsePacketOpt ->capsFlags = 0x3F

  15. The RDG client sends HTTP_TUNNEL_AUTH_PACKET (section 2.2.10.14) and HTTP_TUNNEL_AUTH_PACKET_OPTIONAL (section 2.2.10.15) to the RDG server to request tunnel authorization.

         pAuthPacket->hdr.packetType = PKT_TYPE_TUNNEL_AUTH;    pAuthPacket->cbClientName = 22;    pAuthPacket->cbClientName = "RDG-Client1";

  16. The RDG server responds with HTTP_TUNNEL_AUTH_RESPONSE and HTTP_TUNNEL_AUTH_RESPONSE_OPTIONAL to the RDG client.

         pAuthResponse->hdr.packetType = PKT_TYPE_TUNNEL_AUTH_RESPONSE;    pAuthResponse->errorCode = hrIn;    pAuthResponse->fieldsPresent = HTTP_TUNNEL_AUTH_RESPONSE_FIELD_REDIR_FLAGS |     HTTP_TUNNEL_AUTH_RESPONSE_FIELD_IDLE_TIMEOUT;    pAuthResponseOpt->redirFlags = 0;    pAuthResponseOpt -> idleTimeout = 0;

  17. The RDG client sends HTTP_CHANNEL_PACKET (section 2.2.10.2) to request channel creation.

         pChannelPkt->hdr.packetType = PKT_TYPE_CHANNEL_CREATE;    pChannelPkt->numResources = 1;    pChannelPkt->numAltResources = 0;    pChannelPkt->port = 3389;    pChannelPkt->protocol = 3;

  18. The RDG server responds with HTTP_CHANNEL_RESPONSE (section 2.2.10.4) and HTTP_CHANNEL_RESPONSE_OPTIONAL (section 2.2.10.5).

         pChannelResp->hdr.packetType = PKT_TYPE_CHANNEL_RESPONSE;    pChannelResp->errorCode = 0;    pChannelResp->fieldsPresent = HTTP_CHANNEL_RESPONSE_FIELD_CHANNELID|    HTTP_CHANNEL_RESPONSE_FIELD_UDPPORT| HTTP_CHANNEL_RESPONSE_FIELD_AUTHNCOOKIE;    pChannelRespOpt->channelId = 1;    pChannelRespOpt->udpPort = 3391;    pChannelRespOpt->authnCookie.cbLen = 1433;    pChannelRespOpt->authnCookie.blob = <encrypted blob>