quickfix-developers — QuickFIX developers forum

RE: [Quickfix-developers] Session Identification Problem

[Shamanth <sha...@in...>]

Hi Oren
=20
Thanks for the reply, the option of using UserID is very helpful, we =
could do this.:)
=20
But does FIXProtocol allow this? like can we have same sender and =
targetID for two different sessions if the two sessions are different in =
functionality?
or does it say that we need to have a unique combination of senderId and =
targetID.=20
=20
I did go through the FIXProtocol spec, but I could not identify any =
place where it specifically states this.=20
=20
thanks
R Shamanth

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Friday, July 30, 2004 5:19 PM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-developers] Session Identification Problem



That's a strange scenario. The way QuickFIX would handle this now is the =
way you don't want to do it, two separate processes. The problem with =
using something like the port to identify the session is twofold. One, =
as Joerg pointed out, it is a transport level concept and not one which =
the fix protocol itself is familiar with. Another problem is that the =
port is not a part of the message. In other words, in a scenario like =
this, you can no longer rely on the contents of the message to identify =
what session it belongs to. This means we would have to rely on some =
meta-data in addition to the FIX message itself to figure out where it =
needs to be routed. I don't have a problem with this necessarily, but I =
don't think and arbitrary attribute like the session port is the way to =
do it.=20


One thing I may consider is something along the lines of a UserID =
configuration field. Something like this:=20


[SESSION]=20

SenderCompID=3DSENDER=20

TargetCompID=3DTARGET=20

UserID=3DMARKETDATA=20


[SESSION]=20

SenderCompID=3DSENDER=20

TargetCompID=3DTARGET=20

UserID=3DORDER=20


This user id would be optional, and it would at least make the id =
meaningful.=20


On Jul 28, 2004, at 7:18 AM, Shamanth wrote:=20


Hi=20


We have a provider who has the two sessions exposed=20

1) For Marketdata=20

2) For Order=20


The problem is both these sessions use same SenderID, SenderSubID, =
TargetID and also the SocketConnectHost the only difference is in the =
port number (SocketConnetPort).=20


How does quickfix can be setup to handle the above situation. We want to =
run only one instance of quickfix servicing both the sessions.=20


thanks=20

R Shamanth=20


  NOTICE=20


This e-mail message and any attachments, which may contain confidential =
information, are to be viewed solely by the intended recipient of =
Integral Development Corp.  If the reader of this message is not the =
intended recipient, you are hereby notified that any use, dissemination, =
distribution or copying of this communication is strictly prohibited.  =
If you have received this message in error, please immediately notify =
the sender and delete the mail and all attachments.

Re: [Quickfix-developers] Session Identification Problem

[Oren M. <or...@qu...>]

That's a strange scenario.  The way QuickFIX would handle this now is=20
the way you don't want to do it, two separate processes.  The problem=20
with using something like the port to identify the session is twofold. =20=

One, as Joerg pointed out, it is a transport level concept and not one=20=

which the fix protocol itself is familiar with.  Another problem is=20
that the port is not a part of the message.  In other words, in a=20
scenario like this, you can no longer rely on the contents of the=20
message to identify what session it belongs to.  This means we would=20
have to rely on some meta-data in addition to the FIX message itself to=20=

figure out where it needs to be routed.  I don't have a problem with=20
this necessarily, but I don't think and arbitrary attribute like the=20
session port is the way to do it.

One thing I may consider is something along the lines of a UserID=20
configuration field.  Something like this:

[SESSION]
SenderCompID=3DSENDER
TargetCompID=3DTARGET
UserID=3DMARKETDATA

[SESSION]
SenderCompID=3DSENDER
TargetCompID=3DTARGET
UserID=3DORDER

This user id would be optional, and it would at least make the id=20
meaningful.

On Jul 28, 2004, at 7:18 AM, Shamanth wrote:

> Hi
>
> We have a provider who has the two sessions exposed
>  1) For Marketdata
>  2) For Order
>
> The problem is both these sessions use same SenderID, SenderSubID,=20
> TargetID and also the SocketConnectHost the only difference is in the=20=

> port number (SocketConnetPort).
>
> How does quickfix can be setup to handle the above situation. We want=20=

> to run only one instance of quickfix servicing both the sessions.
>
> thanks
>  R Shamanth
>
> =A0 NOTICE
>
> This e-mail message and any attachments, which may contain=20
> confidential information, are to be viewed solely by the intended=20
> recipient of Integral Development Corp.=A0 If the reader of this =
message=20
> is not the intended recipient, you are hereby notified that any use,=20=

> dissemination, distribution or copying of this communication is=20
> strictly prohibited.=A0 If you have received this message in error,=20
> please immediately notify the sender and delete the mail and all=20
> attachments.

Re: [Quickfix-developers] Problem implementing Email Message in 4.2

[Oren M. <or...@qu...>]

It would appear that you declared,

void onMessage( const FIX42::Email&, const FIX::SessionID& );

in your header without providing a proper definition for it in your  
source file.  Double check that you have a definition and that it  
matches the declaration.

--oren

On Jul 29, 2004, at 10:34 PM, loic guezennec wrote:

> QuickFIX Documentation:  
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> This may sound silly, but I have been trying to handle
> the Email message with FIX 4.2 on linux using
> gcc.2.95.3 and quickfix 1.8 ( I also tried on a
> version of qf.1.6 and gcc 3.x that I had lying around)
> and I can't seem to link: I keep on getting:
> Application.o(.gnu.linkonce.t.__thunk_12_onMessage__11ApplicationRCQ25F 
> IX425EmailRCQ23FIX
> 9SessionID+0x6): In function `virtual function thunk
> (delta:-12) for Application::onMessa
> ge(FIX42::Email const &, FIX::SessionID const &)':
> : undefined reference to
> `Application::onMessage(FIX42::Email const &,
> FIX::SessionID con
> st &)'
>
>
> Now my question is: has anyone implemented Email
> messages ( ie is it just me or is there something
> wrong), I have no problem with other message types, so
> I think there may be something up.
>
> I don't know nm well enough to understand what
> happens, but as far as I can see the symbols are
> there.
> Any pointers will be appreciated :)
>
>
> 	
> 	
> 		
> ___________________________________________________________ALL-NEW  
> Yahoo! Messenger - all new features - even more fun!   
> http://uk.messenger.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source  
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Problem implementing Email Message in 4.2

[<loi...@ya...>]

Hi,

This may sound silly, but I have been trying to handle
the Email message with FIX 4.2 on linux using
gcc.2.95.3 and quickfix 1.8 ( I also tried on a
version of qf.1.6 and gcc 3.x that I had lying around)
and I can't seem to link: I keep on getting:
Application.o(.gnu.linkonce.t.__thunk_12_onMessage__11ApplicationRCQ25FIX425EmailRCQ23FIX
9SessionID+0x6): In function `virtual function thunk
(delta:-12) for Application::onMessa
ge(FIX42::Email const &, FIX::SessionID const &)':
: undefined reference to
`Application::onMessage(FIX42::Email const &,
FIX::SessionID con
st &)'


Now my question is: has anyone implemented Email
messages ( ie is it just me or is there something
wrong), I have no problem with other message types, so
I think there may be something up.

I don't know nm well enough to understand what
happens, but as far as I can see the symbols are
there.
Any pointers will be appreciated :)


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

[Quickfix-developers] Week long sessions

[Oren M. <or...@qu...>]

I've checked into CVS support for week long sessions.  In addition to 
the StartTime and EndTime, QuickFIX will allow you to specify a 
StartDay and EndDay which are days of the week. So monday, or friday, 
or any abbreviation.  Remember that all times are in UTC, so the time 
difference could affect which day you should specify.  There are a lot 
of unit tests and everything looks good, but I would appreciate if 
people can independently verify that it does what's expected.  The 
driving force for this feature is to support connecting to the CME out 
of the box.

Instructions for getting the source from CVS are here: 
http://www.quickfixengine.org/developers.html

When we are happy with this feature, we will do a new release.

--oren

[Quickfix-developers] RE: Reconnect problem.

[Shamanth <sha...@in...>]

Hi Oren

Sorry I forgot to mention the version. I am using 1.7.1, tomorrow I will =
test it with 1.8 and let you guys know the results.

thanks
R Shamanth

>  -----Original Message-----
> From: 	Shamanth =20
> Sent:	Friday, July 23, 2004 5:30 PM
> To:	'qui...@li...'
> Cc:	'qui...@li...'
> Subject:	Reconnect problem.
>=20
> Hi
>=20
> We have a problem with disconnect.
>=20
> We have a simulator (quickfix instance "acceptor") and a FIX =
client(also quickfix instance "initiator").
>=20
> On the acceptor our starttime and endtime are
> StartTime=3D00:00:00
> EndTime=3D00:00:00
>=20
> On the initiator our starttime and endtime are
> StartTime=3D05:30:00   (IST =3D  GMT + 5:30)
> EndTime=3D05:30:00   (IST: GMT + 5:30)
>=20
> Also
> CheckLatency=3DN
> ResetOnDisconnect=3DN
> ResetSeqNoOnLogon=3Dtrue
>=20
> But the problem is the acceptor disconnects exactly at 00:00:00 GMT =
and does not reconnect. We have tried by changing the initiator start =
and end time to 06:00:00, and ResetSeqNoOnLogon to false. But this does =
not solve the problem.
>=20
> Does any one know what could be the problem.
>=20
> NOTE: Both initiator and simulator are sitting on the same machine.
>=20
> thanks and regards
> R Shamanth
>=20
>=20
>   NOTICE
> This e-mail message and any attachments, which may contain =
confidential information, are to be viewed solely by the intended =
recipient of Integral Development Corp.  If the reader of this message =
is not the intended recipient, you are hereby notified that any use, =
dissemination, distribution or copying of this communication is strictly =
prohibited.  If you have received this message in error, please =
immediately notify the sender and delete the mail and all attachments.
>=20

[Quickfix-developers] Session Identification Problem

[Shamanth <sha...@in...>]

Hi

We have a provider who has the two sessions exposed
1) For Marketdata
2) For Order

The problem is both these sessions use same SenderID, SenderSubID, =
TargetID and also the SocketConnectHost the only difference is in the =
port number (SocketConnetPort).

How does quickfix can be setup to handle the above situation. We want to =
run only one instance of quickfix servicing both the sessions.

thanks
R Shamanth

>   NOTICE
> This e-mail message and any attachments, which may contain =
confidential information, are to be viewed solely by the intended =
recipient of Integral Development Corp.  If the reader of this message =
is not the intended recipient, you are hereby notified that any use, =
dissemination, distribution or copying of this communication is strictly =
prohibited.  If you have received this message in error, please =
immediately notify the sender and delete the mail and all attachments.
>=20

