Вы находитесь на странице: 1из 13

1

FIX Api Tutorial


http://javarevisited.blogspot.com/2011/01/basics-of-fix-protcol-and-fix-engine.html#ixzz31R5GXTXt
FIX Protocolo Sesin o Admin Mensajes de tutorial

He estado trabajando en el protocolo FIX por casi 5 aos, cuando empec a trabajar en el protocolo FIX
Mir a Internet desde hace algn buen tutorial que podra completar o complementar larga especificacin
del protocolo FIX no haba nada en ese momento as que cuando Yo empec mi blog pens escribir
sobre mi experiencia en el protocolo FIX tan corto, claro y conciso formato tutorial. Ya que me gusta el
tipo de ruegos y preguntas del intercambio de conocimientos tambin he escrito un post de blog
en preguntas de la entrevista de protocolo FIX puede que le resulte interesante.

En FIX tutorial de hoy vamos a echar un vistazo a los mensajes de nivel de sesin de protocolo
FIX. Como ustedes pueden saber todos los mensajes FIX se pueden clasificar en dos categoras
mensajes admin tambin llamados mensajes de nivel de sesin y mensajes de aplicacin que incluyen el
comercio, el comercio de pre y post oficios mensajes. La comprensin de cmo funciona sesin FIX es
muy importante porque hasta que no sepa el nmero de secuencia fundamental de FIX, cmo sesin
FIX se conecta, lo que son la secuencia de mensajes que fluyen entre Engine Fix remitente y el motor
FIX receptor, no ser capaz de identificar rpidamente cualquier problema relacionado con la FIX
protocolo. Especificacin FIX es muy clara acerca de lo que debe arreglar el motor haga en
varias sesiones FIX escenario de conexin / desconexin .

Slo para revisar de acuerdo con el protocolo FIX primero remitente del motor y el motor FIX FIX
receptor se conecta a la otra en el protocolo TCP / IP en especfico IP y el puerto a travs de lnea,
enlace Radianz, red privada virtual (VPN) o va internet arrendado. Aplicacin remitente vez la
conectividad de nivel TCP Socket estableci enva Logon (tag fix 35 = A MsgType = A) con
SenderCompID acordado (tag fix 49) y TargetCompID (tag fix 56). Motor FIX receptor recibe este
mensaje y la autenticacin de cliente remitente FIX Engine basado en SenderCompID (tag fix 49) y
TargetCompID (tag fix 56), si el cliente se autentica satisfactoriamente, entonces el motor fix receptor
responde con el mensaje mismo enva Logon (fix tag = 35 A) y la conexin se establece correctamente y
luego ambos motores FIX enviar mensajes de latido (etiqueta fix 35 = 0) en el intervalo de pulsacin
especificada para mantener viva la conexin. En el caso del motor FIX receptor no es capaz de
autenticar el cliente va a enviar un mensaje Logout (tag fix 35 = 5) y la conexin se terminar aunque
conexin de socket todava estar all. Motor FIX receptor tambin puede enviar un mensaje Cerrar
sesin (tag fix 35 = 5) si recibe arreglar mensaje con nmero de secuencia inferior al que se esperaba.
-> Ahora vamos a ver cada uno de los mensajes de nivel de sesin o de administrador en el pequeo
detalle. Siempre se puede hacer referencia FIX documento de especificacin de protocolo y que se
recomienda tambin para obtener la descripcin completa de cada uno de estos mensajes. Cierto nivel
de sesin importante o mensajes administrativos especificados en la especificacin FIX son los
siguientes:

Heartbeat :
mensajes de latido se denotan por MsgType = 0 en el intercambio de informacin financiera (FIX)
Protocolo. Tanto Sesin FIX Iniciador y Sesin FIX Aceptador enva entre s mensajes de latido para
mantener sesin FIX viva en un intervalo definido por Intervalo de latidos que suele ser de 30 o 60
segundos. Si ve el mensaje Heartbeat (tag FIX 35 = 0) en el archivo de registro FIX Engine significa que
su sesin FIX est en marcha y conectado.

2

Inicio de sesin:
el mensaje de inicio de sesin es denotada por la etiqueta FIX 35 = A y se utiliza para enviar el mensaje
de inicio de sesin del iniciador de FIX. De acuerdo con el Protocolo FIX vez qued establecida la
conexin TCP entre FIX Iniciador y FIX del aceptador, iniciador FIX enva el mensaje de inicio de sesin
(tag = 35 A) con pre acordado SenderCompID (etiqueta 49) y TargetCompID (etiqueta 56) y con la
secuencia No (tag FIX 34) esperando por el aceptador de FIX. Cuando Aceptador FIX recibe la solicitud
de inicio de sesin (MsgType = A) se autentique sesin FIX basado en compid especifica en arreglo del
mensaje y Secuencia n y contestar de nuevo, ya sea con mensaje (tag = 35 A) en base a resultado Salir
mensaje (etiqueta 35 = 5) o de inicio de sesin de autenticacin.
Solicitud de reenvo de
solicitud de reenvo (tag FIX 35 = 2 MsgType = 2) se utiliza para preguntar de retransmisin o
repeticin de mensajes perdidos durante la transmisin o debido al nmero de secuencia
incorrecta. Normalmente es enviado por el FIX Engine que est recibiendo un mensaje para iniciar la
retransmisin de mensajes. FIX Engine utiliza Solicitud de reenvo (etiqueta 35 = 2) si se detecta una
diferencia de nmero de secuencia o si FIX Engine de recibir solicitud perdi su mensaje o como parte
del proceso de inicializacin para que el nmero de secuencia en sincrona.
Solicitud de reenvo (tag FIX 35 = 2 MsgType = 2) se puede utilizar para solicitar un nico mensaje FIX,
una serie de mensajes FIX o todos los mensajes FIX posteriores a un mensaje FIX particular.
Vale la pena sealar que el envo de FIX Engine posible que desee considerar el tipo de mensaje que
volver a enviar mensajes; por ejemplo, si un nuevo orden es en la serie del reenvo y un perodo de
tiempo significativo se ha pasado desde que fue enviado originalmente, el motor FIX remitente puede no
deseen retransmitir la orden ya la dinmica del mercado un precio etc podra haber sido cambiado
tambin puede dar lugar a Para rancio rechazan que se realiza por sistemas de gestin de pedidos
(OMS). (El reinicio de secuencia (tag FIX 35 = 4 o MsgType = 4) Tambin llamado como Gap Rellene se
utiliza para omitir mensajes FIX que un motor FIX remitente no quiere que vuelva a enviar.)
Es obligatorio que el arreglo de recepcin de mensajes de proceso del motor en orden secuencial, por
ejemplo, si el mensaje FIX nmero 11 es olvidada y 12-13 recibida, la solicitud debe ignorar 12 y 13 y
pedir un reenvo de 11 a 13, o 11 -0 ( 0 denota el infinito). Segundo enfoque se recomienda
fuertemente para recuperarse de condiciones fuera de secuencia, ya que permite una recuperacin ms
rpida en presencia de ciertas condiciones de carrera cuando ambos lados de FIX motores estn
intentando al mismo tiempo para recuperar un salto de nmero de secuencia.

Solicitud de prueba
en el intercambio de informacin financiera tambin llamado FIX Protocol Test Request es denotada por
la etiqueta FIX 35 = 1 o MsgType = 1. Prueba de Solicitud FIX mensaje es utilizado por FIX Engine a las
fuerzas de un latido del corazn del motor FIX contrario. La solicitud de prueba (etiqueta FIX 35 = 1)
Mensaje comprueba los nmeros de secuencia o verifica estado de la lnea de comunicacin. El motor
FIX contrario responde a la solicitud de prueba Test Request (tag FIX 35 = 1) con un latido del corazn
(etiqueta FIX 35 = 0) que contiene el TestReqID (tag FIX 112).
La etiqueta FIX TestReqID 112) verifica que el motor FIX contraparte est generando el latido del
corazn (etiqueta FIX 35 = 0) como resultado de la solicitud de prueba (etiqueta FIX 35 = 1) y no es un
tiempo de espera normal. El motor FIX opuesta incluye el TestReqID (tag FIX 112) en el latido del
corazn resultante (tag FIX 35 = 0). Cualquier cadena se puede utilizar como el latido del corazn
(etiqueta FIX 35 = 0) (Algunos motores fix generalmente utiliza una cadena de fecha y hora).
Nivel Sesin Rechazar
En la informacin financiera protocolo de intercambio (FIX) a nivel de sesin Rechazar o Rechazar
mensaje es denotada por la etiqueta FIX 35 = 3 o MsgType = 3. Nivel de la sesin Rechazar es utilizado
3

por el motor FIX cuando se recibe un mensaje de correccin, pero no se puede procesar adecuadamente
debido a una violacin de las reglas a nivel de sesin como se especifica en el documento Especificacin
del protocolo FIX. Como un ejemplo de motor FIX utilizar a nivel de sesin Rechazar o rechazarla
recibe un mensaje FIX con los datos bsicos no vlidos (por ejemplo MsgType = 35 $), que supera con
xito de-codificacin, la suma de comprobacin (tag FIX 10) y BodyLength (tag FIX 9) comprueba
. Como una regla de mensajes FIX deben remitirse a la solicitud de negociacin de los rechazos de nivel
empresarial siempre que sea posible.
Mensajes rechazados deben ser registrados en el archivo de registro y el nmero de secuencia de
entrada deben ser incrementados por FIX Engine.
Vale la pena sealar que la recepcin de FIX Engine debe ignorar cualquier mensaje FIX lo cual es
incorrecto, no se puede analizar o no una comprobacin de integridad de los datos. Procesamiento del
siguiente mensaje FIX vlida har que la deteccin de una falta de coincidencia de nmero de secuencia
y una solicitud de reenvo (tag FIX 35 = 2 MsgType = 2), se genera y se pasa a FIX contraparte Engine.
Generacin y recepcin de un mensaje de rechazo (tag FIX 3) indica un error grave que puede ser el
resultado de una lgica defectuosa, ya sea en el envo o recepcin de motor FIX.
Si el motor FIX enviar decide retransmitir el mensaje rechazado, se debe asignar un nuevo nmero de
secuencia (tag FIX 34) y se enva con PossResend (tag FIX 97) = Y.
Su recomendado para describir la causa del rechazo en el texto de etiqueta fijo (FIX Tag 58) que puede
ser utilizado por la recepcin de motor FIX o desarrollador para identificar la causa real del nivel de la
sesin de rechazo (por ejemplo, Etiqueta de precio no se encuentra en el lmite de la Orden).
A continuacin se presentan algunos escenarios donde a nivel de sesin Reject (FIX Tag 3 o MsgType =
3) se puede utilizar.
Compid problema : o FIX Iniciador o FIX Acceptor est enviando SenderCompID incorrecto (etiqueta
49) y TargetCompID (etiqueta 56).
MsgType no vlida : o iniciador FIX o FIX Acceptor est enviando MsgType distinta a la especificada en
FIX Especificacin para esa particular FIX Versin ejemplo FIX4.2
Formato de datos incorrecto para el valor : Si una etiqueta de revisin tiene un tipo de datos
timestamp y el motor FIX es el envo de otro tipo de datos
Etiqueta requerida falta : O FIX Iniciador o FIX Aceptador no est enviando tag FIX obligatoria en un
determinado mensaje FIX eg Precio (tag FIX 44) desaparecidos en un mensaje NewOrderSingle
(MsgType = D) con OrdType = 2, es decir Limit Order.
Nmero de etiqueta no vlido: cualquier iniciador FIX o FIX Acceptor est enviando cualquier etiqueta
distinta a la especificada en FIX Especificacin para esa particular FIX Versin ejemplo FIX4.2
Etiqueta no definida para este tipo de mensaje : Ninguno de iniciador o FIX FIX Acceptor est
enviando cualquier etiqueta distinta a la especificada en la especificacin FIX para ese tipo de mensaje
en particular por ejemplo, envo de TestReqID en el mensaje de cierre de sesin.
Tag Indefinido: En caso de que alguno de motor FIX remitente est enviando etiqueta personalizada y
que no est configurado o apoyada por vengarse del motor del arreglo.
Tag especifica sin un valor: por ejemplo, 35 = y no hay ningn valor para esa etiqueta solucin
particular. Su motor de correccin no un mensaje punto vlido y as recibir la rechazar.
4

