Utilisation de CA Service Virtualization › Utilisation de la Workstation (Station de travail) et de la console avec CA Service Virtualization › Création d'images de service › Création d'une image de service à partir d'un enregistrement › Protocoles de transport › TCP › Virtualisation du protocole TCP

Virtualisation du protocole TCP

Le protocole de transport TCP permet de virtualiser le trafic TCP/IP brut entre un ou plusieurs clients et un serveur. Ce transport est similaire au protocole HTTP et utilise de nombreuses fonctionnalités identiques.

Lors de l'enregistrement, configurez le protocole TCP de la même manière que le protocole HTTP en mode Endpoint (Terminal). Attribuez-lui un socket d'écoute et ajoutez le serveur cible et la destination. Le protocole envoie des données entre le client et le serveur, puis écoute ces données pour créer des transactions de VSE.

Conversion d'octets en transactions du VSE

Il peut être difficile de connaître les éléments constituant une demande ou une réponse complète, ainsi que le mode de corrélation de ces demandes et réponses. Les données TCP n'ont aucune structure inhérente. Un délimiteur de demande est requis pour identifier les demandes dans le flux de données entrantes. Vous pouvez également sélectionner un délimiteur de réponse, mais cela n'est pas strictement requis.

L'enregistreur utilise les règles suivantes pour déterminer des demandes et des réponses et les corréler ensemble dans des transactions :

1. Une demande est suivie de 0 ou 1 réponse.
2. Chaque réponse est associée à la dernière demande complète.
3. Une demande est considérée complète lorsque des données de la réponse arrivent, même si le délimiteur de demande indique qu'elle n'est pas complète.
4. Une réponse est considérée complète lorsque des données de la demande arrivent, même si le délimiteur de réponse (le cas échéant) indique qu'elle ne l'est pas.
5. Si le délimiteur de réponse détecte une réponse complète lorsque des données de réponse sont reçues, toute donnée de réponse supplémentaire sera rejetée.

Par exemple :

Request 1 - Request 2 - Response A - Partial Request 3 - Response B - Request 4 - Partial Response C - Request 5 - Response D With Trailing Data

Ces données sont analysées dans des transactions comme suit :

• Demande 1 sans réponse
• Demande 2 avec réponse A (règle 2)
• Demande partielle 3 avec réponse B (règle 3)
• Demande 4 avec réponse partielle C (règle 4)
• Demande 5 avec réponse D, mais avec les données de fin sont ignorées (règle 5)

Ce système fonctionne si le client et le serveur suivent un paradigme demande - réponse synchrone et qu'il gère les demandes sans réponse. Le système ne gère pas la communication asynchrone, ni une demande avec des réponses multiples.

Création de conversations

Par défaut, lors de l'enregistrement d'images de service TCP, le VSE crée des conversations basées sur le nom de votre ordinateur (ou l'adresse IP) et le socket de sortie. Lors de chaque changement de socket de sortie, une nouvelle conversation est lancée. Pour modifier ce comportement, cochez la case Treat all conversations as stateless (Traiter toutes les conversations comme conversations sans état).

Séparateurs prêts à l'emploi

DevTest contient les délimiteurs suivants :

Les enregistrements se terminent par des fins de ligne.

Les demandes et les réponses se terminent par un ou plusieurs caractères de nouvelle ligne. Le délimiteur même n'est pas inclus dans la demande/réponse.

Valeurs :

• \n
• \r
• Caractères Unicode 0085, 2028 et 2029

Records are of fixed length (La longueur des enregistrements est fixe.)

Les demandes et les réponses correspondent à une longueur en octets spécifique.

Records are delimited by specific characters (Les enregistrements sont délimités par des caractères spécifiques.)

Un caractère ou une séquence de caractères spécifique (par exemple, une virgule) termine les demandes et réponses. La séquence complète doit correspondre. Le délimiteur même n'est pas inclus dans la demande/réponse. Cette option est semblable à l'importation d'un fichier CSV.

Delimiters match a regular expression (Les délimiteurs correspondent à une expression régulière.)

Chaque demande/réponse se termine par un ensemble d'octets correspondant à l'expression régulière. Le délimiteur même n'est pas inclus dans la demande/réponse.

Si les caractères délimiteurs ne sont pas inclus dans la demande/réponse (comme dans la plupart des cas), les ensembles dos à dos de délimiteurs seront ignorés.

Remarque : Une fois l'enregistrement terminé, vous ne pouvez plus modifier le délimiteur sélectionné. Vous ne pouvez pas changer le délimiteur sélectionné dans l'éditeur de modèles.

Options Treat Request as Text (Traiter la demande comme du texte) et Treat Response as Text (Traiter la réponse comme du texte)

Les cases à cocher Treat Request as Text (Traiter la demande comme du texte) et Treat Response as Text (Traiter la réponse comme du texte) contrôlent le mode d'analyse des données de demande et de réponse.

Treat Request as Text (Traiter la demande comme du texte)

Spécifie si la demande doit être utilisée comme corps de la demande de VSE.

Valeurs :

• Si elle est sélectionnée, elle définit l'ensemble de la demande comme corps du texte de la demande du VSE. Le premier terme (avant le premier espace) est utilisé comme nom d'opération.
• Option désélectionnée : conserve le format binaire du corps de la demande et définit le nom d'opération sur OPERATION.

Treat Request as Text (Traiter la demande comme du texte)

Spécifie si la demande doit être utilisée comme corps de la demande de VSE.

Valeurs :

• Option sélectionnée : le corps de la réponse est considéré comme du texte et tous les caractères nuls intégrés (\0) sont convertis en espaces.
• Si elle est désélectionnée, le corps de la réponse sera binaire.

Pourquoi le nombre de transactions est erroné ?

Le nombre de transactions est toujours décalé d'au moins 1 transaction. Lorsque le protocole TCP détecte une transaction complète, il la met en cache jusqu'au démarrage de la transaction suivante, car le serveur peut intentionnellement fermer le socket après l'envoi de la réponse. Si cela se produit, le protocole TCP le détecte et définit lisa.vse.close_socket_after_response=TRUE dans la réponse. Cette propriété indique au VSE de fermer le socket côté serveur après avoir envoyé cette réponse pendant la lecture.

Si vous n'utilisez aucun délimiteur de réponse, le nombre de transactions sera décalé d'une autre transaction. Le protocole TCP ignore que la réponse est terminée jusqu'au démarrage d'une nouvelle demande. L'erreur sur le nombre total peut donc être de 2 transactions. Le nombre sera correct à l'issue de l'enregistrement.