Custom TCP/IP Based Protocols

The following example comes from an application that used an entirely custom TCP/IP based protocol. In this protocol, both the client request and server response data obey a set of predefined message telegram structures consisting of fixed-length fields. Some of the fields are binary (and may therefore contain zero bytes) and some are string type.

Here is a typical request-response pair from the recorded traffic:

WebTcpipConnect(hWeb0, "10.9.96.81", 3311);
WebTcpipSendBin(hWeb0, 
"\h00000280000000000000000000000000" // ················ 
"\h000100000000000000004F4B36302020" // ··········OK60  
... 
"\h303030302B3030303030303030303030" // 0000+00000000000
"\h30303030000000000000000000000000" // 0000············
, 640);
WebTcpipRecvExact(hWeb0, NULL, 80);
WebTcpipShutdown(hWeb0);

Here is the server response from the record log. Based on the third argument of the WebTcpipRecvExact function in the above script, we already know that it contains 80 bytes:

00 00 00 00  ···P············  00 00 00 50 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 10  ··········OK60    00 01 00 00 00 00 00 00 00 00 4F 4B 36 30 20 20
00 00 00 20    ··U60OKS1 SILK  20 20 00 00 55 36 30 4F 4B 53 31 20 53 49 4C 4B
00 00 00 30  01  ············  30 31 20 20 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 40  ················  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Note: The first four bytes (0x00 00 00 50) are a representation of a four-byte integer (a long variable) with the decimal value 80 (5 * 16 = 80). Note that the length of the entire packet is 80 bytes, hence the 4 initial bytes are included in the "packet size" variable. If available, consult protocol documentation regarding the custom application under test. Otherwise you will have to experiment to discover such protocol behavior on your own.

Note: The client request telegram contains the same information. The first four bytes are 0x00 00 02 80, equal to 2*256 + 8*16 = 640. This is the number of bytes sent to the server.

Here is the script after customization. Note that:

An added pair of MeasureStart/MeasureStop functions has been added to measure the time for the request.
The request has been split into several pieces for parameterization, using the function library.
The WebTcpipRecvExact function has been replaced by a call to WebTcpipRecvProto.

Here is the result:

ResetRequestData();
AppendRequestData("\h00000280000000000000000000000000" 
                 "\h00010000000000000000", 26);
AppendRequestData("OK60    ");
AppendRequestData("\h0000", 2);
AppendRequestData(sUser + sPassword);    
// ... (some more lines not displayed here)

MeasureStart("Write Journal");  
WebTcpipConnect(hWeb0, "10.9.96.81", 3311);
SendTcpipRequest(hWeb0);
WebTcpipRecvProto(hWeb0, 0, 4, TCP_FLAG_INCLUDE_PROTO, 
               sResponse, sizeof(sResponse), nReceived);
// ... (response verification not displayed here)
WebTcpipShutdown(hWeb0);
MeasureStop("Write Journal");

Recording Rule Configuration Files

The following recording rule XML file configures the Silk Performer recorder so that it generates the correct WebTcpipRecvProto calls in place of WebTcpipRecvExact. The settings in the Identify node map to the arguments of WebTcpipRecvProto in the script extract above.

<?xml version="1.0" encoding="UTF-8"?>
<RecordingRuleSet>
  <TcpRuleRecvProto>
    <Name>My custom TCP protocol</Name>
    <Identify>
      <LengthOffset>0</LengthOffset>
      <LengthLen>4</LengthLen>
      <OptionFlags>ProtoIncluded</OptionFlags>
    </Identify>
  </TcpRuleRecvProto>
</RecordingRuleSet>