Sequence Reset
Restablecer Secuencia tambin llamado como Gap llenar mensajes es denotada por la etiqueta FIX 35 =
4 o FIX MsgType 35 = 4. Se utiliza en respuesta a la Solicitud de reenvo (tag FIX 35 = 2 MsgType = 2)
mediante el envo de motor FIX para restablecer el nmero de secuencia de entrada en el motor FIX lado
opuesto. Mensaje Sequence Reset (tag fix 35 = 4) funciona en dos modos diferentes de uno en el que
GapFillFlag (tag FIX 123) es 'Y' tambin llamado Sequence Reset - llenar el espacio y el segundo modo
en el que GapFillFlag (tag FIX 123) es 'N' o no presentar tambin llamado Restablecer Secuencia - Modo
Reset. Segn especificacin del protocolo FIX "Restaurar las secuencias (tag fix 35 = 4)-Reset" modo
SOLO debe usarse para recuperarse de una situacin de desastre que no se puede recuperar de otra
manera por el modo de "Gap relleno".
El reinicio de secuencia o mensaje GapFill (tag fix 35 = 4) pueden ser tiles en las siguientes
circunstancias:
1. Durante el procesamiento de solicitud de reenvo (tag FIX 35 = 2 MsgType = 2) el envo de FIX
Engine puede optar por no enviar un mensaje (por ejemplo, una orden de viejo). El restablecimiento de la
secuencia (tag fix 35 = 4) - Gap Fill se puede utilizar para llenar el lugar de ese mensaje.
2. Mientras (tag FIX 35 = 2 MsgType = 2) Solicitud de procesamiento Reenviar enviar FIX Engine
puede optar por no enviar un mensaje, si todos los mensajes son slo los mensajes de nivel
administrativo o de sesin, porque no hay ningn punto en enviarlos de nuevo en ese caso Restablecer
tambin la secuencia (tag fix 35 = 4) - Gap relleno se utiliza para llenar la brecha mensaje o secuencia.
Salir
mensaje Logout es denotada por la etiqueta FIX 35 = 5 o MsgType = 5 en la especificacin del protocolo
FIX y se utiliza para terminar o cerrar cualquier sesin FIX. En el caso del motor FIX receptor no es
capaz de autenticar el cliente va a enviar un mensaje Logout (tag fix 35 = 5) y la conexin se terminar
aunque conexin de socket todava estar all. Motor FIX receptor tambin puede enviar mensaje Logout
(tag fix 35 = 5) si recibe arreglar mensaje con nmero de secuencia inferior al que se esperaba. El
mensaje Logout (tag fix 35 = 5) se utiliza para terminar una sesin FIX. La terminacin o desconexin sin
el intercambio de mensaje Logout (tag fix 35 = 5) Los mensajes se tratan una condicin anormal.
El intercambio de mensaje Logout (tag fix 35 = 5) antes de realmente terminar o cerrar la sesin permite
que el motor FIX iniciador para realizar cualquier tipo de secuencia de reinicio (tag fix 35 = 4) o Gap
operaciones que sean necesarias o resulten necesarias llenar. Iniciador Cerrar sesin tambin debe
esperar a que el motor FIX opuesta a responder con un mensaje que confirma Salir (tag fix 35 = 5) se
puede terminar la sesin en caso de que el motor FIX remoto no responde en un plazo de tiempo
especificado.








5

