Using CA Service Virtualization › Using the Workstation and Console with CA Service Virtualization › Creating Service Images › Create Service Image by Recording › Transport Protocols › TCP › Virtualize TCP

Virtualize TCP

The TCP transport protocol lets you virtualize raw TCP/IP traffic between one or more clients and a server. This transport resembles the HTTP protocol, and uses many of the same features.

During recording, you configure the TCP protocol exactly as you would configure HTTP in Endpoint mode. You give it a socket on which to listen, the target server, and the destination. The protocol forwards data between the client and server, and "listens in" on that data to create VSE transactions.

Converting Bytes to VSE Transactions

It can be difficult to know what comprises a complete request or response, and how to correlate those requests and responses. The TCP data has no inherent structure. A request delimiter is required to identify requests in the incoming data stream. You can also select a response delimiter, although a response delimiter is not strictly required.

The recorder uses the following rules to determine requests and responses, and to correlate requests and responses together into transactions:

1. Zero or one responses follow a request.
2. Each response is paired with the latest complete request.
3. A request is considered complete when response data arrives, even if the request delimiter says it is not complete.
4. A response is considered complete when request data arrives, even if the response delimiter (if any) says it is not complete.
5. If the response delimiter finds a complete response when response data is received, any extra response data is discarded.

For example:.

Request 1 - Request 2 - Response A - Partial Request 3 - Response B - Request 4 - Partial Response C - Request 5 - Response D With Trailing Data

This data is parsed into transactions as follows:

• Request 1 with no response
• Request 2 with Response A (from rule 2)
• Partial Request 3 with Response B (from rule 3)
• Request 4 with Partial Response C (from rule 4)
• Request 5 with Response D, but with the "trailing data" dropped (from rule 5)

This system works if the client and server follow a synchronous request/response paradigm, and it handles requests with no responses. The system does not handle asynchronous communication, or one request with multiple responses.

Creating Conversations

By default, it records TCP service images, VSE creates conversations based on your machine name (or IP address) and the outbound socket. Any time your outbound socket changes, a new conversation is started. To change this behavior, select the Treat all conversations as stateless check box.

Out-of-the-Box Delimiters

DevTest has the following delimiters:

Records are terminated with line endings

One or more newline characters terminates each request/response. The delimiter itself is not included in the request/response.

Values:

• \n
• \r
• Unicode characters 0085, 2028, and 2029

Records are of fixed length

Each request/response is a specific number of bytes in length.

Records are delimited by specific characters

A specific character or sequence of characters, such as a comma, terminates each request/response. The entire sequence must be matched. The delimiter itself is not included in the request/response. This option is similarto importing a CSV file.

Delimiters match a regular expression

A set of bytes that matches the regular expression terminates each request/response. The delimiter itself is not included in the request/response.

If the delimiter characters are not included in the request/response (as in most cases), back-to-back sets of delimiters are ignored.

Note: You cannot edit the selected delimiter after the recording is done. You cannot change the selected delimiter in the model editor.

Treat Request as Text and Treat Response as Text

The Treat Request as Text and Treat Response as Text check boxes control how the request and response data is parsed.

Treat Request as Text

Specifies whether to use the request as the body of the VSE request.

Values:

• Selected: Sets the entire request as the body text of the VSE request. The first "word" (up to the first space character) is used as the operation name.
• Cleared: Leaves the request body as binary and sets the operation name to OPERATION.

Treat Request as Text

Specifies whether to use the request as the body of the VSE request.

Values:

• Selected: Treats the response body as text and converts any embedded nulls (\0) to spaces.
• Cleared: Leaves the response body as binary.

Why is the Transaction Count Incorrect?

The transaction count always lags by at least one. When the TCP protocol finds a complete transaction, it caches that transaction until the next transaction starts, because the server may intentionally close the socket after responding. If this happens, the TCP protocol detects it and sets lisa.vse.close_socket_after_response=TRUE on the response. This property causes VSE to close the server-side socket after sending that response during playback.

If you do not use a response delimiter, the transaction count lags by another transaction. The TCP protocol does not know the response is finished until a new request starts. So, the total count can be off by two. The count is correct when the recording finishes.