Re: [Quickfix-developers] Heartbeat

[Oren M. <or...@qu...>]

Ahh you know, there is already a fix for this.  OptionsXpress reported=20=

this problem a couple months ago and I helped resolve it for them.  I=20
thought I had checked it in but looking at the release notes and CVS, I=20=

certainly did not.  The easiest way to fix this problem is to add a=20
call to next() on the last line of the Session::next( const Message&=20
message ) method.  This gives the session a chance to do administrative=20=

processing in between messages.  I'll check in the fix and make sure it=20=

goes out in the next release.

--oren

On Jul 23, 2004, at 8:54 AM, Yihu Fang wrote:

> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Joerg,
>
> I don't have the logs with me anymore and will need some effort to=20
> recreate it. Basically, it happens when we evaluate the QF engine by=20=

> sending large amount of messages without throttle from an initiator to=20=

> an acceptor. The initiator will miss the heart beat after a certain=20
> period of time, and then it sends the test request to force a heart=20
> beat. After that miss it declares the session down by log off.
>
> -Yihu
>
> -----Original Message-----
> From: Joerg Thoennes [mailto:Joe...@ma...]
> Sent: Friday, July 23, 2004 4:54 AM
> To: Yihu Fang
> Cc: Patrick Flannery; qui...@li...
> Subject: Re: [Quickfix-developers] Heartbeat
>
> Hi Yihu, hi Patrick,
>
> Yihu wrote:
>
>> We have seen similar missed heartbeat behavior when using=20
>> SocketAcceptor > under heavy sustained message rate. It causes=20
>> reconnect and resend and > other undesired behavior.
>>
>> After we change to ThreadedSocketAcceptor and it has no problem ever=20=

>> since.
>
> Yihu, can you send us log files showing the same scenario using
> SocketAcceptor and ThreadedSocketAcceptor?
>
> Patrick wrote:
>
>> Is it possible that when many messages are being sent or received a
>> heartbeat gets drowned out causing a logout message to be generated?
>>
>> I have both acceptor and initiator ResetOnDiscconect and =
ResetOnLogout
>> set to Y, but I notice when the client starts up there are series of
>> onLogoff and onLogon messages and Reset Sequence number events before=20=

>> a > connection is made?  What could cause this?
>>
>> When the client sends the logout message an onLogout event is=20
>> generated > then an onLogon event the client can send messages as if=20=

>> they never
>> logged off, why would that happen?
>
> Could you please send log file (from both sides of the connecting FIX
> engines if possible) to have a more detailed look at this?
>
> Thanks, 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
>
>
>
> -----------------------------------------------------------------
>         Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
>
>
> -------------------------------------------------------
> 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_idG21&alloc_id=10040&op=3Dclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] Heartbeat

[Yihu F. <Yih...@re...>]

Joerg,

I don't have the logs with me anymore and will need some effort to recreate=
 it. Basically, it happens when we evaluate the QF engine by sending large =
amount of messages without throttle from an initiator to an acceptor. The i=
nitiator will miss the heart beat after a certain period of time, and then =
it sends the test request to force a heart beat. After that miss it declare=
s the session down by log off.

-Yihu

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Friday, July 23, 2004 4:54 AM
To: Yihu Fang
Cc: Patrick Flannery; qui...@li...
Subject: Re: [Quickfix-developers] Heartbeat

Hi Yihu, hi Patrick,

Yihu wrote:

> We have seen similar missed heartbeat behavior when using SocketAcceptor=
 > under heavy sustained message rate. It causes reconnect and resend and=
 > other undesired behavior.
>=20
> After we change to ThreadedSocketAcceptor and it has no problem ever sinc=
e.

Yihu, can you send us log files showing the same scenario using=20
SocketAcceptor and ThreadedSocketAcceptor?

Patrick wrote:

> Is it possible that when many messages are being sent or received a=20
> heartbeat gets drowned out causing a logout message to be generated?=20
>=20
> I have both acceptor and initiator ResetOnDiscconect and ResetOnLogout=20
> set to Y, but I notice when the client starts up there are series of=20
> onLogoff and onLogon messages and Reset Sequence number events before a=
 > connection is made?  What could cause this?
>=20
> When the client sends the logout message an onLogout event is generated=
 > then an onLogon event the client can send messages as if they never=20
> logged off, why would that happen?

Could you please send log file (from both sides of the connecting FIX=20
engines if possible) to have a more detailed look at this?

Thanks, 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



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

[Quickfix-developers] Reconnect problem.

[Shamanth <sha...@in...>]

Hi

We have a problem with disconnect.

We have a simulator (quickfix instance "acceptor") and a FIX client(also =
quickfix instance "initiator").

On the acceptor our starttime and endtime are
StartTime=3D00:00:00
EndTime=3D00:00:00

On the initiator our starttime and endtime are
StartTime=3D05:30:00   (IST =3D  GMT + 5:30)
EndTime=3D05:30:00   (IST: GMT + 5:30)

Also
CheckLatency=3DN
ResetOnDisconnect=3DN
ResetSeqNoOnLogon=3Dtrue

But the problem is the acceptor disconnects exactly at 00:00:00 GMT and =
does not reconnect. We have tried by changing the initiator start and =
end time to 06:00:00, and ResetSeqNoOnLogon to false. But this does not =
solve the problem.

Does any one know what could be the problem.

NOTE: Both initiator and simulator are sitting on the same machine.