Fundamentos del protocolo FIX y FIX Engine
Protocolo FIX es un protocolo de valor de la variable en el que cada campo tiene un nombre de etiqueta
nica y significa algo eg Precio (etiqueta 44) denota el precio de un acciones particulares, OrderQty
denota cantidad de orden.
FIX protocolo especificar diferentes tipos de mensajes para distintos fines comerciales por ejemplo para
el envo de una orden de intercambiar solan mensaje NewOrderSingle (MsgType = 35) o para el envo
de una Cancel para intercambiar solan mensaje CancelOrder (MsgType = F). MsgType (etiqueta 35) y
que el mensaje para todos los efectos del comercio ciclo de vida e .. g tienen pre el mensaje comercial
(por ejemplo, Noticias, Peticin de Inters), mensaje del comercio (NewOrderSingle,
OrderCancelReplaceRequest, OrderCancelRequest) y el mensaje comercial posterior por ejemplo,
mensajes de Asignacin ( ).
Para entender estos mensajes FIX cliente y agente de bolsa, los dos de las partes involucradas en el
comercio tiene un pedazo de software llamado FIX Engine.
Hay muchos motores FIX comercial disponible que se utiliza en la industria por ejemplo Cameron FIX
Engine, Appia etc de NYFIX mensajes en protocolo FIX se pueden clasificar en primer mensaje de nivel
de la sesin dos de tipo tambin llamado admin mensajes y mensajes de segundo nivel de la aplicacin.
Mensajes de nivel de sesin es usado para establecer una sesin FIX entre dos mensajes de motores
FIX y de aplicacin son los mensajes que est destinado para algn propsito e .. g NewOrderSingle
mensaje que se utiliza para enviar la orden va FIX. MsgType (etiqueta 35) es una etiqueta importante
en FIX protocolo que se utiliza para identificar de forma nica un mensaje FIX.
Cada mensaje individual en protocolo FIX debe haber correspondiente MsgType otro modo FIX motor
rechazar aquellos mensajes diciendo que no es un mensaje FIX vlida.
Segn el protocolo FIX conexin entre dos motores FIX se llama sesin FIX y cada sesin FIX ha
acordado previamente host / puerto y borrador id. Puesto que un solo motor FIX se puede utilizar para
mltiples clientes de servidor en el lado broker cada cliente se identifica de forma nica por la
combinacin de IP, el puerto y hay IDs Comp, IDs Comp son combinacin de SenderCompID y
TargetCompID que son dos etiquetas separadas en el protocolo FIX. Una vez FIX Sesin establecida
con empresa cliente puede enviar rdenes a travs de FIX y el corredor luego enviarlo intercambiar para
su ejecucin.
Voy a tratar de mantenerlo actualizado con la informacin relevante, por favor preguntar si tiene alguna
pregunta, duda, etc aprendizaje feliz y bienvenidos al mundo FIX protocolo .









6

Grupos que se repiten en el Protocolo FIX
En este tutorial protocolo FIX que voy a compartir mi experiencia con FIX repetir bloque o un
grupo. Este es el concepto fundamental del protocolo FIX y se utiliza para transportar datos que
se repiten. La correcta comprensin de los diversos grupos de FIX repitiendo disponibles, por
ejemplo, el bloque PartyID,
Asignacin de grupo de repeticin, etc es muy importante para la escritura de software FIX
basado. En este tutorial FIX voy a explicar acerca de cmo analizar un grupo de repeticin,
cmo preparar un grupo de repeticin y la forma de entender un grupo de repeticin. Si usted
quiere saber ms acerca de los conceptos bsicos en el protocolo FIX, puede que encuentre
mi Protocolo FIX tutorial interesante.
-> En protocolo FIX cuando un grupo de etiquetas aparece tiempo mltiple en un mensaje FIX que se
denominan grupo de repeticin. Estos son esenciales para indicar la repeticin de entidad en un mensaje
FIX por ejemplo tomar un ejemplo de grupo de repeticin PartyID que se utiliza para denotar el comercio
Parte el ID (India, Corea, Taiwn, China, etc) del mercado.
Voy a mantener la discusin en torno a este grupo de repeticin en particular para ilustrar diferentes
puntos. grupo de repeticin PartyID se hace las siguientes etiquetas:
453 NoPartyIDs
448 PartyID
447 PartyIDSource
452 PartyRole
Cada grupo de repeticin comienza con una etiqueta concreta, que especifica cuntas etiquetas se
repiten estn presentes dentro de la repeticin grupo por ejemplo, en caso de PartyID repitiendo
NoPartyIDs grupo (etiqueta 453) denota el nmero de identificacin del banquete entradas que se repiten
estn presentes en el mensaje, por ejemplo, NoPartyIDs = 2 indicarn dos partes estn presentes que
hay dos grupos de repeticin se encuentran presentes en el mensaje tambin como etiqueta debe venir
inmediatamente antes del inicio de la repeticin de las entradas de grupo, por ejemplo, en el caso de
NoPartyIDs bloque PartyID debe venir antes de repetir las etiquetas por ejemplo PartyRole
Segn FIX protocolo de cada entrada de un grupo de repeticin debe tener un campo especfico que a
su vez identifica el comienzo de un nuevo grupo entrada. Este campo debe tener lugar en el mensaje
crudo antes de cualquier otra etiqueta de una entrada de grupo de repeticin nica. En otras palabras,
estos campos separar las entradas de grupo de repeticin entre s. . En caso de PartyID bloque sede tag
448 PartyID que es la primera etiqueta de grupo de repeticin y marque inicio de un grupo y al final de
otra.
Aspectos importantes de FIX repitiendo la estructura del grupo: mensajes FIX bien definidos asumen
todas las etiquetas de un grupo de repeticin venir en una determinada el orden y la aparicin de
cualquier etiqueta que no pertenece al grupo de repeticin (de acuerdo con la especificacin FIX) indica
automticamente el final de la grupo de repeticin.
Apariencia ms posterior de las etiquetas del grupo de repeticin no est permitido por el estndar
FIX. Repeticin de grupo dentro de grupo de repeticin Segn especificacin del protocolo FIX, es
posible que los grupos aparezcan en el interior de otro grupo de repeticin en este caso la repeticin de
todas las entradas del grupo de repeticin interno pertenecen a la nica entrada del grupo de repeticin
externa, que se conoce comnmente como SubIDs por ejemplo, en el bloque instancia PartyID
podramos tener otro grupo de repeticin llamada NoOfSubIDs que se hace de SubIDType y SubID.
7

