クライアント リクエストを完全に制御することは簡単に行えますが、適切なサーバー レスポンスを見込むことは困難です。最も重要なことは、仮想ユーザーはサーバー レスポンスが完了したときを知る必要があるということです。それによって、続くリクエストを処理することが可能になり、またサーバー レスポンスにエラーが含まれていたり、完了しない場合にエラーを発生させたりできます。
WebTcpipRecvExact(hWeb0, NULL, 26);
再生時に、仮想ユーザーはサーバーから正確に 26 バイト受信することを期待します。しして、スクリプトの次のステートメントを使って続行します。サーバーが 26 バイトを超えて送信する場合、そのバイトは次の WebTcpipRecvExact ステートメントによって受信されます (以降のすべてのスクリプト実行は予測不能になります)。サーバーが送信するバイトが少ない場合、WebTcpipRecvExact はタイムアウト エラーを報告します。
よって、レスポンスのバイト数がどのような状況でも変わらない場合にのみ、この行を変更せずに残すことができます。レスポンス長を保証できない場合、さまざまな長さのサーバー レスポンスを処理できるようにスクリプトをカスタマイズしなければなりません。
プロトコルのセマンティクスに基づいた適切なカスタマイズ3 つの共通のシナリオは、カスタマイズ処理を簡単にする Silk Performer API 関数によって反映されます。
リクエストとレスポンス データの長さは、パケットの定義済みの位置にエンコードされている場合があります (大抵は、パケット ヘッダー)。Silk Performer 関数 WebTcpipRecvProto とその同系の WebTcpipRecvProtoEx は、このような状況を適切に処理できます。これらは、レスポンス データのパケット長情報の位置と長さの定義を考慮します。たとえば、次の BDL コードの行は、レスポンス データの長さが、サーバー レスポンスの最初の 2 バイト (たとえば、位置 0) に 2 バイト シーケンスで埋め込まれている場合に使用できます。
WebTcpipRecvProto(hWeb, 0, 2, TCP_FLAG_INCLUDE_PROTO, sData, sizeof(sData), nReceived);
このシナリオでは、データ パケットは一定のバイト シーケンスで終了します。対応する Silk Performer 関数は、WebTcpipRecvUntil です。たとえば、終了シーケンスが 2 バイト シーケンス 0xFF00 で定義されている場合、次の行は正しく処理されます。
WebTcpipRecvUntil(hWeb, sResp, sizeof(sResp), nRecv, "\hff00", 2);
これは、3 つのシナリオのうち一番困難です。関数を組み合わせて使用できます。 WebTcpipRecv を使用して、サーバーからの不明な長さのバッファを受信します。そして、WebTcpipSelect を使用して、提供した接続ハンドルに対するその後の WebTcpipRecv 操作がブロックされるか、直ちに成功するかどうかを確認します。
Silk Performer は、ルール ベースの記録 という高度な機能を提供します。.独自の TCP/IP プロトコルのセマンティクスを認識できるように、TCP/IP Recorder を設定できます。特に、Recorder は、先に議論した 2 つのシナリオに対して設定できます (パケットに含まれるパケット長、および終了バイト シーケンス)。
結果として、Recorder は正しい WebTcpipRecvProto(Ex) 関数と WebTcpipRecvUntil 関数を自動的に生成でき、さらにスクリプトのこの部分をカスタマイズする必要はありません。
記録ルールを設定する際に、記録ルールを XML でエンコードした設定ファイルを書き、ドキュメント フォルダ (プロジェクト固有のルール) または、パブリックかユーザーの RecordingRules ディレクトリに保存します (グローバル ルール).ます。記録ルール ファイルは、ファイル拡張子 .xrl を持ちます。
ルール ベースの記録は、TCP/IP および HTTP に対して存在しますが、このセクションで議論する対象の記録ルールは、TCP/IP に対するものだけです。