The following test script sequence was taken from a TN3270e traffic recording:
WebTcpipRecvExact(hWeb0, NULL, 3); WebTcpipSendBin(hWeb0, "\hFFFB06", 3); // IAC WILL TIMING-MARK WebTcpipRecvExact(hWeb0, NULL, 3); WebTcpipSendBin(hWeb0, "\hFFFC06", 3); // IAC WON'T TIMING-MARK
In this example, the server challenges the client with a three-byte code (first line of the code above) whenever the client is inactive for a period of time. The client responds with three-byte sequence of its own. Such "ping pong" activity, initiated by the server, can serve as a control mechanism for detecting whether or not a client is still active.
These lines cause problems during replay because they aren't predictable or reproducible. To address such a situation, rather than incorporating the appropriate intelligence into a Silk Performer script, which would be a daunting task, simply disable this feature on the server.
Some background info from RFC 860 (Telnet timing mark option):
"It is sometimes useful for a user or process at one end of a TELNET connection to be sure that previously transmitted data has been completely processed, printed, discarded, or otherwise disposed of. This option provides a mechanism for doing this. In addition, even if the option request (DO TIMING-MARK) is refused (by WON'T TIMING-MARK) the requester is at least assured that the refuser has received (if not processed) all previous data."