Missing points

, ,
1

Imported from previous forum

2

Hello,

I’m a software developer and new to FIX but not to trading software in general.
I started reading version 4.0 of the spec but i run into some points that i’m missing (or I’m to blind to find them).

I can’t find anything about the actual message flow. Who is starting the communication? client or server?
Are there any initialization messages?
What about if one side disconnects in the middle of the communication? How should the other side react?
What if one side sends invalid data?

I hope you can help me out?

Regards,
Sascha Kiefer

3

Hello,

I’m a software developer and new to FIX but not to trading software in
general. I started reading version 4.0 of the spec but i run into some
points that i’m missing (or I’m to blind to find them).

I can’t find anything about the actual message flow. Who is starting the
communication? client or server? Are there any initialization messages?
What about if one side disconnects in the middle of the communication?
How should the other side react? What if one side sends invalid data?

I hope you can help me out?

Regards, Sascha Kiefer

I’m also very new to FIX but since no one has answered yet ill try to share some information about what I’ve learned so far hopefully someone with more insight or experience will provide more details.

To your first question It really depends on how fix is being used between parties usually a buy side firm will initiate the session to a brokers FIX engine to place an order to buy or sell.

TO initiate a FIX session there is a (Logon) session level message I believe MsgType[35]=“A” that authenticates a user establishing a connection to a remote system. This is sent from the requestor side who wants initiate a FIX connection.

FIX Engines validate that messages are properly formed and will reject the message using a Session Level REJECT message if the message is invalid back to the requestor.

I hope this helps.

  • Rodrick R. Brown
4

Hello,

I’m a software developer and new to FIX but not to trading software in
general. I started reading version 4.0 of the spec but i run into some
points that i’m missing (or I’m to blind to find them).

To be honest all of these points are covered in quite a lot of detail in the FIX spec - you might want to read a more recent version as they are more complete. Also any new implementation would probably want to be more recent than FIX.4.0 in any case.

Try starting on page 6 of FIX 4.4 spec volume 2.

Thanks,

James

5

Thank you very much for you hints.
Helped me a lot already.

Hello,

I’m a software developer and new to FIX but not to trading software
in general. I started reading version 4.0 of the spec but i run into
some points that i’m missing (or I’m to blind to find them).

To be honest all of these points are covered in quite a lot of detail in
the FIX spec - you might want to read a more recent version as they are
more complete. Also any new implementation would probably want to be
more recent than FIX.4.0 in any case.

Try starting on page 6 of FIX 4.4 spec volume 2.

Thanks,

James

6

[ original email was from Sean Hawie - sean.hawie@reuters.com ]

What about if one side disconnects in the middle of the communication?
How should the other side react?

Whatever the cause of the disconnect, the direction of connection is always the same as in the first instance, i.e. the initiator should attempt to reconnect. In my experience, I’ve seen people use Order Status Request messages (MsgType=H) to retrieve lost data on a per-trade basis.

Hope this helps.

Regards,
Sean

7

You can refer these links within fix protocol website. Its really good and gives a detailed insite of what you want to know.

http://www.fixprotocol.org/specifications/fixt1.1spec
http://www.fixprotocol.org/specifications/TechDoc-Beginner

Regards,
Sunil

8

Hi Sunil,

Thanks for your information. Actually, I have been the member of FIXprotocol for about 3 years now. I visit their website at least twice a week in an attempt to learn something new. Currently, I am desperately search for some technical assistance about FIX Gateway capability as well as many useful and advanced functionalities within equity trading arena. Do you know anyone of such amazing quality? Anyone who knows all versions of FIX from 4.0 to 5.0? I need professional experts to help us.

Thanks.

Bruce

9

[ original email was from Antonio Barakat - antonio_barakat2000@yahoo.com ]
>

What about if one side disconnects in the middle of the communication?
How should the other side react?

Whatever the cause of the disconnect, the direction of connection is
always the same as in the first instance, i.e. the initiator should
attempt to reconnect. In my experience, I’ve seen people use Order
Status Request messages (MsgType=H) to retrieve lost data on a per-
trade basis.

Hope this helps.

Regards, Sean

Sean,

In my experience although its more convienent if the initiator attempts to connect, ive set up connections in the past that its easier if the connection is established ‘opposite’ the order flow. The acknowledgements flowing back to the initiator can then be resent if the FIX messages were never sent to begin with.
Its much more to know that an order is acknowledged and being worked on rather than an order never being received at all. I’ve seem many trade breaks because of this and by setting up the connection in this manner its alleviated quite a bit of issues…any suggestions on your end?

10

[ original email was from Sean Hawie - sean.hawie@reuters.com ]
> >

What about if one side disconnects in the middle of the
communication? How should the other side react?

Whatever the cause of the disconnect, the direction of connection is
always the same as in the first instance, i.e. the initiator should
attempt to reconnect. In my experience, I’ve seen people use Order
Status Request messages (MsgType=H) to retrieve lost data on a per-
trade basis.

Hope this helps.

Regards, Sean

Sean,

In my experience although its more convienent if the initiator
attempts to connect, ive set up connections in the past that its
easier if the connection is established ‘opposite’ the order flow. The
acknowledgements flowing back to the initiator can then be resent if
the FIX messages were never sent to begin with. Its much more to know
that an order is acknowledged and being worked on rather than an order
never being received at all. I’ve seem many trade breaks because of
this and by setting up the connection in this manner its alleviated
quite a bit of issues…any suggestions on your end?

Antonio,

The ‘initiator’ I refer to is the term given to the FIX engine which attempts to log into the other (the acceptor). This usually cannot be switched after a disconnect, as in many cases FIX connections typically heavily firewalled in one direction and this would cause complications. What I believe you’re referring to is the initiator in the trade workflow, perhaps?

11

[ original email was from Antonio Barakat - antonio_barakat2000@yahoo.com ]
> > >

What about if one side disconnects in the middle of the
communication? How should the other side react?

Whatever the cause of the disconnect, the direction of connection is
always the same as in the first instance, i.e. the initiator should
attempt to reconnect. In my experience, I’ve seen people use Order
Status Request messages (MsgType=H) to retrieve lost data on a per-
trade basis.

Hope this helps.

Regards, Sean

Sean,

In my experience although its more convienent if the initiator
attempts to connect, ive set up connections in the past that its
easier if the connection is established ‘opposite’ the order flow.
The acknowledgements flowing back to the initiator can then be
resent if the FIX messages were never sent to begin with. Its much
more to know that an order is acknowledged and being worked on
rather than an order never being received at all. I’ve seem many
trade breaks because of this and by setting up the connection in
this manner its alleviated quite a bit of issues…any suggestions
on your end?

Antonio,

The ‘initiator’ I refer to is the term given to the FIX engine which
attempts to log into the other (the acceptor). This usually cannot be
switched after a disconnect, as in many cases FIX connections typically
heavily firewalled in one direction and this would cause complications.
What I believe you’re referring to is the initiator in the trade
workflow, perhaps?

Yes in the direction of the trade flow, what i referred to what not the physical connection but when re-sending the messages. The initiator of the connection should get the re-send request. This is typical of many connection where the receipiant of the connection re-sends its messages, opposite the trade flow.