[This message was posted by Mahesh Kumaraguru of <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/761287b2 - PLEASE DO NOT REPLY BY MAIL.]
[Quotes from FIX specs located at http://fixprotocol.org/specifications/] A FIX session is defined as a bi-directional stream of ordered messages between two parties within a continuous sequence number series. Logon - Establishing a FIX connection involves three distinct operations: creation of a telecommunications level link, authentication/acceptance of the initiator by the acceptor and message synchronization (initialization). The sequence of connection follows: * The session initiator establishes a telecommunication link with the session acceptor. * The initiator sends a Logon message. The acceptor will authenticate the identity of the initiator by examining the Logon message. The Logon message will contain the data necessary to support the authentication method previously agreed upon between the parties. If the initiator is successfully authenticated, the acceptor responds with a Logon message, if authentication fails, the session acceptor should shut down the connection. The session initiator may begin to send messages immediately following the Logon message, however, the session may not be supported by the other side at this time. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established. After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon message. Depending on the encryption method being used for that session, this Logon message may or may not contain the same session encryption key. The initiator side will use the Logon message being returned from the acceptor as confirmation that a FIX session has been established. If the session acceptor has chosen to change the session encryption key, the session initiator must send a third Logon back to the other side in order to acknowledge the key change request. This also allows the session acceptor to know when the session initiator has started to encrypt using the new session key. Both parties are responsible for infinite loop detection and prevention during this phase of the session. * After authentication, the initiator and acceptor must synchronize their messages through interrogation of the MsgSeqNo field. A comparison of the MsgSeqNo in the Logon message to the internally monitored next expected sequence number will indicate any message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment Logon message MsgSeqNo to the next expected value. Refer to the section on message recovery later in this document for dealing with message gaps. [End Quotes] > Hi, > > I'm fairly new to FIX, having come from a SWIFT-type background. > > The most significant difference appears to be transport of the messages. > Is there anyone who could describe how I would know in the TCP stream > when it was ok to send a message? > > This is particularly WRT opening a connection, logging in and opening > streaming FX rates. > > I'm expecting to continually receive new quote updates, and once they > start flowing I'm not sure how to know when it's ok to transmit > something to the counter party. > > Hope this all makes sense... > > Regards, Dave [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
