Re: [Quickfix-developers] Waiting for automatic ResendRequest to finish?

[Edde <edd...@gm...>]

Hi Oren,

>
> I would really look into writing a simple gateway so your two
> applications can share the connection.


Thanks for everyone's help with this issue!

We've now been in contact with our broker and they have agreed to host one
of our server which is great news since we can now rewrite our applications
to work as a client/server system.
The idea is to have our server (which is hosted at the broker firm) to
communicate with the market through FIX and then we can have any number of
clients connected to the server. I guess this is a fairly common setup for =
a
trading system so I was wondering if anyone on this list have any
suggestions on what transfer/communications protocol we should use between
the client and the server. I guess you can use FIX here as well but since w=
e
need to transmit other data as well (e.g portfolio information) I'd like to
find some other way to communicate. My own idea was to use some XML based
protocol like SOAP but my experience in this is limited so I'd gladly
appreciate any suggestions from the experts on this list. Our system is 100=
%
Java based and I'd like to keep it this way if possible.

Thanks again!
/Eddie



--oren
>
> Edde wrote:
>
> > Hi Dale,
> >
> > Thanks for the quick reply.
> >
> > The reason we've gone through the hassel of resending all the messages
> > is that we're too people working on our trading system. We work from
> > two different locations and a couple of times a day we swap who's
> > doing the actual trading. The current procedure when we swap is that
> > we simply exchange the seqnums file and then since we do the complete
> > ResendRequest the one taking over the trading will process the old
> > messages and reach the current trading "state".
> > However I realize know that I've been on the wrong path by doing this.
> > Your first suggestion  about reading the messages from the log seems
> > pretty good to me. Is there a standardized way of doing this? For
> example:
> >
> > 1) I don't really care about heartbeats etc so is there a
> > specification somewhere which messages are significant when
> reprocessing?
> > 2) Are there any utility methods in QuickFIX to reproduce a FIX
> > message from a String/character stream or similar?
> > 3) I guess you need to maintain a list of all messages already
> > processed so that you don't get duplicate processing of one or more
> > messages?
> >
> > Thanks for your help,
> > /Eddie
> >
> >
> > On 2/20/06, *Dale Wilson* <wil...@oc...
> > <mailto:wil...@oc...>> wrote:
> >
> >     Hi Eddie
> >
> >     Edde wrote:
> >
> >     > Since it needed to resend 50000 messages this takes some time and
> >     > while this is in progress our system continues the startup
> process.
> >     > I'm planning to rewrite this code ASAP but at the moment what we
> do
> >     > after a major crash on either end is to clear all our databases
> and
> >     > send a ResendRequest demanding all messages sent in the session:
> >
> >     The problem is that a ResendRequest is an administrative-level
> message
> >     and you are attempting to use it for an application-level purpose.
> >     TCP/IP will resend packets on occasion as part of it's error
> recovery,
> >     but no one attempts to use this information to "replay" a TCP/IP
> >     session.  THe same should be true for FIX.  Communication stacks
> work
> >     because the layers are kept distinct  --- each one serving it's own
> >     purpose and interactinint with the layers above and below it throug=
h
> a
> >     well specified API.
> >
> >     Unfortunately in FIX the two layers, admin and app, are not so
> >     clearly
> >     delineated and it tempts developers to cross the line.  This
> >     is  not the
> >     first time I have seen someone trying to use a ResendRequest for
> this
> >     purpose.  QuickFIX takes care of the administrative layer of the
> >     protocol for you, but if your application sends its own admin layer
> >     messages that QuickFIX doesn't know about, it gets confused (and
> >     rightly
> >     so!)
> >
> >     You might be able to come up with a hack that works for this
> >     particular
> >     version of QuickFIX, but what ever you come up with there's no
> >     guarantee
> >     that it will work correctly in future versions of QuickFIX.
> >
> >     That gets us to the question of, "what's the *right* way to fix thi=
s
> >     problem..
> >
> >     Solution #1:  read the day's messages fom the store or from the
> >     log and
> >     reprocess them.  .
> >
> >     Solution #2: define a "retransmit today's transactions"
> message.  You
> >     might  define a new custom message type, or consider "twisting" an
> >     application level message for this purpose. (How about using
> >     "wildcard"
> >     order id's in an order status request.? )   You could even define a=
n
> >     "End of retransamint" application level message (or field within a
> >     message).  This, of course, assumes you have some influence on the
> >     software at the other end of the connection.  Note that "misusing"
> an
> >     application level message is much less of a sin than subverting an
> >     Admin
> >     message.  Among other things it won't confuse QuickFIX.
> >
> >     Solution #3:  Trick QuickFIX into sending  the resend request you
> need
> >     -- reset the expected incoming sequence number to 1 without
> >     chaning the
> >     next sequence number to send.  Do this before loggin in so only one
> >     "resed" will happen.
> >
> >
> >     Dale
> >
> >     --
> >     -----------------------------------------------------
> >     Dale Wilson, Senior Software Engineer
> >     Object Computing, Inc. (OCI)
> >     http://www.ociweb.com/  http://www.theaceorb.com/
> >     ----------------------------------------------------
> >
> >
>