Intercambio de información financiera

La codificación de mensajes FIX original se conoce como codificación tagvalue. Cada campo consta de una etiqueta numérica única y un valor. La etiqueta identifica el campo semánticamente. Por lo tanto, los mensajes son autodescriptivos. La codificación tagvalue se basa en caracteres y utiliza códigos ASCII .

8=FIX.4.2|9=65|35=A|49=SERVIDOR|56=CLIENTE|34=177|52=20090107-18:15:16|98=0|108=30|10=062| ^ 5 + 10 + 10 + 7 + 21 + 5 + 7 ^ = 65

FIXML ^{[ 7 ]} es un esquema XML para mensajes FIX. Es semánticamente equivalente a los mensajes codificados con tagvalue, pero aprovecha la tecnología de análisis XML. FIXML se usa comúnmente en aplicaciones de back-office y compensación, más que en operaciones bursátiles.

La codificación binaria simple ^{[ 8 ]} define un formato de transmisión utilizando tipos de datos primitivos propios de los sistemas informáticos. Por lo tanto, la codificación y decodificación de mensajes presenta una latencia mucho menor que los protocolos basados ​​en caracteres, ya que no se requiere traducción para convertir los datos a un formato utilizable por las computadoras. Además de las ventajas en cuanto a latencia, el rendimiento es más determinista, dado que los mensajes SBE están limitados por plantillas y se prefieren elementos de datos de longitud fija. Otra consecuencia es que los campos suelen estar en una posición fija, de modo que los filtros y enrutadores de mensajes no necesitan analizar el mensaje completo para acceder a los campos clave.

SBE fue desarrollado por el Grupo de Trabajo de Alto Rendimiento de FIX para dar soporte a operaciones de alto rendimiento. Se consideró que la codificación Tagvalue ya no era adecuada, puesto que se basa en caracteres en lugar de binarios, y sus campos y mensajes de longitud variable dan como resultado un rendimiento no determinista.

A diferencia de tagvalue y FIXML, un mensaje SBE no es autodescriptivo. Solo se envían datos por la red con una cabecera mínima para identificar la plantilla que controla el mensaje. Los metadatos que describen la estructura del mensaje se intercambian fuera de banda entre los participantes.

La comunidad de negociación FIX publica un esquema XML para los esquemas de mensajes SBE. Un esquema de mensaje puede contener cualquier número de plantillas de mensaje. Una plantilla describe los campos que componen un mensaje. Además, un esquema proporciona una lista de tipos de datos simples y compuestos que pueden ser reutilizados por cualquier número de campos.

Desde una perspectiva práctica, asumiendo una implementación en C/C++ y ajustando el orden de bytes : la mayoría de los tipos no compuestos en el mensaje se asignan directamente al mismo tipo en el lenguaje. Por ejemplo, un entero de 32 bits se asigna a uint32_t, las cadenas fijas se asignan a const char *, los números de punto flotante se asignan a floaty así sucesivamente. Se puede generar un C/C++ structa partir de la definición del esquema. Luego, dado un puntero a un búfer de mensajes, acceder a los campos no compuestos del mensaje equivale a convertirlo a un puntero a una estructura y acceder directamente a los miembros de la estructura.

/* Estructura generada a partir del esquema */ struct Message { ... uint32_t qty ; ... const char * symbol ; ... };void consume_message ( void * incoming_message ) { const struct Message * msg = ( const struct Message * ) incoming_message ; printf ( "Intercambiado %u de %s \n " , msg -> qty , msg -> symbol ); ... }

La comunidad de comercio FIX también ha desarrollado asignaciones estándar entre FIX y otros protocolos de mensajería, entre los que se incluyen:

• Google Protocol Buffers
• ASN.1
• JSON

El protocolo de sesión FIX original no tenía nombre propio, ya que formaba parte de una especificación monolítica que abarcaba tanto la semántica de la capa de aplicación como la codificación de mensajes. Sin embargo, a partir de la versión 5.0 de FIX, la capa de sesión se separó como una especificación independiente con la introducción de FIXT. ^{[ 9 ]} FIXT era prácticamente igual que la capa de sesión original sin nombre de la versión 4.x, pero ofrecía una innovación significativa: proporcionaba un mecanismo para combinar versiones de la capa de aplicación FIX sobre una versión de sesión común. La versión actual de FIXT es la 1.1.

En teoría, FIXT es independiente del protocolo de transporte. Sin embargo, suele emplearse sobre el Protocolo de Control de Transmisión (TCP).

FIXT es un protocolo punto a punto . Garantiza la entrega de mensajes en ambas direcciones. Los mensajes enviados en cada dirección incluyen un número de secuencia en la cabecera. Si se produce un fallo de comunicación, un interlocutor puede solicitar la retransmisión de los mensajes perdidos. La entrega de mensajes se mantiene incluso en caso de desconexión y posterior restablecimiento de la sesión.

Para implementar el establecimiento de sesiones y la entrega garantizada, FIXT y FIX 4.x clásico definen estos tipos de mensajes de sesión:

• Latido del corazón
• Solicitud de prueba
• Reenviar solicitud
• Rechazar
• Reinicio de secuencia
• Cerrar sesión
• Iniciar sesión
• XMLnonFIX

FIXP ^{[ 10 ]} fue desarrollado por el Grupo de Trabajo de Alto Rendimiento de FIX ^{[ 11 ]} para satisfacer las necesidades de la negociación de alto rendimiento. La necesidad principal es la codificación y decodificación de mensajes de baja latencia y el control sobre las garantías de entrega de mensajes.

Para garantizar una baja latencia, se admiten codificaciones de mensajes binarios tanto para la capa de sesión como para los mensajes de la aplicación. El formato de transmisión real se abstrae en la especificación FIXP, por lo que los usuarios pueden seleccionar la codificación FIX que prefieran, siempre que los participantes acuerden un protocolo. En las primeras fases de desarrollo se utilizó la codificación binaria simple.

FIXP cubre casos de uso tanto de punto a punto como de multidifusión con primitivas comunes.

Cuando se establece una sesión punto a punto, los participantes negocian garantías de entrega entre las siguientes opciones:

• Recuperable: entrega de mensajes una sola vez. Si se detectan interrupciones, los mensajes perdidos pueden recuperarse mediante retransmisión.
• Idempotente: entrega como máximo una vez. Si se detectan interrupciones, se notifica al remitente, pero la recuperación queda bajo el control de la aplicación, si es que se realiza.
• Sin secuenciar: no ofrece garantías de entrega. Esta opción es apropiada si las garantías no son necesarias o si la recuperación se proporciona en la capa de aplicación o a través de un canal de comunicación diferente .
• Nota: No se deben enviar mensajes de la aplicación en una sola dirección de la sesión.

Las garantías de entrega pueden ser asimétricas. Por ejemplo, un operador puede introducir órdenes a través de un flujo idempotente, mientras que las ejecuciones se devuelven a través de un flujo recuperable. En mercados volátiles, la demora inherente a la retransmisión suele ser indeseable, lo que conlleva la pérdida de oportunidades o malas operaciones.