FIX Session Recovery versus Non FIX reconnect procedures / Roles of Session Initiator and Acceptor + Networking
Mahesh Kumaraguru <>
3 Nov 2007 1:05AM ETMilind,
I am not sure if what you are trying to do would work with FIX Engines built as per FIX Protocol specs. By definition, its the Session initiator who sends Logon message. Many of the Buy side FIX engines that I have come across retry logon some configurable number of times as Session Initiator and Sell side engine waits some timeout interval for attempt from buy side client to reconnect, else if successfull fails, then Sell side trading engine (NOT FIX Engine) kills the orders hich it received from the "disconnected timedout Buy side client" as per some mutually agreed upon rules. If your side ie. Sell side ie. Session Acceptor sends an logon message after disconnect, I am not sure if your counterparty's FIX Rngine which are designed to be Session initiator would even accept it. FIX Sessions I have come accross always expect the "buy side client" to send logon to "sell side server". This also follows from client-server architecture - its always the client requesting services from server.
http://en.wikipedia.org/wiki/Client_server
Switching Logon sequence mid session on session disconnect would do more damage than benefit. What if the Session initiator is behind a firewall which permits only outbound connections, in which case your "special" logon message would not reach the Session initiator's FIXEngine. If your FIX Engine is behind a firewall which only permits inbound connections, then your message would not go out.
Instead, the better option is Buy side client retries normal FIX logon procedure and after successful relogon, either makes resend request (in case of missed messages), or makes Order status request (when there are no missed messages) and your server can honor client request and stay within FIX protocol.
Finally, FIX is a protocol - so whatever is agreed upon mutually has to be implimented by both sides unless one party proves thru an FIXperiment (QA/UAT FIX Test) that the other party needs to "fix their FIX". This "special" logon mechanism can work between "your client and "your" server", but it would not work with "all" FIX engines designed as per convention of "Session Initiator always sends logon". If you implement this special Logon mechanism, then you might be entering the zone of Peer-to-Peer Architecture:-
http://en.wikipedia.org/wiki/Client_server#Comparison_to_Peer-to-Peer_Architecture
http://en.wikipedia.org/wiki/Category:Network_architecture
or something else. Welcome to FIXperimentors club. Let me for the sake of simplicity take a layman example (sorry for thinking out aloud):-
Traffic / driving road rules are established by the governments - all "drivers" adhere to the "local" driving rules - in India, road rule says "keep to left" and when all people follow this rule everything is fine, in USA road rule says "keep to right" and when all people follow this rule everything is fine. Its just a convention agreed upon by all people on the "street" and enforced by a governing body, its the same @ FIX Street. If you want to connect to "real FIX on Wall street", you would need to follow "THE" FIX spec, everything outside of it may be just a FIXperiment :-(
Regards,
K. Mahesh
+1-203-252-4039
> > Hello Friends, I have encounter with a Problem where i want to send
> > login request again. But with different transcode...like special
> > login request Can I use another transcode for logon? is there any
> > provision for recovery? Looking for reply urgently Thanks and
> > Regards, Milind Ture
>
>
> Thanks a Lot Mahesh for reply Actually the requirement is like..if FIX
> initiator fails after establishing connnection ,we are planing to send
> special logon request so that client should not feel like log out. as
> per your reply we will use special logon rewuest with field 35 and
> transcode will start with "U". Thanks a lot again.
