Full control of client requests can be easily achieved however anticipating appropriate server responses can be challenging. Most significantly, virtual users must know when server responses are complete so that they can proceed with subsequent requests, or raise errors if server responses contain errors or aren't complete.
WebTcpipRecvExact(hWeb0, NULL, 26);
During replay, the virtual user expects to receive exactly 26 bytes from the server. It then continues on with the next statement in the script. If the server sends more then 26 bytes, the bytes are received by the next WebTcpipRecvExact statement (making all further script execution unpredictable). If the server sends fewer bytes, WebTcpipRecvExact will report a timeout error.
Therefore this line can remain unchanged only if the number of response bytes won't change under any circumstances. If response length cannot be guaranteed, scripts must be customized so that they can handle server responses of varying length.
Appropriate customization depends on the semantics of the protocol. Three common scenarios are reflected by Silk Performer API functions, which simplify the customization process.
The length of request and response data may be encoded into packets at a defined position (typically in the packet header). The Silk Performer function WebTcpipRecvProto and its sibling, WebTcpipRecvProtoEx, can adequately handle such situations. They allow for definition of the position and length of packet-length information in response data. For example, the following BDL code line will be used if the length of the response data remains a two-byte sequence in the first two bytes (for example, position 0) of the server response:
WebTcpipRecvProto(hWeb, 0, 2, TCP_FLAG_INCLUDE_PROTO, sData, sizeof(sData), nReceived);
In this scenario data packets are terminated by a constant byte sequence. The corresponding Silk Performer function is WebTcpipRecvUntil. If, for example, the end sequence is defined by the two-byte sequence 0xFF00, the following line would be appropriate:
WebTcpipRecvUntil(hWeb, sResp, sizeof(sResp), nRecv, "\hff00", 2);
This is the most challenging of the three scenarios. You can use a combination of the functions WebTcpipRecv, which receives a buffer of unknown length from the server, and WebTcpipSelect, which checks whether or not a subsequent WebTcpipRecv operation on the provided connection handle will block or succeed immediately.
An advanced feature offered by Silk Performer is rule-based recording. You can configure the TCP/IP recorder to be aware of the semantics of proprietary TCP/IP protocols. In particular, the recorder can be configured for two of the scenarios discussed earlier (Packet length contained in the packet and termination byte sequence).
As a result, the recorder can automatically generate correct WebTcpipRecvProto(Ex) and WebTcpipRecvUntil functions so that further customization for this part of the script isn't required.
When configuring recording rules, you write a configuration file encoding the recording rules in XML and save them to the project's Documents folder (project specific rules) or in the public or the user’s RecordingRules directory (global rules). Recording rule files carry the file extension .xrl.
Rule-based recording exists for TCP/IP and HTTP, however only recording rules for TCP/IP are discussed in this section.