thanks and regards
R Shamanth


>   NOTICE
> This e-mail message and any attachments, which may contain =
confidential information, are to be viewed solely by the intended =
recipient of Integral Development Corp.  If the reader of this message =
is not the intended recipient, you are hereby notified that any use, =
dissemination, distribution or copying of this communication is strictly =
prohibited.  If you have received this message in error, please =
immediately notify the sender and delete the mail and all attachments.
>=20

Re: [Quickfix-developers] Heartbeat

[Joerg T. <Joe...@ma...>]

Hi Yihu, hi Patrick,

Yihu wrote:

> We have seen similar missed heartbeat behavior when using SocketAcceptor 
> under heavy sustained message rate. It causes reconnect and resend and 
> other undesired behavior.
> 
> After we change to ThreadedSocketAcceptor and it has no problem ever since.

Yihu, can you send us log files showing the same scenario using 
SocketAcceptor and ThreadedSocketAcceptor?

Patrick wrote:

> Is it possible that when many messages are being sent or received a 
> heartbeat gets drowned out causing a logout message to be generated? 
> 
> I have both acceptor and initiator ResetOnDiscconect and ResetOnLogout 
> set to Y, but I notice when the client starts up there are series of 
> onLogoff and onLogon messages and Reset Sequence number events before a 
> connection is made?  What could cause this?
> 
> When the client sends the logout message an onLogout event is generated 
> then an onLogon event the client can send messages as if they never 
> logged off, why would that happen?

Could you please send log file (from both sides of the connecting FIX 
engines if possible) to have a more detailed look at this?

Thanks, 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

RE: [Quickfix-developers] Heartbeat

[Yihu F. <Yih...@re...>]

Patrick,

=20

Are you using SocketAcceptor or ThreadedSocketAcceptor?

=20

We have seen similar missed heartbeat behavior when using SocketAcceptor
under heavy sustained message rate. It causes reconnect and resend and
other undesired behavior.

=20

After we change to ThreadedSocketAcceptor and it has no problem ever
since.

=20

-Yihu

=20

  _____ =20

From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Patrick Flannery
Sent: Thursday, July 22, 2004 1:45 PM
To: qui...@li...
Subject: [Quickfix-developers] Heartbeat

=20

Oren,

Is it possible that when many messages are being sent or received a
heartbeat gets drowned out causing a logout message to be generated? =20

=20

I have both acceptor and initiator ResetOnDiscconect and ResetOnLogout
set to Y, but I notice when the client starts up there are series of
onLogoff and onLogon messages and Reset Sequence number events before a
connection is made?  What could cause this?

=20

When the client sends the logout message an onLogout event is generated
then an onLogon event the client can send messages as if they never
logged off, why would that happen?

=20

Thank you in advance for your time.=20

Patrick Flannery

  _____ =20

This email message is intended only for the addressee(s) and contains
information that may be confidential and/or=20
copyright.  If you are not the intended recipient please notify the
sender by reply email and immediately delete=20
this email. Use, disclosure or reproduction of this email by anyone
other than the intended recipient(s) is strictly=20
prohibited. No representation is made that this email or any attachments
are free of viruses. Virus scanning is=20
recommended and is the responsibility of the recipient.

Thank you.

  _____ =20

For more information on CTC, LLC please visit our website at
http://www.chicagotrading.com.


=20



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

[Quickfix-developers] Heartbeat

[Patrick F. <pat...@ch...>]

Oren,
Is it possible that when many messages are being sent or received a
heartbeat gets drowned out causing a logout message to be generated? =20
=20
I have both acceptor and initiator ResetOnDiscconect and ResetOnLogout =
set
to Y, but I notice when the client starts up there are series of =
onLogoff
and onLogon messages and Reset Sequence number events before a =
connection is
made?  What could cause this?
=20
When the client sends the logout message an onLogout event is generated =
then
an onLogon event the client can send messages as if they never logged =
off,
why would that happen?
=20
Thank you in advance for your time.=20
Patrick Flannery

-----------------------------------------------------------=20
This email message is intended only for the addressee(s)=20
and contains information that may be confidential and/or=20
copyright.  If you are not the intended recipient please=20
notify the sender by reply email and immediately delete=20
this email. Use, disclosure or reproduction of this email=20
by anyone other than the intended recipient(s) is strictly=20
prohibited. No representation is made that this email or=20
any attachments are free of viruses. Virus scanning is=20
recommended and is the responsibility of the recipient.

Thank you.
-----------------------------------------------------------=20

For more information on CTC, LLC please visit
our website at:=20

           http://www.chicagotrading.com.

[Quickfix-developers] quickfix 1.8.0 RPM's.

[Steve P. S. <ss...@st...>]

I've produced RPM's of quickfix 1.8.0 for fedora core 2.
Quickfix 1.7.1 had some problems with the autobreak tools so RPM's of
it were never made.

You can find the rpm's here:

http://www.steveshack.org/files/quickfix/quickfix-1.8.0-1.i386.rpm
http://www.steveshack.org/files/quickfix/quickfix-devel-1.8.0-1.i386.rpm
http://www.steveshack.org/files/quickfix/quickfix-debuginfo-1.8.0-1.i386.rpm

I'd appreciate hearing about any problems using these packages. In
particular the java api as it isn't tested.=20
--=20
--
Steve Paul Shack			        sshack at steveshack dot org
GPG Fingerprint:          22C5 195E 0060 9EAF 0DFC  D933 93DC 4BC9 C429 53F6
http://www.steveshack.org