El nmero de instancias de grupo de repeticin debe coincidir con el valor especificado por Nmero
etiquetas NoPartyIDs ejemplo, de lo contrario FIX motor no pueda entender el mensaje FIX rechazar
mensajes FIX como mal formado.
Parsing del grupo de repeticin
Al analizar un grupo de repeticin debemos tener en cuenta dos importantes tag
1) tag Number (NoXXX) por ejemplo, para comprobar NoPartyIDs el nmero de grupos que se repiten
estn presentes
2) Encontrar la etiqueta de lder que marca de inicio y final del grupo de repeticin. En general todos los
grupos de repeticin tiene una etiqueta en particular que se utiliza como marcador de etiqueta, pero en la
mayora de los casos siguen el orden especificado en la especificacin FIX. Pero no hay una lnea dura
en que en la mayora de los casos el uso de mensajes FIX analizador de etiqueta Nmero de identificar
el nmero de grupo de repeticin y luego suelen utilizar la ocurrencia de la primera etiqueta
documentada del grupo de repeticin para determinar inicio y final del grupo de repeticin.
Formateo de una mensaje FIX con grupo de repeticin
Es bueno seguir el orden de las etiquetas especificadas en la especificacin FIX mensaje durante la
construccin de un grupo de repeticin que permite analizador FIX usar la primera etiqueta especificada
en los documentos de FIX como etiqueta de marcador de inicio y final del grupo de repeticin.
En Resumen
- Cuando el grupo de etiquetas aparece varias veces en un mensaje FIX los llamamos grupo de
repeticin.
- etiqueta de nmero es una etiqueta que lleva el que se especifica el nmero de grupos que se repiten
estn presentes en los mensajes FIX ejemplo NoPartyIDs
- Primera etiqueta especificada en la especificacin de mensajes FIX se utiliza como etiqueta de
marcador para marcar de inicio y final de un mensaje FIX.
- No de grupos de repeticin debe coincidir con el nmero indicado de No # # # tag ejemplo
NoPartyIDs
- Siga el orden de las etiquetas especificadas en la especificacin FIX mensaje durante la construccin
un grupo de repeticin
- un grupo de repeticin puede contener otro grupo de repeticin dentro de ella.
- PartyID bloques se introducen en FIX 4.3 por lo que no funcionar en versiones anteriores del
protocolo FIX.









8

Reproduccin de mensajes en el protocolo FIX
En Protocolo FIX dos motores FIX se comunican entre s mediante mensajes FIX y cada
mensajes FIX se asignar con el nmero de secuencia nico denotada por la etiqueta 34.
Aparentemente cada motor FIX tiene dos nmeros de secuencia Nmero de secuencia
entrante (que FIX motor est a la espera del marcador del partido) y el nmero de secuencia
de salida (qu motor FIX est enviando para contrarrestar parte). Estos nmeros de secuencia
a lo largo de las normas especificadas en las especificaciones tcnicas del protocolo FIX
garantiza que ningn motor FIX debe perder ningn mensaje FIX en el caso de alguna
desconexin.
En este Tutorial Protocolo FIX vamos a discutir algunos de los escenarios donde desconexin
entre dos motor FIX se produce y cmo se recuperan de esa
situacin. Normalmente desconectar y volver a conectar puede provocar la repeticin de
los mensajes que se requieren de cualquiera de las partes por ejemplo, el cliente o el agente
basado en que tiene mayor nmero de secuencia.


Este Tutorial Protocolo FIX es una continuacin de mi tutorial anterior FIX Protocolo Sesin o
mensajes de admin tutoria ly Diferencia entre FIX 4.2 vs 4.4 FIX en la conectividad FIX .

Ahora veamos algunos escenarios donde puede ocurrir la repeticin de mensajes FIX:

1) Si Final del da (EOD) no se ha ejecutado por cualquiera de motor FIX :
Cada sesin FIX tiene alguna EOD o fin de los tiempos das normalmente algn tiempo
despus del cierre del mercado, en la que se restablecen nmero de secuencia tanto entrantes
como salientes a 1/1 y se inicia el da fresco.
-> Si por casualidad FIX EOD no sucede a cada lado entonces tanto el nmero de secuencia
de entrada y salida no se restablece a 1/1 de ese lado y ambos motores FIX estar fuera de
secuencia y cuando al da siguiente cuando empiezan conectar entre s de inicio de sesin no
tendr xito, entonces el motor FIX cliente mantiene enviar el mensaje de inicio de sesin cada
vez que el aumento de nmero de secuencia hasta que el agente (aceptante) fijar el motor
acepta la conexin. una vez que el motor fix broker aceptar la conexin va a contestar de
nuevo con su nmero de secuencia de salida que no es 1 y podra ser 400 segn el nmero de
mensaje de ayer.

Dado que el motor fix cliente nmero de secuencia de entrada sigue siendo 1, sera enviar una peticin
de reenvo de mensajes de 1 a 400 y el corredor se volver a reproducir los mensajes. Estos mensajes
de repeticin pueden ser los oficios de ayer. As que para evitar tal escenario todo lo posible para tener
su trabajo de Fin de Da se ejecuta en el tiempo acordado entre el agente y el cliente y usted debe tener
una alerta cuando fall. si usted fija motor proporciona apoyos para el cambio manual de los nmero de
secuencia a continuacin, usted puede ajustar manualmente esos tambin. Motores FIX Normalmente
comerciales como NYFIX Appia apoya el funcionamiento del EOD en proceso en s mismo, pero si su
motor FIX no soporta EOD entonces usted podra una configuracin Autosys o cron job unix para
eliminar los archivos de persistencia relacionados con el nmero de secuencia de manera que cuando el
proceso se acerca de nuevo el prximo da crear nuevo archivo persistencia con nmero de secuencia
1/1.

2) Debido a la red publica conexin entre motor FIX remitente y receptor FIX Engine se ha perdido y
despus de problema resuelto cuando tratan de reconectarse que podra estar fuera de secuencia.

