Following is a sampling of TCP/IP traffic recorded by Silk Performer:
WebTcpipSendBin(hWeb0,
"\h00000000007DD7D311D57CA2899392F0" // ·····}×Ó·Õ|¢···ð
"\hF0F14011D74CA2899392F0F0F140FFEF", 32); // ðñ@·×L¢···ððñ@·ï
WebTcpipRecvExact(hWeb0, NULL, 645);
Customization of such a script may at first appear daunting. The server responses (not shown in the example) look much like the client request. They do not include a single readable character.
The reality is that customization of such a script is fairly simple. 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 Silk Performer function.
Other possible causes for traffic that contains unreadable strings:
| Reason | Consequence |
|---|---|
| Traffic uses a character set other than ASCII. | Character mapping functions can easily be implemented in Silk Performer BDL language. |
| Traffic is encrypted with a custom encryption algorithm (for example, one that does not rely on SSL, which is automatically supported by Silk Performer). | The encryption/decryption routines should be re-implemented in BDL, or made accessible to Silk Performer using a DLL or a Silk Performer framework (for example, Java Framework). |
| Traffic does not contain any strings, only numbers sent as binaries. | In such instances you do not have to worry about strings. |