「キープ アライブ」機構における問題

次のテスト スクリプト シーケンスは、TN3270e トラフィックの記録から得られたものです。

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

この例では、ある一定期間の間クライアントが非アクティブであるときに、サーバーは 3 バイト コード (上記コードの最初の行) を使ってクライアントに確認を送信します。クライアントは、自身の 3 バイト シーケンスを使用して応答します。このような「ピンポン」活動は、サーバーによってはじめられ、クライアントがまだアクティブであるかどうかを検出するための制御機構として使用できます。

これらの行は、予測できないまたは再現できないため、再生時に問題を起こします。このような状況を解決するために、Silk Performer スクリプトに適切な知能を組み込むのは非常に困難な作業になるため、単にこの機能をサーバー上で無効化します。

RFC 860 (Telnet タイミング マーク オプション) の基礎知識:

「以前に送信されたデータが完全に処理され、印刷され、破棄され、または捨てられたかことを確実にすることは、TELNET 接続の片端のユーザーまたはプロセスにとって時には有効になります。このオプションはこれを行うための機構を提供します。さらに、オプション リクエスト (DO TIMING-MARK) が拒否されたとしても (WON'T TIMING-MARK により)、リクエスト送信者は、拒否者がすべての前のデータを受信したことが少なくとも保障されます (処理されなかったとしても)。」