3) remitente o receptor FIX Engine baja debido a Host Fracaso , En este evento tambin cuando
tratan de volver a conectar entre s la validacin de nmero de secuencia se har y reproduccin
9

suceder si alguna de haber cado ningn mensaje.

4) Debido al reinicio de cualquiera de remitente o Receptor Motor FIX.

Tambin vale la pena sealar que para manejar la reproduccin de mensajes FIX FIX correctamente
protocolo proporciona dos etiqueta especial PossDup (tag fix 43) y PossResend (etiqueta 97), que
sugieren que el motor del arreglo de recepcin que estos mensaje ha sido enviado con
anterioridad. usted puede leer ms acerca de Diferencia entre PossDup y PossResed en el Protocolo
FIX aqu.


Diferencia entre el nivel de sesin de rechazo y el mensaje de negocios rechazan
En el protocolo FIX hay mltiples maneras de rechazar el mensaje algunos de ellos estn
utilizando un Informe de Ejecucin (MsgType = 8) y ExecType = 8 para rechazar un mensaje
FIX si no puede ser aceptable por intercambio por ejemplo, orden de envo de un vnculo de
intercambio y entre corredor y el intercambio est abajo. Otra manera de rechazar el mensaje
es OrderCancelReject (FIX MsgType = 9) que se utiliza para rechazar la enmienda (MsgType
mensaje OrderCancelReplace FIX 35 = G) y cancelar (OrderCancelRequest MsgType FIX = F)
mensajes si no es posible modificar o cancelar el mensaje original eg Envo Cancelar solicitud
para una orden ya est lleno, sern rechazadas por el mensaje OrderCancelReject en el
protocolo FIX.


En este tutorial FIX (eso es lo que he llamado :) tal vez no sea un tutorial de pleno derecho,
pero simplemente un artculo basado en mi experiencia, que te da idea bsica acerca de
algunas funciones disponibles en el protocolo FIX y complementar su concepto durante la
lectura larga pero detallada especificacin del protocolo FIX) vamos a hablar de otras dos
maneras o rechazar mensajes FIX, stas rechazan el mensaje de error representan ms grave
que dos anteriores y se nombran como Nivel Sesin Rechazar (MsgType FIX 35 = 3) y
Business Message Reject (35 = j). Si quieres saber ms sobre mis tutoriales protocolo FIX
consulte este enlace Protocolo FIX tutorial .

Tanto a nivel de sesin Rechazar (MsgType FIX 35 = 3) y Business Message Reject (MsgType
FIX 35 = j) se utiliza para rechazar mensajes FIX entrante.
Sesin nivel Rechazar (MsgType FIX 35 = 3) mensaje debe ser utilizado cuando el mensaje
entrante no se puede analizar correctamente debido a violacin de las reglas a nivel de
sesin. por ejemplo a nivel de sesin Rechazar (FIX MsgType 35 = 3) se debe utilizar para
rechazar un mensaje entrante FIX con los datos bsicos vlidos como MsgType desconocido
(por ejemplo, 35 MsgType = 99) que pasa con xito de-codificacin, la suma de comprobacin
(tag FIX 10) y BodyLength (etiqueta FIX 9) cheques. Segn lo recomendado por el Protocolo
FIX siempre debemos tratar de enviar mensajes FIX para la aplicacin comercial para la
aplicacin o nivel de negocio rechazos.

Siempre debemos iniciar tanto a nivel de sesin Rechazar (MsgType FIX 35 = 3) y Business
Message Reject (FIX MsgType = 35 j) en el archivo de registro FIX Engine para que de apoyo
al comercio lo sabe y informar al cliente o corredor acerca tambin de nmero de secuencia se
debe aumentar como resultado de la sesin o de nivel empresarial rechazar. Nivel de la sesin
Rechazar (FIX MsgType 35 = 3) indica un error grave que se debe a buggy o lgica defectuosa,
ya sea en el motor FIX enviar o recibir por lo que el mensaje de error en la regla de nivel de
sesin por ejemplo, la suma de comprobacin o de la longitud del cuerpo a nivel de sesin
10

rechazar debe ser preferencia, a nivel de negocios rechazan mientras que el negocio de
mensajes de rechazo (MsgType FIX 35 = j) se debe utilizar para rechazar un mensaje de nivel
de aplicacin, que pasa todas las normas de nivel de sesin y no puede ser rechazado por
cualquier otro medio.
-> Mensaje de Empresas Rechazar (MsgType FIX 35 = j) se puede utilizar en el siguiente escenario:
1) cuenta no asignada correctamente en el lado corredor.
2) Desconocido ID
3) Vlido pero sin soporte de mensajes de tipo
4) Desconocido seguridad
5) Vlido pero desconocido . tipo de mensaje
6) Algunas de campo condicional requerido no est presente en el mensaje FIX entrante.

