ADC

Cas d’utilisation 2 : configurer la persistance basée sur des règles en fonction d’une paire nom-valeur dans un flux d’octets TCP

August 11, 2023

Contributeur:

Certains protocoles transmettent des paires nom-valeur dans un flux d’octets TCP. Le protocole du flux d’octets TCP dans cet exemple est le protocole FIX (Financial Information eXchange). Dans une implémentation non XML, le protocole FIX permet à deux hôtes communiquant via un réseau d’échanger des informations commerciales ou liées au commerce sous forme de liste de paires nom-valeur (appelées « champs FIX »). Le format du champ est <tag>=<value><delimiter>. Ce format de valeur de balise traditionnel rend le protocole FIX idéal pour ce cas d’utilisation.

La balise dans un champ FIX est un identifiant numérique qui indique la signification du champ. Dans cet exemple ;

La balise 35 indique le type de message.
La valeur après le signe égal a une signification spécifique pour la balise donnée et est associée à un type de données. La valeur A pour la balise 35 indique que le message est un message d’ouverture de session.
Le délimiteur est le caractère ASCII « Start of Header » (SOH) non imprimable (0x01), qui est le symbole de curseur (^).
Un nom est également attribué à chaque champ. Le champ portant la balise 35 est le champ MsgType.

Voici un exemple de message d’ouverture de session.

8=FIX.4.1 9=61 35=A 49=INVMGR 56=BRKR 34=1 52= 20000426-12:05:06 98=0 108=30 10=157

Votre choix de type de persistance pour une liste de valeurs de balises telle que celle présentée ci-dessus est déterminé par les options qui s’offrent à vous pour extraire une chaîne particulière de la liste. Les méthodes de persistance basées sur des jetons nécessitent que vous spécifiez le décalage et la longueur du jeton que vous souhaitez extraire de la charge utile. Le protocole FIX ne vous permet pas de le faire, car le décalage d’un champ donné et la longueur de sa valeur peuvent varier d’un message à l’autre. Cette variation dépend du type de message, des champs précédents et de la longueur des valeurs précédentes. Il varie également en fonction de l’implémentation de l’un à l’autre, selon que des champs personnalisés ont été définis ou non. De telles variations rendent impossible de prédire le décalage exact d’un champ donné ou de spécifier la longueur de la valeur à extraire comme jeton. Dans ce cas, la persistance basée sur des règles est donc le type de persistance préféré.

Supposons qu’un serveur virtuel fixlb1 équilibrage la charge des connexions TCP à une batterie de serveurs hébergeant des instances d’une application compatible FIX. Vous souhaitez configurer la persistance des connexions sur la base de la valeur du champ SenderCompid, qui identifie l’entreprise qui envoie le message. La balise de ce champ FIX est 49 (illustrée dans l’exemple de message d’ouverture de session précédent).

Pour configurer la persistance basée sur des règles pour le serveur virtuel d’équilibrage de charge, définissez le type de persistance du serveur virtuel d’équilibrage de charge sur RULE et configurez le paramètre de règle avec une expression. L’expression doit extraire la partie de la charge utile TCP dans laquelle vous pensez trouver le champ SenderCompID, tape la chaîne résultante dans une liste nom-valeur basée sur les délimiteurs, puis extrait la valeur du champ SenderCompID (balise 49), comme suit :

set lb vserver fixlb1 -persistenceType RULE -rule "CLIENT.TCP.PAYLOAD(300).TYPECAST_NVLIST_T('=','^').VALUE("\49\")"

Remarque : Des barres obliques inverses ont été utilisées dans l’expression car il s’agit d’une commande CLI. Si vous utilisez l’utilitaire de configuration, ne saisissez pas de barres obliques inverses.

Si le client envoie un message FIX contenant la liste nom-valeur de l’exemple de message d’ouverture de session précédent, l’expression extrait la valeur INVMGR et l’appliance NetScaler crée une session de persistance basée sur cette valeur.

L’argument de la fonction PAYLOAD () peut être aussi grand que vous le jugez nécessaire pour inclure le champ SenderCompid dans la chaîne extraite par la fonction. Vous pouvez également utiliser la fonction SET_TEXT_MODE (IGNORECASE) si vous souhaitez que l’appliance ignore la casse lors de l’extraction de la valeur du champ, et que la fonction HASH crée une session de persistance basée sur un hachage de la valeur extraite. L’expression suivante utilise les fonctions SET_TEXT_MODE (IGNORECASE) et HASH :

CLIENT.TCP.PAYLOAD(500).TYPECAST_NVLIST_T('=','^').SET_TEXT_MODE(IGNORECASE).VALUE("49").HASH

Vous trouverez ci-dessous d’autres exemples de règles que vous pouvez utiliser pour configurer la persistance des connexions FIX (à <tag> remplacer par la balise du champ dont vous souhaitez extraire la valeur) :

Pour extraire la valeur d’un champ FIX dans les 300 premiers octets de la charge utile TCP, vous pouvez utiliser l’expression CLIENT.TCP.PAYLOAD(300).BEFORE_STR(“^”).AFTER_STR(“<tag>=”).
Pour extraire une chaîne de 20 octets au décalage 80, convertissez la chaîne dans une liste nom-valeur, puis extrayez la valeur du champ souhaité, utilisez l’expression CLIENT.TCP.PAYLOAD(100).SUBSTR(80,20).TYPECAST_NVLIST_T(‘=’,’^’).VALUE(“<tag>”).
Pour extraire les 100 premiers octets de la charge utile TCP, convertissez la chaîne dans une liste nom-valeur et extraire la valeur de la troisième occurrence du champ souhaité, utilisez l’expression CLIENT.TCP.PAYLOAD(100).TYPECAST_NVLIST_T(‘=’,’^’).VALUE(“<tag>“,2). Remarque : Si le second argument transmis à la fonction VALUE() est n, l’appliance extrait la valeur de l’instance (n+1) <sup>th</sup> du champ car le nombre commence à zéro ( 0).

Vous trouverez ci-dessous d’autres exemples de règles que vous pouvez utiliser pour configurer la persistance. Seules les expressions basées sur la charge utile peuvent évaluer les données transmises via le protocole FIX. Les autres expressions sont des expressions plus générales permettant de configurer la persistance sur la base de protocoles réseau inférieurs.

CLIENT.TCP.PAYLOAD(100)
CLIENT.TCP.PAYLOAD (100) .HASH
CLIENT.TCP.PAYLOAD (100) .SUBSTR (5,10)
CLIENT.TCP.SRCPORT
CLIENT.TCP.DSTPORT
CLIENT.IP.SRC
CLIENT.IP.DST
CLIENT.IP.SRC.GET4
CLIENT.IP.DST.GET4
CLIENT.ETHER.SRCMAC.GET6
CLIENT.ETHER.DSTMAC.GET5
CLIENT.VLAN.ID

La version officielle de ce document est en anglais. Certains contenus de la documentation Cloud Software Group ont été traduits de façon automatique à des fins pratiques uniquement. Cloud Software Group n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Cloud Software Group à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Cloud Software Group, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Cloud Software Group ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

Cas d’utilisation 2 : configurer la persistance basée sur des règles en fonction d’une paire nom-valeur dans un flux d’octets TCP

August 11, 2023

Contributeur:

August 11, 2023

Contributeur:

Cas d’utilisation 2 : configurer la persistance basée sur des règles en fonction d’une paire nom-valeur dans un flux d’octets TCP

Dans cet article