Re: [Quickfix-developers] ExDestination missing in FIX41::OrderCancelRequest

[Oren M. <or...@qu...>]

If you just update the xml file, you will no longer reject these=20
messages.

--oren

On Jul 20, 2004, at 10:11 AM, Clark Sims wrote:

> I have a socketacceptor program based on the example program executor.=20=

> When I send a cancel order with flag 100 defined I get an error of the=20=

> form:
> <20040720-12:00:57, FIX.4.1:TW->CLIENT3, event>
> =A0 (Message 3307 Rejected: Tag not defined for this message type:100)
> Am I missing something?=A0 It is ok to specifiy exdestination on a=20
> cancelrequest, isn't it?
> =A0
> How dow I fix this? do I need to change the header file=20
> quickfix/fix41/OrderCancelRequest.h?=A0 do I also need to change the =
xml=20
> file?
> =A0
> Thanks in Advance,
> =A0
> Clark
>
> Clark Sims <cla...@ya...> wrote:
> It looks like the ExDestition is missing in FIX41::OrderCancelRequest
> I have to use the setField method instead of set
> =A0=A0=A0
>  FIX41::OrderCancelRequest message( arg1, arg2, arg4, arg5);
> =A0=A0=A0 message.set(FIX::OrderQty( _quantity));
> =A0=A0=A0 if (OutSymbolSfx.size() > 0) {
> =A0=A0=A0=A0=A0 message.set( FIX::SymbolSfx( OutSymbolSfx));
> =A0=A0=A0 }
> =A0=A0=A0 if (OutExDest.size() > 0)
>  =A0=A0=A0=A0=A0=A0/* message.set( FIX::ExDestination( OutExDest)); */
> =A0=A0=A0=A0=A0 message.setField( 100, OutExDest);
> =A0=A0=A0 }
>
>  Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
>
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!=

Re: [Quickfix-developers] ExDestination missing in FIX41::OrderCancelRequest

[Clark S. <cla...@ya...>]

I have a socketacceptor program based on the example program executor. When I send a cancel order with flag 100 defined I get an error of the form:

<20040720-12:00:57, FIX.4.1:TW->CLIENT3, event>
  (Message 3307 Rejected: Tag not defined for this message type:100)

Am I missing something?  It is ok to specifiy exdestination on a cancelrequest, isn't it?
 
How dow I fix this? do I need to change the header file quickfix/fix41/OrderCancelRequest.h?  do I also need to change the xml file?
 
Thanks in Advance,
 
Clark

Clark Sims <cla...@ya...> wrote:
It looks like the ExDestition is missing in FIX41::OrderCancelRequest
I have to use the setField method instead of set
    
FIX41::OrderCancelRequest message( arg1, arg2, arg4, arg5);
    message.set(FIX::OrderQty( _quantity));
    if (OutSymbolSfx.size() > 0) {
      message.set( FIX::SymbolSfx( OutSymbolSfx));
    }
    if (OutExDest.size() > 0) 
      /* message.set( FIX::ExDestination( OutExDest)); */
      message.setField( 100, OutExDest);
    }



---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

		
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!

Re: [Quickfix-developers] SocketInitiator prob

[Oren M. <or...@qu...>]

Well, that exception is thrown when it is trying to pull out a field=20
from the settings and it is unable to find it.  Normally the message=20
would be Configuration failed: [name of key] not defined.  But it looks=20=

like it is trying to pull out a setting using an empty string as the=20
key.  What version of QuickFIX are you using?

--oren

On Jul 20, 2004, at 1:43 AM, Jonas Bostrom wrote:

> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi
>
> I have been using VC++ ver of quickfix and that works fine..
> But now I want to implement a simple QuickFix Trading client in C#.=20
> Should not be a problem there.. But when I try to create the=20
> SocketInitiator object I get an exception : ""Configuration failed: =20=

> not defined"
>
> Cant understand why... The SessionSettings object seems to find the=20
> cfg file. Simple code is like this:
>
> try
> {
> SessionSettings settings =3D new =
SessionSettings("c:\\tradeclient.cfg");
> 				FileStoreFactory factory =3D new =
FileStoreFactory(settings);
> 				FileLogFactory logFactory =3D new =
FileLogFactory("output");
> 				MessageFactory messageFactory =3D new =
DefaultMessageFactory();
> 				m_application =3D new FixClientClass();
> 				m_initiator =3D new SocketInitiator( =
m_application, factory,=20
> settings,logFactory, messageFactory);
> 				m_initiator.start();
>
> }
> catch ( Exception e1 )
> {
> Console.WriteLine( e1 );
> }
>
> and the tradeclient file loos like this:
> [DEFAULT]
> ConnectionType=3Dinitiator
> HeartBtInt=3D30
> FileStorePath=3Dstore
> StartTime=3D00:00:00
> EndTime=3D00:00:00
> UseDataDictionary=3DN
> SocketConnectHost=3Dlocalhost
> SocketConnectPort=3D5001
>
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DCL
> TargetCompID=3DME
>
> The code is just in an Form class at the moment for testing, but that=20=

> should not be a prob???
>
> This is just driving me insane.. Otherwise QF works great in VC++..=20
> Thanx Oren...
>
> Cheers
>
> /Jonas
>
> _________________________________________________________________
> Bli f=F6r=E4lskad p=E5 MSN Dejting =
http://www.msn.se/dejting/default.asp
>
>
>
> -------------------------------------------------------
> 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=3D4721&alloc_id=3D10040&op=3Dclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] SocketInitiator prob

