NOTE: High level support for Terminal Emulation exists in the current versions of Silk Performer. Please see the 'Terminal Emulation Support' section of Help for more details.
The information below is for those instances where no Terminal Emulation client exists or TCP/IP traffic is the only option available.
Also, since the introduction of GUI-Level testing in SilkPerformer 2006 Release 2, it may be possible to loadtest applications that are not supported by SilkPerformer on the protocol- or API-levels by recording at the GUI level. Please refer to the 'GUI-Level Testing Support' section of Help for full details.
TCP/IP is designed to handle underlying Network traffic. The protocol offers a range of services such as full error detection and correction, flow control, sequencing and its Interoperability means that it is the one of the most common protocols used. The TCP/IP protocol is the lowest level of traffic that can be captured by the SilkPerformer Recorder.
In order to decide whether or not you will be able to load test an application using SilkPerformer TCP/IP functions you have to consider three things:
- The amount and type of data returned by the Server:
When you record HTTP traffic between a Client and a Server at TCP/IP level what you will see generated in the BDF script will be mainly client requests made to a server via the function "WebTcpipSend" function. These client requests will be shown in ASCII text format as Request Headers.
Every Client Request will be followed by a Response from the Server, this can be seen in the form of functions such as "WebTcpipRecvExact". The purpose of this function is to retrieve an exact number of bytes from the server or an error will be flagged, however this will cause problems on replay of the script if the server response is dynamic in size. This problem can be easily rectified if you replace the function "WebTcpipRecvExact" with "WebTcpipRecvUntil" function which retrieve the response from the server until a particular pattern is found. It is critical that you distinguish exactly what this pattern is. It is possible to implement Recording Rules for the SilkPerformer Recorder to avoid this type of behavior occurring during the Record process, see below for further details.
- Determine if the generated TCP/IP Recorded BDF script is suitable for replay in SilkPerformer
In essence by recording at TCP/IP level you are able to capture the proprietary traffic sent by the Custom application which is carried by this underlying protocol. However you have to consider the type of traffic generated, for example you should note that not all protocols are practical at the TCP/IP level, especially complex standard protocols (e.g. JDBC or RMI), or traffic that is encrypted using non-SSL encryption.
There are three questions a user should ask when deciding if it makes sense to replay a generated TCP/IP Recorded script in SilkPerformer.
- Question:Is the generated traffic readable or does it use a character set other than ASCII?.
Answer: If on inspection of the script the generated traffic appears not to be ASCII then a user should be aware of the validity of replaying the script without customization; the reason being is that the script in its current format is un-readable and thus a user may be unaware if customization is required. To combat this problem SilkPerformer provides character mapping functions which can easily be implemented in SilkPerformer"s BDL language. For example a user can build a function "EBCDIC2ASC" which will convert EBCDIC characters to ASCII; thus allowing a user to perform any necessary manipulation and customization which may be required to enable successful replay.
The following below is an example of TCP/IP traffic recorded by SilkPerformer which requires character conversion:
WebTcpipSendBin(hWeb0, "\h00000000007DD7D311D57CA2899392F0"// }WS U|" p"\hF0F14011D74CA2899392F0F0F140FFEF", 32); // pq@ WL" ppq@ o WebTcpipRecvExact(hWeb0, NULL, 645);Customization of such a script may at first appear daunting; the server responses (not shown in the above example) look much like the client request in they do not include a single readable character. However the reality is that customization of such a script is fairly simple; in the above example the server is an IBM mainframe that uses the EBCDIC (Extended Binary Coded Decimal Interchange Code) character set rather than the more familiar ASCII character set. There is a simple one-to-one mapping between these two character sets, which can be implemented as a SilkPerformer function. For further detailed information on performing character mapping please refer to the Whitepaper "Load Testing Legacy and Custom TCP/IP Based Protocols with SilkPerformer".
- Question:Is the traffic encrypted with a custom encryption algorithm (i.e., one that doesn"t rely on SSL, which would automatically be supported by SilkPerformer)?.
Answer: The encryption/decryption routines should be re-implemented in SilkPerformer script by implementing the logic of the algorithm in the BDL language. Alternatively the encryption/decryption algorithms could be accessible in SilkPerformer via a DLL or a SilkPerformer framework (e.g., Java Framework).
- Question:Does the traffic contain any strings?
Answer: If the traffic generated in the script only consists of numbers which are sent as binary then a user will normally not have to worry about customization or string conversion.
- Question:Is the generated traffic readable or does it use a character set other than ASCII?.
- Customizing session / data hard-coded in the script
It is important to note that the majority of TCP/IP based protocols rely on TCP/IP connections between server and client to keep the communication open and active during sessions, as a result of this they do not contain any session ID"s. Therefore the problems that can arise when customizing load test scripts for stateless protocols such as HTML often don"t exist; so a user may not need to worry about parsing session id"s. However with every rule there are of course exceptions, so a user should always check the generated TCP/IP script and look out for any session ID"s that may be being sent to the server (normally a constant number which is sent to the server for each request). A good way to do this is to use the Compare Wizard in the TrueLog Explorer to identify any differences in the server response data. If any session information is found a user can write out the server response by adding the parameter "sData" to any WebTcpIpRecv function; there is a resolution listed below which explains in detail how to customize binary data in SilkPerformer BDF script.
It is also essential to have access to someone who really understands the protocol used for communication. In order to manipulate the script to enable successful replay. For example some of this proprietary traffic will contain hexadecimal or binary data which will then need to be interpreted in order to customize. This means understanding how connections are established, the format of requests, being able to understand any encryption, how requests are terminated etc. If you do not have a clear understanding of this it is very likely that your TCP/IP script will fail on replay.
- Creating "Advanced Recording Rules" for the TCP/IP protocol to be used by the SilkPerformer Recorder.
Recording rule files are written in XML, have a .XRL file extension, and can be stored either in the include directory "..\SilkPerformer 6.5\Working\Include\" for global rules, or the current project directory"..\SilkPerformer 6.5\Working\Projects\MyProject\Documents" for project specific rules.
Without SilkPerformer recording rules, the server responses are scripted by the "WebTcpipRecvExact() function calls. The recorder uses the TCP/IP to detect user defined termination sequences, if detected the Recorder generates functions which are better suited to handling dynamic server responses.
There are two types of TCP/IP Protocol Rules that can be created.
TcpRuleRecvProto
This rule is used to describe length based protocols. Length based protocols are protocols in which the number of bytes received from the server can be extracted from a fixed location in a protocol header. This rule type is specified by XML nodes with the name TcpRuleRecvProto.Using this rule the number of bytes can be extracted from the protocol header at offset "LengthOffset" using "lengthLen" number of bytes. This can be interpreted by specifying the byte order of the packet-length section using the Little-endian representation means that the most significant byte is at the end. At the opposite end is the (default) Big-endian which means that the most significant byte is at the front of the packet-length section.
There is also added attributes and conditions which can be applied in order to specify exactly where the rules should be applied this is beneficial when a user wishes to exclude the detection of a protocol where the server responses coincidentally resemble protocol specifications.
TcpRuleRecUntil
This rule is used to describe protocols in which the end of a server response can be detected by a terminating sequence of bytes. This rule type is specified by XML nodes with the name TcpRuleRecvUntil.The main attribute required when using this rule is the terminating byte sequence of the protocol however you can added conditions in the same manner as the other Recording Rule and you can also use the attribute to "ignore white spaces" which will mean the recorder will ignore white spaces when searching for the terminating data.
Further details on Recording Rules and testing custom TCP/IP based protocols are located in the whitepapers called Rule-Based Recording With SilkPerformer and Load Testing Legacy and Custom TCP/IP Based Protocols which can be found by going to:
"START | All PROGRAMS | SILK | SILKPERFORMER x.x | DOCUMENTATION | ADVANCED CONCEPT BOOK"
For information on customizing the binary data generated by TCP/IP traffic please view the following resolution - How can I customize binary data in my script ?