Nivel de sesin Rechazar (FIX MsgType 35 = 3) se puede utilizar en los siguientes escenarios.
compid problema : o FIX Iniciador o FIX Acceptor est enviando incorrecta SenderCompID (tag 49) y
TargetCompID (etiqueta 50).
invlida MsgType : o iniciador o FIX FIX Acceptor est enviando MsgType distinta a la especificada en
FIX Especificacin para que FIX Versin ejemplo FIX4.2 particular,
formato de datos incorrecto para el valor : Si una etiqueta de revisin tiene un tipo de datos motor
Timestamp y FIX es el envo de otro tipo de datos
etiqueta requerida falta: O FIX Iniciador o FIX Aceptador no est enviando tag FIX obligatoria en un
determinado mensaje FIX eg Precio (tag FIX 44) desaparecidos en un mensaje NewOrderSingle
(MsgType = D) con OrdType = 2 es decir, orden de lmite.
nmero de etiqueta no vlida : o iniciador o FIX FIX Acceptor est enviando cualquier etiqueta distinta
a la especificada en FIX Especificacin para esa particular FIX Versin ejemplo FIX4.2
Etiqueta no definida para este tipo de mensaje : o iniciador FIX o FIX aceptor es el envo de cualquier
etiqueta distinta a la especificada en la especificacin FIX para ese tipo de mensaje en particular por
ejemplo, envo de TestReqID en el mensaje de cierre de sesin.
Tag Indefinido : En caso de que alguno de motor FIX remitente est enviando etiqueta personalizada y
que no est configurado o apoyada por vengarse del motor del arreglo.
Tag especificado sin un valor : por ejemplo, 35 = y no hay ningn valor para esa etiqueta solucin
particular. No es un mensaje de punto vlido y as recibir el motor fix lo rechazarn. Tambin puede
comprobar los mensajes de nivel de sesin en el protocolo FIX para aprender ms acerca de Sesiones
del protocolo FIX. tambin he documentado mi discusin en mi tutorial protocolo FIX serie, por favor
consulte ms informacin sobre las diferentes reas de protocolo FIX y conectividad FIX por ejemplo la
gestin de sesin FIX , gestin de aplicaciones FIX o preguntas de la entrevista de FIX .



Diferencia entre FIX 4.2 vs 4.4 FIX en la conectividad FIX
11

Diferencia entre FIX 4.2 vs 4.4 FIX en la conectividad FIX

Protocolo FIX ha evolucionado con el tiempo; es ahora ms de una dcada que ha comenzado por
Fidelity y Salomn Brothers. FIX conectividad es la solucin existe conectividad ms popular para el
comercio si sus acciones, futuros, opciones o de renta fija o incluso cambio de divisas (FX). Protocolo
FIX ha dominado el mercado y llegar a ser como solucin estndar para cualquier mercado o broker que
est tratando de desarrollar la conectividad con el mercado en un corto perodo de tiempo debido a la
complejidad de api nativo de Exchange y la falta de compatibilidad con el protocolo FIX venir como
prctico.
Desarrollar la conectividad de arreglo que necesite llegar a un acuerdo sobre la cual la versin del
protocolo FIX vas a seguir, ya que muchos de versin del protocolo fix existe por ejemplo FIX4.0, FIX4.1,
FIX4.2 y FIX4.4 versin an ms reciente estn disponibles, pero ms firme usar FIX 4.2, ya que la
solucin preferida conectividad FIX o se puede decir versin todava ms utilizado es FIX 4.2, muchas
empresas, los clientes, los fondos de cobertura, fondos de pensiones todava lo utilizan para el comercio
en lnea, pero incluso despus del lanzamiento de la versin ms adelantado que todava sigue siendo el
popular. En FIX lado de avance de 4,4 es conseguir popularidad.
En esta breve discusin que estoy destacando algunas de las diferencias entre FIX 4.2 y FIX 4.4 . Dos
versiones ms populares del protocolo FIX puede comprobar la especificacin FIX para ms detalles y
alguna otra diferencia que sale. Especificacin FIX estn disponibles en http://www.fixprotocol.org se
puede descargar la versin pdf de estas especificaciones y puede mirar antes de desarrollar su
conectividad FIX.
Hay muchas diferencias entre estas dos versiones de protocolo de revisin, algunos de ellos estoy
destacando aqu.
1) Hubo etiqueta llamada ExecTransType (etiqueta 20), que estaba all en FIX 4.2 y ahora se fusionaron
para ExecType etiqueta 150 en FIX4.4, esta etiqueta se utiliza para definir la naturaleza de la ejecucin
recibi del cambio o corredor.
2) Sustituido el uso del QuantityType () campo de etiqueta 465 con nueva QtyType (etiqueta 854), que
contiene un conjunto re-organized/consolidated de valores.
3) Eliminado diversos campos relacionados Instrucciones de liquidacin.
4) Alta "Cita Respuesta" a la lista de mensajes para los que Quote Status Report mensaje es la
respuesta adecuada.
El establecimiento de la conectividad FIX es difcil si se trata de etiquetas de revisin personalizada,
stas son las etiquetas que no estn definidos por el protocolo FIX, pero utilizado por muchas empresas
o entre el cliente y el agente para llevar un poco de informacin extra que se acuerde de eso. Protocolo
FIX permite definir etiquetas FIX personalizado para su conectividad FIX hasta que, ya menos que no
estn en conflicto con cualquier otra etiqueta FIX. Por lo general las empresas utilizan etiquetas o por
encima de 10 000 5000 para definir ste Etiquetas FIX personalizado.
Hay muchos otros cambios que estn disponibles en las notas de la versin de FIX
4.4 http://www.fixprotocol.org , voy a aadir un poco ms de lo llego a saber que se utiliza en el comercio
de da con ms frecuencia.



12

Diferencia entre FIX 4.2 vs 4.4 FIX en la conectividad FIX