[Jonas B. <my_...@ho...>]

Hi

I have been using VC++ ver of quickfix and that works fine..
But now I want to implement a simple QuickFix Trading client in C#. Should 
not be a problem there.. But when I try to create the SocketInitiator object 
I get an exception : ""Configuration failed:  not defined"

Cant understand why... The SessionSettings object seems to find the cfg 
file. Simple code is like this:

try
{
SessionSettings settings = new SessionSettings("c:\\tradeclient.cfg");
				FileStoreFactory factory = new FileStoreFactory(settings);
				FileLogFactory logFactory = new FileLogFactory("output");
				MessageFactory messageFactory = new DefaultMessageFactory();
				m_application = new FixClientClass();
				m_initiator = new SocketInitiator( m_application, factory, 
settings,logFactory, messageFactory);
				m_initiator.start();

}
catch ( Exception e1 )
{
Console.WriteLine( e1 );
}

and the tradeclient file loos like this:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
FileStorePath=store
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=N
SocketConnectHost=localhost
SocketConnectPort=5001

[SESSION]
BeginString=FIX.4.2
SenderCompID=CL
TargetCompID=ME

The code is just in an Form class at the moment for testing, but that should 
not be a prob???

This is just driving me insane.. Otherwise QF works great in VC++.. Thanx 
Oren...

Cheers

/Jonas

_________________________________________________________________
Bli förälskad på MSN Dejting http://www.msn.se/dejting/default.asp

Re: [Quickfix-developers] Another Disconnect Issue

[Oren M. <or...@qu...>]

The settings look ok.  We do have sessions that span over a day in our 
tests, but I'll plug in these numbers to see if there is some problem.

--oren

On Jul 16, 2004, at 12:18 PM, Jon Dahl wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> We could possibly have a 23 hour trading session and I have come upon 
> an
> issue with the Session Management. If a Session is created at 4:50 PM 
> and
> the initial connection for that Session is at 3AM the next day, QF 
> drops
> the connection and resets the Session. Subsequently, the client can
> connect.
>
> So it looks like to me, QF has a problem when a Session Time can span 
> more
> than one Calendar date. I thought it would be able to if the StartTime 
> and
> EndTime in the configuration file were set correctly but it doesn't 
> help.
>
> We are central time here so we are -5 w/ Daylight Savings Time and 
> UTCTime.
>
> I'm setting StartTime=21:55:00 and EndTime=21:30:00 in the 
> configuration
> file.
>
> Any problems with those settings ?
>
> Thanks,
>
> JD
>
>
>
>
>
> -------------------------------------------------------
> 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=4721&alloc_id=10040&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Another Disconnect Issue

[Jon D. <jd...@wi...>]

We could possibly have a 23 hour trading session and I have come upon an
issue with the Session Management. If a Session is created at 4:50 PM and
the initial connection for that Session is at 3AM the next day, QF drops
the connection and resets the Session. Subsequently, the client can
connect.

So it looks like to me, QF has a problem when a Session Time can span more
than one Calendar date. I thought it would be able to if the StartTime and
EndTime in the configuration file were set correctly but it doesn't help.

We are central time here so we are -5 w/ Daylight Savings Time and UTCTime.

I'm setting StartTime=21:55:00 and EndTime=21:30:00 in the configuration
file.

Any problems with those settings ?

Thanks,

JD

[Quickfix-developers] Interface quickFIX with Visual Basic

[Jose M. <Jos...@db...>]

