ADC

Caso de uso 2: Configurar la persistencia basada en reglas basada en un par nombre-valor en un flujo de bytes TCP

August 11, 2023

Contribución de:

Algunos protocolos transmiten pares de nombre-valor en un flujo de bytes TCP. El protocolo de la secuencia de bytes TCP en este ejemplo es el protocolo Financial Information Exchange (FIX). En la implementación no XML, el protocolo FIX permite que dos hosts que se comunican a través de una red intercambien información empresarial o relacionada con el comercio como una lista de pares nombre-valor (denominados “campos FIX”). El formato del campo es <tag>=<value><delimiter>. Este formato tradicional de etiqueta-valor hace que el protocolo FIX sea ideal para este caso de uso.

La etiqueta de un campo FIX es un identificador numérico que indica el significado del campo. En el ejemplo;

La etiqueta 35 indica el tipo de mensaje.
El valor después del signo igual contiene un significado específico para la etiqueta dada y está asociado con un tipo de datos. El valor A para la etiqueta 35 indica que el mensaje es un mensaje de inicio de sesión.
El delimitador es el carácter ASCII “Start of Header” (SOH) no imprimible (0x01), que es el símbolo de intercalación (^).
A cada campo también se le asigna un nombre. El campo con etiqueta 35 es el campo MsgType.

A continuación se muestra un ejemplo de un mensaje de inicio de sesión.

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

La elección del tipo de persistencia para una lista de valores de etiquetas como la que se muestra arriba viene determinada por las opciones disponibles para extraer una cadena determinada de la lista. Los métodos de persistencia basados en token requieren que especifique el desplazamiento y la longitud del token que quiere extraer de la carga útil. El protocolo FIX no permite hacerlo, porque el desplazamiento de un campo determinado y la longitud de su valor pueden variar de un mensaje a otro. Esta variación depende del tipo de mensaje, de los campos anteriores y de la longitud de los valores anteriores. También varía según la implementación de una a otra, en función de si se han definido campos personalizados. Tales variaciones hacen que sea imposible predecir el desplazamiento exacto de un campo dado o especificar la longitud del valor que se va a extraer como el token. En este caso, por lo tanto, la persistencia basada en reglas es el tipo de persistencia preferido.

Supongamos que un servidor virtual fixlb1 equilibra la carga de las conexiones TCP a un conjunto de servidores que aloja instancias de una aplicación habilitada para Fix. Desea configurar la persistencia para las conexiones sobre la base del valor del campo SenderCompid, que identifica a la empresa que envía el mensaje. La etiqueta de este campo FIX es 49 (se muestra en el ejemplo de mensaje de inicio de sesión anterior).

Para configurar la persistencia basada en reglas para el servidor virtual de equilibrio de carga, defina el tipo de persistencia del servidor virtual de equilibrio de carga en RULE y configure el parámetro de la regla con una expresión. La expresión debe ser una expresión que extraiga la parte de la carga útil de TCP en la que espera encontrar el campo SenderCompid, mecanografiar la cadena resultante en una lista de nombres y valores basada en los delimitadores y, a continuación, extraiga el valor del campo SenderCompid (etiqueta 49), de la siguiente manera:

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

Nota: Se han utilizado caracteres de barra invertida en la expresión porque se trata de un comando de CLI. Si está usando la utilidad de configuración, no introduzca los caracteres de barra invertida.

Si el cliente envía un mensaje FIX que contiene la lista de nombres y valores del ejemplo del mensaje de inicio de sesión anterior, la expresión extrae el valor INVMGR y el dispositivo NetScaler crea una sesión de persistencia basada en este valor.

El argumento de la función PAYLOAD () puede ser tan grande como considere necesario para incluir el campo SenderCompid en la cadena extraída por la función. Opcionalmente, puede utilizar la función SET_TEXT_MODE (IGNORECASE) si desea que el dispositivo ignore el caso al extraer el valor del campo y la función HASH para crear una sesión de persistencia basada en un hash del valor extraído. La siguiente expresión utiliza las funciones SET_TEXT_MODE (IGNORECASE) y HASH:

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

A continuación se muestran más ejemplos de reglas que puede utilizar para configurar la persistencia de las conexiones FIX ( <tag> sustitúyalas por la etiqueta del campo cuyo valor desee extraer):

Para extraer el valor de cualquier campo FIX de los primeros 300 bytes de la carga útil de TCP, puede utilizar la expresión CLIENT.TCP.PAYLOAD (300) .BEFORE_STR (“^”) .AFTER_STR (“ =”).<tag>
Para extraer una cadena de 20 bytes con un desfase de 80, convertirla en una lista de nombres y valores y, a continuación, extraer el valor del campo que desee, utilice la expresión CLIENT.TCP.PAYLOAD (100) .SUBSTR (80,20) .TYPECAST_NVLIST_T (‘=’, ‘^’) .VALUE (“ “).<tag>
Para extraer los primeros 100 bytes de la carga útil de TCP, convertir la cadena a una lista de nombres y valores y extraer el valor de la tercera aparición del campo que desee, utilice la expresión CLIENT.TCP.PAYLOAD (100) .TYPECAST_NVLIST_T (‘=’, ‘^’) .VALUE (“ “,2).<tag> Nota: Si el segundo argumento que se pasa a la función VALUE () es n, el dispositivo extrae el valor de la (n+1) <sup>th</sup> instancia del campo porque el recuento comienza desde cero ( 0).

A continuación se muestran más ejemplos de reglas que puede utilizar para configurar la persistencia. Solo las expresiones basadas en la carga útil pueden evaluar los datos que se transmiten a través del protocolo FIX. Las otras expresiones son expresiones más generales para configurar la persistencia en función de protocolos de red inferiores.

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 versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Cloud Software Group solo tiene traducción automática. Cloud Software Group no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Cloud Software Group se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Cloud Software Group, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Cloud Software Group no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

Caso de uso 2: Configurar la persistencia basada en reglas basada en un par nombre-valor en un flujo de bytes TCP

August 11, 2023

Contribución de:

August 11, 2023

Contribución de:

Caso de uso 2: Configurar la persistencia basada en reglas basada en un par nombre-valor en un flujo de bytes TCP

En este artículo