Protocolo FIX ha evolucionado con el tiempo; es ahora ms de una dcada que ha comenzado por
Fidelity y Salomn Brothers. FIX conectividad es la solucin existe conectividad ms popular para el
comercio si sus acciones, futuros, opciones o de renta fija o incluso cambio de divisas (FX). Protocolo
FIX ha dominado el mercado y llegar a ser como solucin estndar para cualquier mercado o broker que
est tratando de desarrollar la conectividad con el mercado en un corto perodo de tiempo debido a la
complejidad de api nativo de Exchange y la falta de compatibilidad con el protocolo FIX venir como
prctico.
Desarrollar la conectividad de arreglo que necesite llegar a un acuerdo sobre la cual la versin del
protocolo FIX vas a seguir, ya que muchos de versin del protocolo fix existe por ejemplo FIX4.0, FIX4.1,
FIX4.2 y FIX4.4 versin an ms reciente estn disponibles, pero ms firme usar FIX 4.2, ya que la
solucin preferida conectividad FIX o se puede decir versin todava ms utilizado es FIX 4.2, muchas
empresas, los clientes, los fondos de cobertura, fondos de pensiones todava lo utilizan para el comercio
en lnea, pero incluso despus del lanzamiento de la versin ms adelantado que todava sigue siendo el
popular. En FIX lado de avance de 4,4 es conseguir popularidad.
En esta breve discusin que estoy destacando algunas de las diferencias entre FIX 4.2 y FIX 4.4 . Dos
versiones ms populares del protocolo FIX puede comprobar la especificacin FIX para ms detalles y
alguna otra diferencia que sale. Especificacin FIX estn disponibles en http://www.fixprotocol.org se
puede descargar la versin pdf de estas especificaciones y puede mirar antes de desarrollar su
conectividad FIX.
Hay muchas diferencias entre estas dos versiones de protocolo de revisin, algunos de ellos estoy
destacando aqu.
1) Hubo etiqueta llamada ExecTransType (etiqueta 20), que estaba all en FIX 4.2 y ahora se fusionaron
para ExecType etiqueta 150 en FIX4.4, esta etiqueta se utiliza para definir la naturaleza de la ejecucin
recibi del cambio o corredor.
2) Sustituido el uso del QuantityType () campo de etiqueta 465 con nueva QtyType (etiqueta 854), que
contiene un conjunto re-organized/consolidated de valores.
3) Eliminado diversos campos relacionados Instrucciones de liquidacin.
4) Alta "Cita Respuesta" a la lista de mensajes para los que Quote Status Report mensaje es la
respuesta adecuada.
El establecimiento de la conectividad FIX es difcil si se trata de etiquetas de revisin personalizada,
stas son las etiquetas que no estn definidos por el protocolo FIX, pero utilizado por muchas empresas
o entre el cliente y el agente para llevar un poco de informacin extra que se acuerde de eso. Protocolo
FIX permite definir etiquetas FIX personalizado para su conectividad FIX hasta que, ya menos que no
estn en conflicto con cualquier otra etiqueta FIX. Por lo general las empresas utilizan etiquetas o por
encima de 10 000 5000 para definir ste Etiquetas FIX personalizado.
Hay muchos otros cambios que estn disponibles en las notas de la versin de FIX
4.4 http://www.fixprotocol.org , voy a aadir un poco ms de lo llego a saber que se utiliza en el comercio
de da con ms frecuencia.
-> He documentado mi discusin en mi protocolo FIX tutorial serie, por favor verifica para ms
informacin sobre las diferentes reas del protocolo FIX y conectividad FIX por ejemplo la gestin de
sesin FIX , gestin de aplicaciones FIX o preguntas de la entrevista de FIX .

13

Tema comn sobre la informacin financiera de cambio (FIX) Conectividad

Hola chicos, en este post me gustara compartir mi experiencia con el intercambio de informacin
financiera (FIX) Conexiones cual es esencial para la conectividad FIX instalacin con fines de
negociacin. El intercambio de informacin financiera (FIX) Conexiones utilizados tanto en la
conectividad entre cliente y el espacio conectividad de Exchange (en caso de cambio permite el
intercambio de informacin financiera (FIX) Protocolo o se est conectando a travs de cualquier
corredor de Financial Information eXchange (FIX) Protocolo).


As que cada vez que un nuevo cliente llega a bordo de una nueva sesin FIX se necesitar para el que
se identifica por host, el puerto y el borrador ids ejemplo SenderCompID y TargetCompID. Antes de
configurar un nuevo intercambio de informacin financiera (FIX) de sesiones en el motor de su solucin
tendr que requerir la conectividad de red entre la red del cliente y su red, esto por lo general realizado
por el equipo de la red y por razones de seguridad algunas reglas de firewall tambin tiene que ser
configurado. Mientras trabajaba en esta parte usted puede enfrentar algunos problemas de conexin de
red en base a lo que ests eligiendo por ejemplo Radianz, VPN o internet.
-> Una vez que la conexin de red se estableci que est listo para conectar con el cliente. Ahora cliente
enviar la solicitud de inicio de sesin (MessagType = A) con la secuencia no 1, 1 (Al comienzo del da) y
con SenderCompID y TargetCompID acordados. En la capa TCP en primer lugar de conexin de socket
se establezca en la IP del cliente y su IP y su motor Fix escucha en el puerto especificado.una vez que
su motor Fix se logon solicitar su contenido validar y autenticidad de cliente y si todo est bien responde
con otro mensaje de peticin de inicio de sesin. Ahora su intercambio de informacin financiera (FIX)
sesin se establece y est listo para enviar las rdenes a travs de esta conexin. Algunos puntos
importantes a recordar mientras se solucionan Financial Information eXchange (FIX) problemas de
conectividad:

1) Qu Financial Information eXchange (FIX) versiones de protocolo se est utilizando para la
conectividad? Ambas entidades de contrapartida deben utilizar la misma versin de Financial
Information eXchange (FIX) Protocolo para establecer conectividad FIX.
2) Usted est enviando SenderCompID correcta (FIX Tag 49) y TargetCompID (tag FIX 50)? CompIDs
se deben configurar en el lado del aceptador de FIX.
3) Est utilizando IP y el puerto correctos?
4) Se yor motor FIX es el envo de nmero de secuencia correcta que los corredores FIX Engine est
esperando?
5) Est usted manejando solicitud Reenviar correctamente?