Thread: [Quickfix-developers] Subscribe/Publish logic
Brought to you by:
orenmnero
|
From: mjc2k <MJC...@ms...> - 2007-01-05 23:24:30
|
I just started looking at QuickFix so I am trying to understand what's needed by the developer Does quickfix handle Subscribe/Publish logic or is this required by the developer. Example: Client 1 makes a request for Orders on account 10000 (Subscription). The Server will then post updates back to the client anytime something changes with out the client polling (Publish). Client then makes a Snapshot request to backfill any missing orders. Client is now in sync. Client 2 makes a request for a Orders on account 10000. (Subscription). The Server will then post updates back to the client anytime something changes. (Publish). Client then makes a Snapshot request to backfill any missing orders. Client is now in sync. Server: Server stores subscriptions for each client. Now when an updated Order is detected, it will post this to all subscribers. I'm trying to understand where the logic is handled by the server. Any source code examples would be greatly appreciated. I want to be able to pubish realtime prices from our Feed to the clients that subscribe. Not sure if I need my own message types or if one is already supplied. Thanks Matt MJCarlucci at msn.com -- View this message in context: http://www.nabble.com/Subscribe-Publish-logic-tf2928739.html#a8188127 Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Caleb E. <cal...@gm...> - 2007-01-08 21:30:48
|
On 1/5/07, mjc2k <MJC...@ms...> wrote: > Does quickfix handle Subscribe/Publish logic or is this required by the > developer. You'd need to handle this yourself. QuickFIX gives you a FIX engine you can use to send/receive messages (with associated persistence, recovery, etc), but any logic you want on top of these messages will need to be written by you. This would include like maintaining an order book, this "subscription" list you refer to, etc. > I want to be able to pubish realtime prices from our Feed to the clients > that subscribe. Not sure if I need my own message types or if one is already > supplied. FIX4.2 and later include Market Data messages, but if performance is a concern FIX might not be a very good choice for distributing market data. -- Caleb Epstein |
|
From: Matt C. <MJC...@ms...> - 2007-01-15 19:31:36
|
Caleb Epstein wrote: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > On 1/5/07, mjc2k <MJC...@ms...> wrote: > >> Does quickfix handle Subscribe/Publish logic or is this required by the >> developer. > > You'd need to handle this yourself. QuickFIX gives you a FIX engine > you can use to send/receive messages (with associated persistence, > recovery, etc), but any logic you want on top of these messages will > need to be written by you. This would include like maintaining an > order book, this "subscription" list you refer to, etc. > >> I want to be able to pubish realtime prices from our Feed to the clients >> that subscribe. Not sure if I need my own message types or if one is >> already >> supplied. > > FIX4.2 and later include Market Data messages, but if performance is a > concern FIX might not be a very good choice for distributing market > data. > > -- > Caleb Epstein > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > Thank you Carl. I'm starting to see some light. One thing I cam across was the FAST Protocol. I read the spec and scanned several other docs. It appears that Fast would resolve any possible latency issues when sending large amounts of messages. The example provided contains several messages totaling 354 bytes. Typical compression is 2:1, where as using the encoding method was only 67 bytes 5:1 ratio. Does QuickFix offer the Fast Encoding/Decoding methods or is there any immediatae plans to implement it? Regards Matt Carlucci -- View this message in context: http://www.nabble.com/Subscribe-Publish-logic-tf2928739.html#a8377721 Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Caleb E. <cal...@gm...> - 2007-01-16 02:33:52
|
On 1/15/07, Matt Carlucci <MJC...@ms...> wrote:
> Thank you Carl. I'm starting to see some light. One thing I cam across was
Its Caleb. But you're welcome :)
> the FAST Protocol. I read the spec and scanned several other docs. It
> appears that Fast would resolve any possible latency issues when sending
> large amounts of messages.
Yes, FAST is a much more optimal encoding for things like market data.
That said, a simple fixed-field-width text message is also pretty
optimal and used for most major exchange feeds at the present time.
> Does QuickFix offer the Fast Encoding/Decoding methods or is there any
> immediatae plans to implement it?
No, QuickFIX doesn't support FAST, but there is a very nice reference
implementation written in C available on the FIX Protocol web site:
http://www.fixprotocol.org/fast/
--
Caleb Epstein
|