[This message was posted by Sean Holohan of NYSE Technologies <[email protected]> to the "4.0 Session" discussion forum at http://fixprotocol.org/discuss/12. You can reply to it on-line at http://fixprotocol.org/discuss/read/ac0445be - PLEASE DO NOT REPLY BY MAIL.]
> Dan, > > Your message touches on something that I've encountered recently and I > wondered if you, or anyone else, could clarify something for me. I > don't know whether you meant to imply that authentication handshaking > (i.e. the exchange of Logon messages) must be completed before > application messages can be sent, but the FIX.4.0 spec does not seem to > me to be so clear. > > For instance, in the section "SESSION PROTOCOL" it states "A FIX session > is comprised of three parts: logon, message exchange and logout.", which > kind of implies that logon must be completed before message exchange can > begin. However, shortly after this in the same section, in the > subsection "Logon" it states "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." > > Does this mean that the initiator may send application messages before > receiving a Logon message from the acceptor if the parties concerned > have a bilateral agreement in place? Obviously, messages received before > a session is "fully established" should not be processed, but they could > be queued. > > Wayne. Wayne, there is no prohibition in the FIX spec that prevents the initiator from sending messages as soon as a Logon message has been sent. But it'll likely make state handling and encryption a good deal more difficult. >From the acceptor side, there's no reason why it couldn't queue up the >messages -- that's really just a transport issue. Before discussing how someone might do this, I'd ask for the use-case. Is there really a reason that an initiator would want to send a series of messages before the connection has been established? I'm not closed to the idea, just interested what reasons there might be. The one reason I could think off-hand is that an initiator is occasionally bringing up a FIX message to blast some messages really quickly before shutting down the session. But that'd probably trying to fix a transport/bandwidth issue and would be better solved via FIX 5.0 with a change of transport semantics. [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 -~----------~----~----~----~------~----~------~--~---
