[This message was posted by Paul Raskin of RJ O'Brien <[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/4cf8f2b7 - PLEASE DO NOT REPLY BY MAIL.]
> > > > Hi Russ, > > > > > > > > The following is from the FIX.4.4 spec > > > > (http://fixprotocol.org/specifications/FIX.4.4, volume 2, page > > > > 29): > > > > > > > > "If during a Logon one receives a second connection attempt while > > > > a valid FIX session is already underway for that same > > > > SenderCompID, it is recommended that the session acceptor > > > > immediately terminate the second connection attempt and not send a > > > > Logout message. > > > > > > Hi Paul, > > > > > > Thanks - that's pretty much what I thought, but I had received an > > > email from someone who wasn't happy with QuickFix doing that so I > > > was wondering if other engines were doing something different. > > > > > > It would be nice if FIX included an informational message type that > > > could be used in these situations, e.g. one where the sequencer > > > number was not relevant. It seems there are several situations where > > > receiving a response message would be beneficial to the connecting > > > system. > > > > > > Cheers, > > > > > > Russ > > > > I agree wholeheartedly, Russ. It is completely unclear to the third > > party in this scenario as to why logon messages sent are unanswered. > > It would be much more helpful in diagnosing the root cause for that > > party if at least some message were sent, even if it were just an admin- > > level reject versus a logout message. If the FIX engine were smart > > enough, it wouldn't up the sequence number for that session if it were > > already active when it received another logon request and it decided > > to send a notification to the third party. Just my two cents. > > > > - Paul > > FIX connectivity may not always be on private lines. If it is an > anonymous user/hacker who is trying to connect, it is worth not sending > anything back but simply drop the connection request. My 2 cents. > > -Chirag I agree, but if the connection is over a public line, you should probably be using encryption anyway. Otherwise, all the traffic is in plain text. A net-to-net VPN is always nice, but as you said, not always available or practical. I hate to use the 'C' word, but this would be great to have as a configurable option so that if you know you're on a private line you could configure the engine to send a message in response, but if it's public you could simply drop the connection attempt with no reply. Again, there are plenty of ways to manage privacy, and I certainly don't have experience with each and every one. - Paul [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.