Hello all,
=20
I am writing an application that receives a stream of prices using =
quickFIX.
Based on the tradeclient sample I have created a small C++ class that =
allows me to 'subscribe' to a price feed and receive prices.  The =
problem is that the final consumer of those prices is an application =
written in Visual Basic and I am not quite sure about the best way to =
interface the two.
=20
I thought that one idea would be to create a COM interface for the =
tradeclient C++ class that could raise events when it received a price.  =
In this way any COM enabled language could use the component.  I was =
wondering if any of you have already done something similar already and =
could share their experience.
=20
Raising events in COM/C++ does not seem very easy to achieve, =
particularly when raising events on a different thread (even more =
difficult as I haven't got much experience of COM/C++ development).  I =
am not too sure either whether a COM DLL or COM EXE would be best.
=20
Regarding the threading, does anyone know how many threads quickFIX uses =
and which one it uses for calls to the FIX::Application and =
FIX::MessageCracker methods?
=20
I would be glad to hear other approaches to interface the C++ quickFIX =
wrapper and Visual Basic.
=20
Thanks
Jose

_______________________________________________
Visit our website at http://www.dbfs.co.uk
This email may contain confidential information, if you are not the =
intended recipient for this email, please contact ad...@db....
This email has been scanned for viruses using BitDefender v1.6 for =
exchange, and Norton anti-virus software.  DBFS have taken all =
reasonable steps to ensure this email and/or its attachments are =
virus-free, but the recipient should verify the contents are safe before =
use.

Re: [Quickfix-developers] Details for Solaris / SunPRO 5.3 build

[Caleb E. <cal...@gm...>]

OK, here's an optimization to Field::calculate which improves the
results from the "pt" application by a healthy amount.  When possible,
it uses a fixed-size char buffer and sprintf instead of building up a
string with operator+.  It falls back to the old behavior if the fixed
buffer is too small.

I also changed the checksum calculation to use std::accumulate, which
probably has no real impact on anything other than lines-of-code.

---8<---
  void calculate()
  {
      char buf[64];

      // If the largest possible representation of the field ID (11
      // digits) '=' value '\001' can fit in the buffer, use sprintf
      if (13 + m_string.length () < sizeof (buf))
          {
          m_length = sprintf (buf, "%d=%*.*s\001", m_field,
                              m_string.length (), m_string.length (),
                              m_string.data ());
          m_data.assign (buf, m_length);
          }
      else
          {
          m_data = IntConvertor::convert(m_field) + "=" + m_string + "\001";
          m_length = m_data.length ();
          }

    const char* iter = m_data.data ();
    m_total = std::accumulate (iter, iter + m_length, 0);
  }
---8<---

Before the change:
Converting integers to strings: 
    num: 10000, seconds: 0.006, num_per_second: 1.66667e+06
Converting strings to integers: 
    num: 10000, seconds: 0.001, num_per_second: 1e+07
Converting doubles to strings: 
    num: 10000, seconds: 0.019, num_per_second: 526316
Converting strings to doubles: 
    num: 10000, seconds: 0.028, num_per_second: 357143
Creating Heartbeat messages: 
    num: 10000, seconds: 0.113, num_per_second: 88495.6
Serializing Heartbeat messages to strings: 
    num: 10000, seconds: 0.155, num_per_second: 64516.1
Serializing Heartbeat messages from strings: 
    num: 10000, seconds: 0.275, num_per_second: 36363.6
Creating NewOrderSingle messages: 
    num: 10000, seconds: 0.415, num_per_second: 24096.4
Serializing NewOrderSingle messages to strings: 
    num: 10000, seconds: 0.41, num_per_second: 24390.2
Serializing NewOrderSingle messages from strings: 
    num: 10000, seconds: 0.585, num_per_second: 17094
Creating QuoteRequest messages: 
    num: 10000, seconds: 4.83, num_per_second: 2070.39
Serializing QuoteRequest messages to strings: 
    num: 10000, seconds: 0.646, num_per_second: 15479.9
Serializing QuoteRequest messages from strings: 
    num: 10000, seconds: 4.386, num_per_second: 2279.98
Reading fields from QuoteRequest message: 
    num: 10000, seconds: 1.374, num_per_second: 7278.02
Storing NewOrderSingle messages: 
    num: 10000, seconds: 0.576, num_per_second: 17361.1
Validating NewOrderSingle messages with no data dictionary: 
    num: 10000, seconds: 0.071, num_per_second: 140845
Validating NewOrderSingle messages with data dictionary: 
    num: 10000, seconds: 0.23, num_per_second: 43478.3

After:
Converting integers to strings: 
    num: 10000, seconds: 0.007, num_per_second: 1.42857e+06
Converting strings to integers: 
    num: 10000, seconds: 0.001, num_per_second: 1e+07
Converting doubles to strings: 
    num: 10000, seconds: 0.02, num_per_second: 500000
Converting strings to doubles: 
    num: 10000, seconds: 0.027, num_per_second: 370370
Creating Heartbeat messages: 
    num: 10000, seconds: 0.08, num_per_second: 125000
Serializing Heartbeat messages to strings: 
    num: 10000, seconds: 0.118, num_per_second: 84745.8
Serializing Heartbeat messages from strings: 
    num: 10000, seconds: 0.159, num_per_second: 62893.1
Creating NewOrderSingle messages: 
    num: 10000, seconds: 0.255, num_per_second: 39215.7
Serializing NewOrderSingle messages to strings: 
    num: 10000, seconds: 0.251, num_per_second: 39840.6
Serializing NewOrderSingle messages from strings: 
    num: 10000, seconds: 0.355, num_per_second: 28169
Creating QuoteRequest messages: 
    num: 10000, seconds: 3.131, num_per_second: 3193.87
Serializing QuoteRequest messages to strings: 
    num: 10000, seconds: 0.62, num_per_second: 16129
Serializing QuoteRequest messages from strings: 
    num: 10000, seconds: 2.846, num_per_second: 3513.7
Reading fields from QuoteRequest message: 
    num: 10000, seconds: 1.172, num_per_second: 8532.42
Storing NewOrderSingle messages: 
    num: 10000, seconds: 0.633, num_per_second: 15797.8
Validating NewOrderSingle messages with no data dictionary: 
    num: 10000, seconds: 0.042, num_per_second: 238095
Validating NewOrderSingle messages with data dictionary: 
    num: 10000, seconds: 0.189, num_per_second: 52910.1


-- 
Caleb Epstein
cal...@gm...

[Quickfix-developers] Incorrect Data Format for value

[Patrick F. <pat...@ch...>]

Oren,
            I am using both a QuickFIX acceptor and initiator.  =
Sometimes
the acceptor reports an error of incorrect data format for value with a =
date
time value something like 20040714-12:55:30 in the error message.  =
However
looking at the received log I see a date time value that looks more like
20040714-12:55:30.200.  I only seem to receive the error near logon, =
once
logged in I am able to send other messages with the same date time =
format as
the message reported as an error.  Once the Incorrect Data Format for =
Value
Error is given the connection is dropped.  Could the date formatted like
this cause that error?  Thank you in advance for your help.
Patrick
=20

-----------------------------------------------------------=20
This email message is intended only for the addressee(s)=20
and contains information that may be confidential and/or=20
copyright.  If you are not the intended recipient please=20
notify the sender by reply email and immediately delete=20
this email. Use, disclosure or reproduction of this email=20
by anyone other than the intended recipient(s) is strictly=20
prohibited. No representation is made that this email or=20
any attachments are free of viruses. Virus scanning is=20
recommended and is the responsibility of the recipient.

Thank you.
-----------------------------------------------------------=20

For more information on CTC, LLC please visit
our website at:=20

           http://www.chicagotrading.com.

Re: [Quickfix-developers] Details for Solaris / SunPRO 5.3 build

[Oren M. <or...@qu...>]

Actually, the speed improvement for regular messages was more 
significant than I thought, so the performance has improved all around.

I tried reserving space on the m_data member, but this actually hurt 
performance a bit.  The idea is good, but I figured this technique 
might be more effective on larger strings.  So instead instead I tried 
reserving space in the calculateString call, and this made a huge 
difference.  I can now do a to string on the quote messages at a rate 
of 27,000+ per second (up from the previous 23,000+).  Right now I'm 
just making a simple assumption that each field will average about 20 
characters.  Maybe this can be made smarter, but I think this is a 
reasonable assumption for most messages.  I'm happy to err on the side 
of reserving too much.  Speed versus size is a good tradeoff here since 
messages tend to be temporary objects, and generally aren't kept around 
in large quantities.

I've checked these changes if anyone wants to take a look at what was 
done and maybe suggest some other ideas.

--oren

On Jul 13, 2004, at 4:01 PM, Caleb Epstein wrote:

> On Tue, 13 Jul 2004 13:54:50 -0500, Oren Miller 
> <or...@qu...> wrote:
>
>> I noticed you replaced some sprintf calls with ostringstreams.  We
>> actually used to do this, but performance testing revealed that the
>> sprintf calls were considerably faster.  I don't remember the exact
>> numbers, but I believe using the sprintf calls made message
>> construction something on the order of 10% faster.  That's pretty
>> significant.  Is there a particular reason you changed these?
>
>      On Linux I've definitely found this to be the case.  Using
> sprintf to do the formatting and just sending char*'s to the iostreams
> is considerably faster.  You can optimize even further by collecting
> the return value of sprintf and using ostream::write (const char*,
> streamsize) instead of ostream::operator<<, which will avoid at least
> a strlen call.  Taken together, I think these will give you a good
> deal more than a 10% performance improvement.
>
>      I think there is some additional optimization that could be done
> inside the QF Field class by reserving an appropriate amount of
> storage for m_data in the setString method before assigning to it.  We
> have found std::string::append to be a bottleneck when doing this sort
> of thing on Linux.  It would have to be a bit of a guesstimate though,
> since you don't know the number of digits in the ASCII representation
> of the tag.
>
> -- 
> Caleb Epstein
> cal...@gm...
>

Re: [Quickfix-developers] Details for Solaris / SunPRO 5.3 build

[Oren M. <or...@qu...>]

Yeah, I think there is quite a few things that can be done.  I modified 
the method declaration of calculate string from:

std::string calculateString()

to:

std::string& calculateString( std::string& )

This gave some interesting results.  For normal messages this gave a 
small to negligible performance improvement to the messages toString() 
implementation.  I rather expected this.  But, for messages with 
repeating groups (MassQuote messages with 10 groups), the performance 
of toString() improved something like 80-90%.  Previously the machine I 
was benchmarking was able to convert these messages to strings at a 
rate of about 12,000+ per second, after the change it was 22-23000+ per 
second.

It would be nice to see if we can focus on improving message 
construction for messages with repeating groups.  Although we can 
convert these to strings rather quickly, I was only able to construct 
1700 of these messages objects per second on the same hardware.  This 
is actually quite good considering the size of the messages, but I 
think more can be done.  One of the reasons repeating groups is slower 
is that they have the odd requirement of having the fields sorted in a 
specific order.  If we are talking to an engine that doesn't care about 
this (say, for instance, QuickFIX), it would be nice to construct the 
messages without the need for this overhead.

On Jul 13, 2004, at 4:01 PM, Caleb Epstein wrote:

> On Tue, 13 Jul 2004 13:54:50 -0500, Oren Miller 
> <or...@qu...> wrote:
>
>> I noticed you replaced some sprintf calls with ostringstreams.  We
>> actually used to do this, but performance testing revealed that the
>> sprintf calls were considerably faster.  I don't remember the exact
>> numbers, but I believe using the sprintf calls made message
>> construction something on the order of 10% faster.  That's pretty
>> significant.  Is there a particular reason you changed these?
>
>      On Linux I've definitely found this to be the case.  Using
> sprintf to do the formatting and just sending char*'s to the iostreams
> is considerably faster.  You can optimize even further by collecting
> the return value of sprintf and using ostream::write (const char*,
> streamsize) instead of ostream::operator<<, which will avoid at least
> a strlen call.  Taken together, I think these will give you a good
> deal more than a 10% performance improvement.
>
>      I think there is some additional optimization that could be done
> inside the QF Field class by reserving an appropriate amount of
> storage for m_data in the setString method before assigning to it.  We
> have found std::string::append to be a bottleneck when doing this sort
> of thing on Linux.  It would have to be a bit of a guesstimate though,
> since you don't know the number of digits in the ASCII representation
> of the tag.
>
> -- 
> Caleb Epstein
> cal...@gm...
>