RE: [Quickfix-developers] Options for server sharing (was: Waiting for automatic ResendRequest to fi

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Edde,
=20
There are many options. You could use a hybrid approach, FIX for the
trading messages and
a remoting technology like RMI for communicating other information. You
could also transmit
XML documents using FIX for your portfolio messages. If you are familiar
with the Spring
Framework, it has a nice object remoting framework with several options
for the transport
protocol (also see Lingo http://lingo.codehaus.org/ for JMS-based
remoting).
=20
Steve Bate
Smart Trade Technologies
Phone: +33 4 42 90 03 97
http://www.smart-trade.net/

________________________________

	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Edde
	Sent: Wednesday, March 15, 2006 5:09 PM
	To: Oren Miller
	Cc: qui...@li...; Dale Wilson
	Subject: Re: [Quickfix-developers] Waiting for automatic
ResendRequest to finish?
=09
=09
	Hi Oren,
=09

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

	=20
	Thanks for everyone's help with this issue!
	=20
	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 we 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.=20
	=20
	Thanks again!
	/Eddie
	=20
	=20

		--oren
	=09
		Edde wrote:
	=09
		> Hi Dale,
		>
		> Thanks for the quick reply.
		>
		> The reason we've gone through the hassel of resending
all the messages=20
		> 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=20
		> 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:=20
		>
		> 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=20
		> 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?=20
		>
		> Thanks for your help,
		> /Eddie
		>
		>
		> On 2/20/06, *Dale Wilson* <wil...@oc...
		> <mailto: 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.=20
		>     > 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:=20
		>
		>     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,=20
		>     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=20
		>     purpose and interactinint with the layers above
and below it through 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=20
		>     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=20
		>     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 this=20
		>     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=20
		>     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 an=20
		>     "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=20
		>     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=20
		>     -- 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/
		>
----------------------------------------------------
		>
		>
	=09

RE: [Quickfix-developers] Options for server sharing (was: Waiting for automatic ResendRequest to fi

RE: [Quickfix-developers] Options for server sharing (was: Waiting for automatic ResendRequest to finish?)