Quantcast
Channel: Silk Performer
Viewing all articles
Browse latest Browse all 4084

Wiki Page: When recording at TCP/IP level why do the server responses appear fragmented and how can I amalgamate the fragmented responses?

$
0
0
A server response will often be split over a number of TCP/IP packets during the record, which can be confusing when analyzing the record.log file in order to create a recording rule to deal with dynamic server responses. When looking at server responses in the record.log file consecutive server responses should be viewed as one complete response, beginning with the "WebTcpIpRecvExact" function which occurs after a "WebTcpipSendBin" function. For example the snippet from the record.log file shown below shows two TCP/IP packets which form part of one complete server response. WebTcpipSendBin(hWeb1, "\h434F4E4E4543545F4C0B000000434647" // CONNECT_LCFG 00000000 WebTcpipRecvExact(hWeb1, NULL, 8); TcpipServerToClient(#720, 8 bytes) { CFG_CON_ } WebTcpipRecvExact(hWeb1, NULL, 5); TcpipServerToClientBin(#720, 5 bytes) { 00000000 B 42 00 00 00 00 } WebTcpipShutdown(hWeb1); In the above example the consecutive server-side data (without intervening client-side data) is accumulated by the Silk Performer Recorder and any recording rules will be checked against the overall accumulated data instead of the two individual packets. The reason why the data sent by the server appears to be fragmented in the record.log file is that during the record process the Silk Performer Recorder calls the WinSock function "Recv" repeatedly and subsequently receives multiple chunks of data. During the record process the Recorder cannot be 100% certain if the fragmentation of the packets has anything to do with how the server is sending the data or if the packets were modified or corrupted during the transmission over the network. Therefore the only safe assumption that the Recorder can "logically" make is that the server response is a single response, which happens to be fragmented. Is it possible to amalgamate consecutive fragmented packets in the record.log and BDF script? It does not make sense to amalgamate fragmented server responses as a single server response in the record.log file as this might hide data which may be important for customization. However consecutive fragmented responses can be scripted as one single receive in a BDF script if certain TCP/IP recording rules are present. The first required recording rule is: 3000 60000 The above rule (which is subject to the advanced settings in recording rules) will join data fragments provided the sending and the receiving of the fragments does not exceed the values specified (in milliseconds). However a second rule will also need to be created, which when presented with the preliminary server response says "I don"t know yet if I"m applicable, maybe or maybe not, I need more server response data to decide. So please wait for more response data and ask me again later." An example of this would be a TcpRuleRecvUntil rule, which is waiting for a terminating string which will never appear in the actual server response, e.g.: Sample TCP RecvUntil Rule true This string doesn"t appear in the response Another example for a TcpRuleRecvProto rule would be a recording rule in which the length specification will always result in a VERY LARGE number, e.g.: Sample TCP RecvProto Rule true 0 4 In the above situations, the Silk Performer Recorder will defer scripting and accumulate the consecutive server responses until one of the following scenarios is true: A rule announces that it"s applicable The "Join receive timeout" expires A SEND activity happens on the same TCP connection (or the connection is closed) ANY activity happens on a different TCP connection Once any of the above scenarios occur then the accumulated data will be scripted in the BDF script; however if a recording rule applies then the scripting is done according to the rule which has been invoked. Occasions may arise when only part of the accumulated data is handled by the rule, in this scenario the data which is handled by the rule is removed from the accumulated data, and all rules are re-evaluated on the remaining data, iteratively. However, if no rule applies a WebTcpipRecvExact function will be scripted to handle the server response. Finally the joining of consecutive SENDS in the script will work with or without any recording rules present. This can be easily verified by recording a telnet session to a Unix box. When the password is entered, the server-side echo is turned off. Although each character is immediately sent to the server, the Silk Performer Recorder will still record a single send for the password (e.g. the function "WebTcpIpSend("mypassword"))" even though the request has been sent over numerous packets.

Viewing all articles
Browse latest Browse all 4084

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>