Thread: [Quickfix-developers] Does QuickFix implement Message Queue mechanism to make sure all messages are
Brought to you by:
orenmnero
From: Frank <fr...@di...> - 2004-09-02 01:47:49
|
Hi, I'm trying to make use of quickfix to replace the old fix gateway(ugly = code, not flexible, only support fix4.0) in my company. I have many years of socket programming experience. Every time when I = write a tcp socket program, I'll worry about buffering of read and write = stream, queueing of messages ready to send, queueing of messages = received and waiting for handling. If I add such kinds of handling in = the socket program, the program will be really very stable and robust; = if not, errors will occur after it runs for some time. My question is: Does QuickFix have such kinds of handling ? especially = message queue mechanism ? May I borrow it to deal with other sockets = (My program is a fix gateway, one side connects trading system (not fix = protocol), one side connects ECN(fix protocol)) ? QuickFix source code is so complicated that I can not figure it out by = myself right now. Thanks. |
From: Joerg T. <Joe...@ma...> - 2004-09-02 09:04:51
|
Hi Frank, > I'm trying to make use of quickfix to replace the old fix gateway(ugly > code, not flexible, only support fix4.0) in my company. Good to hear that. That is the idea behind QuickFIX: Joining efforts to get one, high quality solution. > I have many years of socket programming experience. Every time when I > write a tcp socket program, I'll worry about buffering of read and write > stream, queueing of messages ready to send, queueing of messages > received and waiting for handling. If I add such kinds of handling in > the socket program, the program will be really very stable and robust; > if not, errors will occur after it runs for some time. Actually, the FIX protocol itself is independent of the underlying transport, it would also work with UDP. The session level protocol takes care of lost and out-of-order messages, so if an implementation fully implements the session level protocol of FIX (which QF does), you should not worry about this. > My question is: Does QuickFix have such kinds of handling ? especially > message queue mechanism ? May I borrow it to deal with other sockets > (My program is a fix gateway, one side connects trading system (not fix > protocol), one side connects ECN(fix protocol)) ? For the incoming data, there is now queue/buffer besides the TCP buffer, so that every message read is immediately forwarded to the fromApp() or fromAdmin() callback. So it is the responsibility of the application to queue these message if needed. The outgoing data is saved in a messsage store (file, database, your own implementation). You can send data to a session as soon as it is created (onCreate() callback triggered). This is independent of the logon state of the session, i.e. you can send messages to a session if it is logged off. If the session gets logged on again, these messages are transferred. The reason behind that is the requirement of the FIX protocol to be always able to resend messages. If this does not answer your question, please do not hesitate to ask. BTW, do you have some new exchange/ECN to be added to our WikiFIX? Cheers, Jörg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
From: Oren M. <or...@qu...> - 2004-09-02 14:16:28
|
Actually, the threaded sockets do use a queue. The relevant code is =20 here: http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/=20 Queue.h?view=3Dmarkup http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/=20 ThreadedSocketConnection.cpp?view=3Dmarkup On Sep 2, 2004, at 4:04 AM, Joerg Thoennes wrote: > QuickFIX Documentation: =20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: =20 > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi Frank, > >> I'm trying to make use of quickfix to replace the old fix =20 >> gateway(ugly code, not flexible, only support fix4.0) in my company. > > Good to hear that. That is the idea behind QuickFIX: Joining efforts =20= > to get one, high quality solution. > >> I have many years of socket programming experience. Every time when I = =20 >> write a tcp socket program, I'll worry about buffering of read and =20= >> write stream, queueing of messages ready to send, queueing of =20 >> messages received and waiting for handling. If I add such kinds of =20= >> handling in the socket program, the program will be really very =20 >> stable and robust; if not, errors will occur after it runs for some =20= >> time. > > Actually, the FIX protocol itself is independent of the underlying =20 > transport, it would also work with UDP. The session level protocol =20 > takes care of lost and out-of-order messages, so if an implementation =20= > fully implements the session level protocol of FIX (which QF does), =20= > you should not worry about this. > >> My question is: Does QuickFix have such kinds of handling ? =20 >> especially message queue mechanism ? May I borrow it to deal with =20= >> other sockets (My program is a fix gateway, one side connects trading = =20 >> system (not fix protocol), one side connects ECN(fix protocol)) ? > > For the incoming data, there is now queue/buffer besides the TCP =20 > buffer, so that every message read is immediately forwarded to the =20 > fromApp() or fromAdmin() callback. So it is the responsibility of the =20= > application to queue these message if needed. > > The outgoing data is saved in a messsage store (file, database, your =20= > own implementation). You can send data to a session as soon as it is =20= > created (onCreate() callback triggered). This is independent of the =20= > logon state of the session, i.e. you can send messages to a session if = =20 > it is logged off. If the session gets logged on again, these messages =20= > are transferred. The reason behind that is the requirement of the FIX =20= > protocol to be always able to resend messages. > > If this does not answer your question, please do not hesitate to ask. > > BTW, do you have some new exchange/ECN to be added to our WikiFIX? > > Cheers, J=F6rg > > --=20 > Joerg Thoennes > http://macd.com > Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH > Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
From: Frank <fr...@di...> - 2004-09-03 19:36:13
|
Hi Joerg, Thank you very much ! I'll try to read the source code to get thorough understanding of QuickFix. It should be almost perfect because of the efforts of so many experts. Message buffer and queue mechanisms are still headache for socket programmers. I'm looking for standard solution so that I can call some standard APIs to deal with such issues. I'm not satisfied with my code and the existing code in my company. It seems that many exchange/ECNs are still using FIX4.0, some of them are upgrading to FIX4.2, I've never heard which exchange/ECN is using FIX4.3 or 4.4. I don't understand why. I'll search WikiFIX and try to add new exchange/ECN to WikiFIX. Cheers, Frank |
From: James C. D. <jc...@co...> - 2004-09-04 00:12:15
|
Frank, To answer your question regarding FIX Version adoption: IMHO, the major liquidity providers that adopted FIX early on, namely the ECNs, have very little incentive to move up to 4.3 or 4.4. To my understanding, these releases addressed deficiencies in the application messages for derivatives and fixed income products. Basically the session level stayed the same. My guess is that Fix 4.5 will have a heavy dose of FX. If a liquidity provider finds a deficiency in a version they have in production they have three choices: 1) Upgrade to a newer version of FIX that addresses the short comings - very expensive. 2) Add a custom tag to their existing implementation - keeps everyone backwardly compatible 3) Incorporate tags from later versions of FIX into the current implementation - easy backward compatibility FIX 4.4 is being implemented in the fixed income world. FIX 4.3 is a bit of an orphan. Jim James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Frank Sent: Friday, September 03, 2004 3:36 PM To: qui...@li... Subject: Re: [Quickfix-developers] Does QuickFix implement Message Queue mechanism to make sure all messages are delivered ? QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: http://www.quickfixengine.org/services.html Hi Joerg, Thank you very much ! I'll try to read the source code to get thorough understanding of QuickFix. It should be almost perfect because of the efforts of so many experts. Message buffer and queue mechanisms are still headache for socket programmers. I'm looking for standard solution so that I can call some standard APIs to deal with such issues. I'm not satisfied with my code and the existing code in my company. It seems that many exchange/ECNs are still using FIX4.0, some of them are upgrading to FIX4.2, I've never heard which exchange/ECN is using FIX4.3 or 4.4. I don't understand why. I'll search WikiFIX and try to add new exchange/ECN to WikiFIX. Cheers, Frank ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |