quickfix-users — QuickFIX user support

RE: [Quickfix-users] Problem with logon in linux

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

Hi Joerg

We found the problem. There was a difference in system time between the =
server and the client machines that we were using. They were off by =
about 5mins.=20
So we added this entry into the client's configuration file

CheckLatency=3DN

and now it works fine.=20
We had faced this problem in both 1.7.0 an 1.7.1, with this entry it is =
working fine in both the versions.
thanks anyway for the reply.

with regards
R Shamanth

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]
Sent: Wednesday, June 02, 2004 2:36 PM
To: Shamanth
Cc: qui...@li...
Subject: Re: [Quickfix-users] Problem with logon in linux


 From a previous message, I see that you probably still use QF 1.7.0.=20
Could you upgrade to QF 1.7.1? Then the event logging would be more=20
verbose in the case of disconnects.

> I am having problems while logging into a linux box.

Our FIX servers runs on a Linux box, and our clients connect from Linux, =

Solaris and Windows machines.

> 1) I have a server and a client program. if both these components are=20
> sitting on the same windows machine or even different windows machine=20
> then everything works fine.
>=20
> Also if both these components sit on the same linux box, then also=20
> everything works fine.
>=20
> But the problem occurs when I have the client running on a different=20
> linux or windows box. I have given the scenarios below.
>=20
> * Server          Client          status *
> windows1        windows1        working
> windows1        windows2        working
> linux1          linux1          working
> linux1          linux2          not working
> linux1          windows1        not working
>=20
> I get the following error on the server console.
> <20040531-10:17:04, FIX.4.3:TW->CLIENT1, incoming>
>  =20
> =
(8=3DFIX.4.3?9=3D65?35=3DA?34=3D22?49=3DCLIENT1?52=3D20040531-09:14:59.00=
0?56=3DTW?98=3D0?108=3D30?10=3D201)=20
> <20040531-10:17:04, FIX.4.3:TW->CLIENT1, event>
>   (Disconnecting)
>=20

Tag 35=3D22 indicates that you already sent some messages. Perhaps the=20
session is disconnected because the sequence number is to low. Try=20
clearing the queues on both sides and restart.

Also there may be a time synchronization issue. Check this to=20
configuration properties:

CheckLatency  	If set to Y, messages must be received from the=20
counterparty within a defined number of seconds (see MaxLatency). It is=20
useful to turn this off if a system uses localtime for it's timestamps=20
instead of GMT.

Values: {Y, N }, Default: Y


MaxLatency 	If CheckLatency is set to Y, this defines the number of=20
seconds latency allowed for a message to be processed.

Values: positive integer, Default: 120

Cheers, J=F6rg

>=20
> On the client console, I see this error
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Created session)
> SK-Run
>=20
> 1) Enter Order
> 2) Cancel Order
> 3) Replace Order
> 4) Market data test
> 5) Load Test
> 6) Quit
> Action:
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Connecting to gfinetap1 on port 5022)
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Connection succeeded)
> Debug toAdmin called=20
> =
8=3DFIX.4.3?9=3D65?35=3DA?34=3D23?49=3DCLIENT1?52=3D20040531-09:15:30.0
> 00?56=3DTW?98=3D0?108=3D30?10=3D192?
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, outgoing>
>  =20
> =
(8=3DFIX.4.3?9=3D65?35=3DA?34=3D23?49=3DCLIENT1?52=3D20040531-09:15:30.00=
0?56=3DTW?98=3D0?108=3D=20
>=20
> 30?10=3D192?)
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
>   (Initiated logon request)
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
>   (Disconnecting)      =20
>=20
> The server and clients are communicating, but they are unable to =
logon.
>=20
> any inputs, about what I am doing wrong.
>=20
> with regards
> R Shamanth
>=20
> */ /*//  *** NOTICE *
>=20
> This e-mail message and any attachments, which may contain =
confidential=20
> information, are to be viewed solely by the intended recipient of=20
> Integral Development Corp.  If the reader of this message is not the=20
> intended recipient, you are hereby notified that any use, =
dissemination,=20
> distribution or copying of this communication is strictly prohibited.  =

> If you have received this message in error, please immediately notify=20
> the sender and delete the mail and all attachments.
>=20


--=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

Re: [Quickfix-users] Problem with logon in linux

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

 From a previous message, I see that you probably still use QF 1.7.0. 
Could you upgrade to QF 1.7.1? Then the event logging would be more 
verbose in the case of disconnects.

> I am having problems while logging into a linux box.

Our FIX servers runs on a Linux box, and our clients connect from Linux, 
Solaris and Windows machines.

> 1) I have a server and a client program. if both these components are 
> sitting on the same windows machine or even different windows machine 
> then everything works fine.
> 
> Also if both these components sit on the same linux box, then also 
> everything works fine.
> 
> But the problem occurs when I have the client running on a different 
> linux or windows box. I have given the scenarios below.
> 
> * Server          Client          status *
> windows1        windows1        working
> windows1        windows2        working
> linux1          linux1          working
> linux1          linux2          not working
> linux1          windows1        not working
> 
> I get the following error on the server console.
> <20040531-10:17:04, FIX.4.3:TW->CLIENT1, incoming>
>   
> (8=FIX.4.3?9=65?35=A?34=22?49=CLIENT1?52=20040531-09:14:59.000?56=TW?98=0?108=30?10=201) 
> <20040531-10:17:04, FIX.4.3:TW->CLIENT1, event>
>   (Disconnecting)
> 

Tag 35=22 indicates that you already sent some messages. Perhaps the 
session is disconnected because the sequence number is to low. Try 
clearing the queues on both sides and restart.

Also there may be a time synchronization issue. Check this to 
configuration properties:

CheckLatency  	If set to Y, messages must be received from the 
counterparty within a defined number of seconds (see MaxLatency). It is 
useful to turn this off if a system uses localtime for it's timestamps 
instead of GMT.

Values: {Y, N }, Default: Y


MaxLatency 	If CheckLatency is set to Y, this defines the number of 
seconds latency allowed for a message to be processed.

Values: positive integer, Default: 120

Cheers, Jörg

> 
> On the client console, I see this error
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Created session)
> SK-Run
> 
> 1) Enter Order
> 2) Cancel Order
> 3) Replace Order
> 4) Market data test
> 5) Load Test
> 6) Quit
> Action:
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Connecting to gfinetap1 on port 5022)
> <20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
>   (Connection succeeded)
> Debug toAdmin called 
> 8=FIX.4.3?9=65?35=A?34=23?49=CLIENT1?52=20040531-09:15:30.0
> 00?56=TW?98=0?108=30?10=192?
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, outgoing>
>   
> (8=FIX.4.3?9=65?35=A?34=23?49=CLIENT1?52=20040531-09:15:30.000?56=TW?98=0?108= 
> 
> 30?10=192?)
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
>   (Initiated logon request)
> <20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
>   (Disconnecting)       
> 
> The server and clients are communicating, but they are unable to logon.
> 
> any inputs, about what I am doing wrong.
> 
> with 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.
> 


-- 
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-users] questions about MySQLStore & MySQLLog

[Oren M. <om...@ri...>]

fromAdmin will give you the administrative messages such as the=20
Heartbeat.

Breaking up the message into fields may be more work than you need to=20
do if you just plan on using a GUI to view the messages.  Instead you=20
may consider sticking the raw string into the database like the message=20=

store does.  You can create this string by calling toString() on the=20
message, and reconstruct it from the database using fromString().  If=20
you plan on doing queries based on the contents of certain fields, then=20=

you may want those field stored separately as well.

--oren

On Jun 1, 2004, at 12:37 PM, Jean Zhong wrote:

> Thank you for the reply.
>
> I plan to implement a database GUI to observe the
> messages much easiler. So, I wanna break down the
>  message into several interesting fields and save them
>  into a database.
>
> I also thought about to implement the database through
>  the callback functions in Application. I am just not
>  sure, which callback function can get heartbeat and
>  event messages.
>
> Thank you.
>
> Jean
>
>  --- Oren Miller <om...@ri...> wrote:
>  > MessageLog does not store Message objects, and the
>  > Store only store
> > messages being sent out, not ones coming in.=A0 Is
>  > there a reason you
> > need to query for these messages instead of just
>  > storing the
> > information you want as they come through the
>  > fromApp callback?
>  >
> > On Jun 1, 2004, at 11:23 AM, Jean Zhong wrote:
>  >
> > > Hi, Guys
>  > >
>  > > I am trying to build a database for the fix
>  > messages.
>  > >
>  > > I plan to decompose each fix message and save
>  > several
>  > >=A0 interesting fields into the table, so I am
>  > thinking if
>  > >=A0 there is a method to access the Message object
>  > from
>  > >=A0 MySQLLog and MySQLStore.
>  > >
>  > > I took a look on the MySQLLog class, MySQLStore
>  > class,
>  > >=A0 MessageStore class and LogFactory class, but I
>  > didn't
>  > >=A0 figure out how to get the instance of Message
>  > object
>  > >=A0 from these classes.
>  > >
>  > > Do you have any idea about this?
>  > >
>  > > Thanks a lot.
>  > >
>  > > Jean
>  > >=A0 =A0=A0
>  > >
>  > >
>  > >
>  > >
>  > >=A0 =A0=A0=A0=A0=A0=A0=A0
>  > >=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
>  > >=A0 __________________________________
> > > Do you Yahoo!?
>  > >=A0 Friends.=A0 Fun.=A0 Try the all-new Yahoo! Messenger.
>  > >=A0 http://messenger.yahoo.com/
> > >
>  > >
>  > >
>  > >
>  >
>  -------------------------------------------------------
>  > >=A0 This SF.Net email is sponsored by: Oracle 10g
>  > >=A0 Get certified on the hottest thing ever to hit
>  > the market... Oracle
> > > 10g.
>  > > Take an Oracle 10g class now, and we'll give you
>  > the exam FREE.
>  > >
> >
>  http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> > > _______________________________________________
> > > Quickfix-users mailing list
>  > >=A0 Qui...@li...
> > >
>  >
>  https://lists.sourceforge.net/lists/listinfo/quickfix-users
>  >
>
>
>
>  =A0=A0=A0=A0=A0=A0=A0
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
>  __________________________________
> Do you Yahoo!?
>  Friends.=A0 Fun.=A0 Try the all-new Yahoo! Messenger.
>  http://messenger.yahoo.com/

Re: [Quickfix-users] questions about MySQLStore & MySQLLog

[Jean Z. <to_...@ya...>]

Thank you for the reply.

I plan to implement a database GUI to observe the
messages much easiler. So, I wanna break down the
message into several interesting fields and save them
into a database.

I also thought about to implement the database through
the callback functions in Application. I am just not
sure, which callback function can get heartbeat and
event messages.

Thank you.

Jean 

--- Oren Miller <om...@ri...> wrote:
> MessageLog does not store Message objects, and the
> Store only store 
> messages being sent out, not ones coming in.  Is
> there a reason you 
> need to query for these messages instead of just
> storing the 
> information you want as they come through the
> fromApp callback?
> 
> On Jun 1, 2004, at 11:23 AM, Jean Zhong wrote:
> 
> > Hi, Guys
> >
> > I am trying to build a database for the fix
> messages.
> >
> > I plan to decompose each fix message and save
> several
> >  interesting fields into the table, so I am
> thinking if
> >  there is a method to access the Message object
> from
> >  MySQLLog and MySQLStore.
> >
> > I took a look on the MySQLLog class, MySQLStore
> class,
> >  MessageStore class and LogFactory class, but I
> didn't
> >  figure out how to get the instance of Message
> object
> >  from these classes.
> >
> > Do you have any idea about this?
> >
> > Thanks a lot.
> >
> > Jean
> >    
> >
> >
> >
> >
> >         
> >                 
> >  __________________________________
> > Do you Yahoo!?
> >  Friends.  Fun.  Try the all-new Yahoo! Messenger.
> >  http://messenger.yahoo.com/
> >
> >
> >
> >
>
-------------------------------------------------------
> >  This SF.Net email is sponsored by: Oracle 10g
> >  Get certified on the hottest thing ever to hit
> the market... Oracle 
> > 10g.
> > Take an Oracle 10g class now, and we'll give you
> the exam FREE.
> > 
>
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Quickfix-users mailing list
> >  Qui...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: [Quickfix-users] questions about MySQLStore & MySQLLog

[Oren M. <om...@ri...>]

MessageLog does not store Message objects, and the Store only store=20
messages being sent out, not ones coming in.  Is there a reason you=20
need to query for these messages instead of just storing the=20
information you want as they come through the fromApp callback?

On Jun 1, 2004, at 11:23 AM, Jean Zhong wrote:

> Hi, Guys
>
> I am trying to build a database for the fix messages.
>
> I plan to decompose each fix message and save several
>  interesting fields into the table, so I am thinking if
>  there is a method to access the Message object from
>  MySQLLog and MySQLStore.
>
> I took a look on the MySQLLog class, MySQLStore class,
>  MessageStore class and LogFactory class, but I didn't
>  figure out how to get the instance of Message object
>  from these classes.
>
> Do you have any idea about this?
>
> Thanks a lot.
>
> Jean
>  =A0=A0
>
>
>
>
>  =A0=A0=A0=A0=A0=A0=A0
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
>  __________________________________
> Do you Yahoo!?
>  Friends.=A0 Fun.=A0 Try the all-new Yahoo! Messenger.
>  http://messenger.yahoo.com/
>
>
>
> -------------------------------------------------------
>  This SF.Net email is sponsored by: Oracle 10g
>  Get certified on the hottest thing ever to hit the market... Oracle=20=

> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
>  http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Quickfix-users mailing list
>  Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

[Quickfix-users] questions about MySQLStore & MySQLLog

[Jean Z. <to_...@ya...>]

Hi, Guys

I am trying to build a database for the fix messages.

I plan to decompose each fix message and save several
interesting fields into the table, so I am thinking if
there is a method to access the Message object from
MySQLLog and MySQLStore.

I took a look on the MySQLLog class, MySQLStore class,
MessageStore class and LogFactory class, but I didn't
figure out how to get the instance of Message object
from these classes.

Do you have any idea about this?

Thanks a lot.

Jean
   



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: [Quickfix-users] Could not get the persisting connection to the client on linux

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

The likely problem you guys are having is nothing to do with operating =20=

systems, but whether the clocks on the machines are synchronized.  =20
QuickFIX will not allow (by default) a connection if the clocks are not =20=

synchronized within 2 minutes of each other.  You're options are to =20
either synchronize the clocks on your machines (I would recommend using =20=

ntp on all your boxes), or disable the synchronization check by adding =20=

the setting CheckLatency=3DN

--oren

On May 31, 2004, at 5:42 AM, Ramakrishna Naga wrote:

> Hi:
>
> =A0
>
> I could not get the persisting connection to the client running on =20
> linux box attempting to connect to the remote server running on either =
=20
> linux or windows. The connection always gets disconnected. Please =20
> advise.
>
> =A0
>
> Following are the details:
>
> =A0
>
> 1. Using FIX 4.3
>
> 2. Using QuickFIX 1.7.1
>
> 3. server1 has QuickFIX1.7.1 installed and =93run_executor_java=94 is =20=

> running
>
> 4. server2 has QuickFIX1.7.1 installed and is used to connect to =20
> server1 using =93run_tradeclient=94
>
> 5. contents of executor.cfg on server1:
>
> [DEFAULT]
>
> ConnectionType=3Dacceptor
>
> SocketAcceptPort=3D5001
>
> FileStorePath=3Dstore
>
> StartTime=3D00:00:00
>
> EndTime=3D00:00:00
>
> =A0
>
> [SESSION]
>
> BeginString=3DFIX.4.3
>
> SenderCompID=3DTW
>
> TargetCompID=3DCLIENT1
>
> DataDictionary=3D../spec/FIX43.xml
>
> =A0
>
> [SESSION]
>
> BeginString=3DFIX.4.3
>
> SenderCompID=3DTW
>
> TargetCompID=3DCLIENT2
>
> DataDictionary=3D../spec/FIX43.xml
>
> 6. contents of =A0=93tradeclient.cfg=94 on server2:
>
> [DEFAULT]
>
> ConnectionType=3Dinitiator
>
> HeartBtInt=3D30
>
> FileStorePath=3Dstore
>
> FileLogPath=3Dlogs
>
> StartTime=3D06:00:00
>
> EndTime=3D06:00:00
>
> UseDataDictionary=3DN
>
> SocketConnectHost=3Dserver1
>
> SocketConnectPort=3D5001
>
> =A0
>
> [SESSION]
>
> BeginString=3DFIX.4.3
>
> SenderCompID=3DCLIENT1
>
> TargetCompID=3DTW
>
> =A0
>
> [SESSION]
>
> BeginString=3DFIX.4.3
>
> SenderCompID=3DCLIENT2
>
> TargetCompID=3DTW
>
> 7. Output on the server console:
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT1, incoming>
>
> =A0 =20
> (8=3DFIX.4.39=3D6635=3DA34=3D16949=3DCLIENT152=3D20040531-10:28:=20
> 06.77356=3DTW98=3D0108=3D3010=3D012)
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT1, event>
>
> =A0 (Tried to send a reject while not logged on)
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT1, event>
>
> =A0 (Disconnecting)
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT2, incoming>
>
> =A0 =20
> (8=3DFIX.4.39=3D6635=3DA34=3D24249=3DCLIENT252=3D20040531-10:28:=20
> 06.77356=3DTW98=3D0108=3D3010=3D005)
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT2, event>
>
> =A0 (Tried to send a reject while not logged on)
>
> <20040531-10:19:41, FIX.4.3:TW->CLIENT2, event>
>
> =A0 (Disconnecting)
>
> 8. Output on the client console:
>
> 1) Enter Order
>
> 2) Cancel Order
>
> 3) Replace Order
>
> 4) Market data test
>
> 5) Quit
>
> Action:
>
>  Logoff - FIX.4.3:CLIENT1->TW
>
> =A0
>
> Logoff - FIX.4.3:CLIENT2->TW
>
> =A0
>
> Logoff - FIX.4.3:CLIENT1->TW
>
> =A0
>
> Logoff - FIX.4.3:CLIENT2->TW
>
> =A0
>
> TIA
>
> =A0
>
> Regards,
>
> RK
>
> =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. 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. If you have received this message in error, =20
> please immediately notify the sender and delete the mail and all =20
> attachments.
>
> =A0

[Quickfix-users] Could not get the persisting connection to the client on linux

[Ramakrishna N. <Ram...@in...>]

Hi:
=20
I could not get the persisting connection to the client running on linux =
box attempting to connect to the remote server running on either linux =
or windows. The connection always gets disconnected. Please advise.
=20
Following are the details:
=20
1. Using FIX 4.3
2. Using QuickFIX 1.7.1
3. server1 has QuickFIX1.7.1 installed and "run_executor_java" is =
running
4. server2 has QuickFIX1.7.1 installed and is used to connect to server1 =
using "run_tradeclient"
5. contents of executor.cfg on server1:
[DEFAULT]
ConnectionType=3Dacceptor
SocketAcceptPort=3D5001
FileStorePath=3Dstore
StartTime=3D00:00:00
EndTime=3D00:00:00
=20
[SESSION]
BeginString=3DFIX.4.3
SenderCompID=3DTW
TargetCompID=3DCLIENT1
DataDictionary=3D../spec/FIX43.xml
=20
[SESSION]
BeginString=3DFIX.4.3
SenderCompID=3DTW
TargetCompID=3DCLIENT2
DataDictionary=3D../spec/FIX43.xml
6. contents of  "tradeclient.cfg" on server2:
[DEFAULT]
ConnectionType=3Dinitiator
HeartBtInt=3D30
FileStorePath=3Dstore
FileLogPath=3Dlogs
StartTime=3D06:00:00
EndTime=3D06:00:00
UseDataDictionary=3DN
SocketConnectHost=3Dserver1
SocketConnectPort=3D5001
=20
[SESSION]
BeginString=3DFIX.4.3
SenderCompID=3DCLIENT1
TargetCompID=3DTW
=20
[SESSION]
BeginString=3DFIX.4.3
SenderCompID=3DCLIENT2
TargetCompID=3DTW
7. Output on the server console:
<20040531-10:19:41, FIX.4.3:TW->CLIENT1, incoming>
  =
(8=3DFIX.4.39=3D6635=3DA34=3D16949=3DCLIENT152=3D20040531-10:28:06.77356=3D=
TW98=3D0108=3D3010=3D012)
<20040531-10:19:41, FIX.4.3:TW->CLIENT1, event>
  (Tried to send a reject while not logged on)
<20040531-10:19:41, FIX.4.3:TW->CLIENT1, event>
  (Disconnecting)
<20040531-10:19:41, FIX.4.3:TW->CLIENT2, incoming>
  =
(8=3DFIX.4.39=3D6635=3DA34=3D24249=3DCLIENT252=3D20040531-10:28:06.77356=3D=
TW98=3D0108=3D3010=3D005)
<20040531-10:19:41, FIX.4.3:TW->CLIENT2, event>
  (Tried to send a reject while not logged on)
<20040531-10:19:41, FIX.4.3:TW->CLIENT2, event>
  (Disconnecting)
8. Output on the client console:
1) Enter Order
2) Cancel Order
3) Replace Order
4) Market data test
5) Quit
Action:=20
Logoff - FIX.4.3:CLIENT1->TW
=20
Logoff - FIX.4.3:CLIENT2->TW
=20
Logoff - FIX.4.3:CLIENT1->TW
=20
Logoff - FIX.4.3:CLIENT2->TW
=20
TIA
=20
Regards,
RK
=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-users] Problem with logon in linux

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

Hi

I am having problems while logging into a linux box.

1) I have a server and a client program. if both these components are =
sitting on the same windows machine or even different windows machine =
then everything works fine.
Also if both these components sit on the same linux box, then also =
everything works fine.

But the problem occurs when I have the client running on a different =
linux or windows box. I have given the scenarios below.

Server 		Client		status
windows1 	windows1	working
windows1	windows2	working
linux1		linux1		working=09
linux1		linux2		not working
linux1		windows1	not working

I get the following error on the server console.
<20040531-10:17:04, FIX.4.3:TW->CLIENT1, incoming>
  =
(8=3DFIX.4.3?9=3D65?35=3DA?34=3D22?49=3DCLIENT1?52=3D20040531-09:14:59.00=
0?56=3DTW?98=3D0?108=3D30?10=3D201)
<20040531-10:17:04, FIX.4.3:TW->CLIENT1, event>
  (Disconnecting)


On the client console, I see this error
<20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
  (Created session)
SK-Run

1) Enter Order
2) Cancel Order
3) Replace Order
4) Market data test
5) Load Test
6) Quit
Action:
<20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
  (Connecting to gfinetap1 on port 5022)
<20040531-09:15:29, FIX.4.3:CLIENT1->TW, event>
  (Connection succeeded)
Debug toAdmin called =
8=3DFIX.4.3?9=3D65?35=3DA?34=3D23?49=3DCLIENT1?52=3D20040531-09:15:30.0
00?56=3DTW?98=3D0?108=3D30?10=3D192?
<20040531-09:15:30, FIX.4.3:CLIENT1->TW, outgoing>
  =
(8=3DFIX.4.3?9=3D65?35=3DA?34=3D23?49=3DCLIENT1?52=3D20040531-09:15:30.00=
0?56=3DTW?98=3D0?108=3D
30?10=3D192?)
<20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
  (Initiated logon request)
<20040531-09:15:30, FIX.4.3:CLIENT1->TW, event>
  (Disconnecting)=09

The server and clients are communicating, but they are unable to logon.

any inputs, about what I am doing wrong.

with 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-users] Problem with MarketDataRequest Message

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

T29wcywgDQoNCnRoYW5rcy4gDQpSIFNoYW1hbnRoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBBbmRyZXcgTXVubiBbbWFpbHRvOmFuZHJld0BubWVkaWEubmV0XQ0KU2VudDog
RnJpZGF5LCBNYXkgMjgsIDIwMDQgODozMCBQTQ0KVG86IFNoYW1hbnRoDQpDYzogcXVpY2tmaXgt
dXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBSRTogW1F1aWNrZml4LXVzZXJz
XSBQcm9ibGVtIHdpdGggTWFya2V0RGF0YVJlcXVlc3QgTWVzc2FnZQ0KDQoNClRoZSBleGVjdXRv
ciBvbmx5IHJlc3BvbmRzIHRvIE5ld09yZGVyU2luZ2xlLiAgSXQgZG9lcyBub3QgcmVzcG9uZCB0
byBNYXJrZXREYXRhUmVxdWVzdCBzbyB0aGF0IGlzIHdoeSB5b3UgZ2V0IFVuc3VwcG9ydGVkIE1l
c3NhZ2UgVHlwZSBiYWNrLg0KDQotQW5kcmV3DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KRnJvbTogcXVpY2tmaXgtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNl
Zm9yZ2UubmV0IFttYWlsdG86cXVpY2tmaXgtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2Uu
bmV0XSBPbiBCZWhhbGYgT2YgU2hhbWFudGgNClNlbnQ6IEZyaWRheSwgTWF5IDI4LCAyMDA0IDk6
NTUgQU0NCkNjOiBxdWlja2ZpeC11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6
IFJFOiBbUXVpY2tmaXgtdXNlcnNdIFByb2JsZW0gd2l0aCBNYXJrZXREYXRhUmVxdWVzdCBNZXNz
YWdlDQoNCkhpIE9yZW4NCiANCkkgYW0gdXNpbmcgdGhlIGV4YW1wbGUgImV4ZWN1dG9yIiBhcHBs
aWNhdGlvbiBhcyBteSBzZXJ2ZXIsIEkgZGlkIG5vdCBtYWtlIGFueSBjaGFuZ2VzIHRvIHRoZSBz
ZXJ2ZXIgY29kZS4NCiANCkkganVzdCB3cm90ZSBhIGphdmEgY2xpZW50IGFuZCBhbSB0cnlpbmcg
dG8gc2VuZCBhIHJlcXVlc3QuDQogDQpTbyBJIGZlZWwgdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdp
dGggbXkgY29kZS4gSXMgdGhlIG1lc3NhZ2UgY29ycmVjdD8NCiANCndpdGggcmVnYXJkcw0KUiBT
aGFtYW50aA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9yZW4gTWlsbGVyIFtt
YWlsdG86b3JlbkBxdWlja2ZpeGVuZ2luZS5vcmddDQpTZW50OiBGcmlkYXksIE1heSAyOCwgMjAw
NCA3OjU3IFBNDQpUbzogU2hhbWFudGgNCkNjOiBxdWlja2ZpeC11c2Vyc0BsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQNClN1YmplY3Q6IFJlOiBbUXVpY2tmaXgtdXNlcnNdIFByb2JsZW0gd2l0aCBNYXJr
ZXREYXRhUmVxdWVzdCBNZXNzYWdlDQpMb29rcyBsaWtlIG9uIHRoZSBzZXJ2ZXIgeW91IGFyZSBw
YXNzaW5nIHRoZSBtZXNzYWdlIG9uIHRvIGEgTWVzc2FnZUNyYWNrZXIgd2l0aG91dCBvdmVycmlk
aW5nIHRoZSBvbk1lc3NhZ2UgbWV0aG9kIGZvciBNYXJrZXREYXRhUmVxdWVzdHMuIA0KDQotLW9y
ZW4gDQoNCk9uIE1heSAyOCwgMjAwNCwgYXQgODo1NiBBTSwgU2hhbWFudGggd3JvdGU6IA0KDQpI
aSANCg0KSSBoYXZlIGEgcHJvYmxlbSB3aGlsZSB0ZXN0aW5nIFF1aWNrRklYIEVuZ2luZS4gDQoN
CkkgYW0gdHJ5aW5nIHRvIHNlbmQgTWFya2V0RGF0YVJlcXVlc3QgbWVzc2FnZSBhbmQgdHJ5aW5n
IHRvIHJlY2VpdmUgYSByZXNwb25zZSBmcm9tIHRoZSBRdWlja0ZJWCBFbmdpbmUuIA0KDQpNeSBN
YXJrZXREYXRhUmVxdWVzdCBNZXNzYWdlIGlzIGFzIHNob3duIGJlbG93LiANCg0KOD1GSVguNC4z
4pi6OT0xMDnimLozNT1W4pi6MzQ9NTQ04pi6NDk9Q0xJRU5UMuKYujUyPTIwMDQwNTI4LTEzOjE5
OjU5LjAwMOKYujU2PVRX4pi6MTQ2PTHimLo1IA0KNT1MTlVY4pi6MjYyPU1BUktFVERBVEFJROKY
ujI2Mz0w4pi6MjY0PTDimLoyNjc9MeKYujI2OT0w4pi6MTA9MTYw4pi6IA0KDQpJIGtlZXAgZ2V0
dGluZyB0aGUgZm9sbG93aW5nIHJlc3BvbnNlIGZyb20gdGhlIHNlcnZlci4gDQoNCjg9RklYLjQu
M+KYujk9MTAx4pi6MzU9auKYujM0PTU0MeKYujQ5PVRX4pi6NTI9MjAwNDA1MjgtMTM6MTk6NTku
MDAw4pi6NTY9Q0xJRU5UMuKYujQ1PTU0NOKYujU4PSANClVuc3VwcG9ydGVkIE1lc3NhZ2UgVHlw
ZeKYujM3Mj1W4pi6MzgwPTPimLoxMD0xODTimLogDQoNClRoZSBjb2RlIHRoYXQgZ2VuZXJhdGVz
IHRoZSBNYXJrZXREYXRhUmVxdWVzdCBpcyBwYXN0ZWQgYmVsb3cgDQoNCiAgICAgICAgICAgICAg
ICBNRFJlcUlEIG1kUmVxSUQgPSBuZXcgTURSZXFJRCggIk1BUktFVERBVEFJRCIgKTsgDQogICAg
ICAgICAgICAgICAgU3Vic2NyaXB0aW9uUmVxdWVzdFR5cGUgc3ViVHlwZSA9IG5ldyBTdWJzY3Jp
cHRpb25SZXF1ZXN0VHlwZSggU3Vic2NyaXB0aW9uUmVxdWVzdFR5cGUuU05BUFNIT1QgKTsgDQog
ICAgICAgICAgICAgICAgTWFya2V0RGVwdGggbWFya2V0RGVwdGggPSBuZXcgTWFya2V0RGVwdGgo
IDAgKTsgDQoNCiAgICAgICAgICAgICAgICBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVz
dC5Ob01ERW50cnlUeXBlcyBtYXJrZXREYXRhRW50cnlHcm91cCA9IG5ldyBxdWlja2ZpeC5maXg0
My5NYXJrZXREYXRhUmVxdWVzdC5Ob01ERW50cnlUeXBlcygpOyANCg0KICAgICAgICAgICAgICAg
IE1ERW50cnlUeXBlIG1kRW50cnlUeXBlID0gbmV3IE1ERW50cnlUeXBlKCBNREVudHJ5VHlwZS5C
SUQgKTsgDQogICAgICAgICAgICAgICAgbWFya2V0RGF0YUVudHJ5R3JvdXAuc2V0KCBtZEVudHJ5
VHlwZSApOyANCg0KICAgICAgICAgICAgICAgIHF1aWNrZml4LmZpeDQzLk1hcmtldERhdGFSZXF1
ZXN0Lk5vUmVsYXRlZFN5bSBzeW1ib2xHcm91cCA9IG5ldyBxdWlja2ZpeC5maXg0My5NYXJrZXRE
YXRhUmVxdWVzdC5Ob1JlbGF0ZWRTeW0oKTsgDQoNCiAgICAgICAgICAgICAgICBTeW1ib2wgc3lt
Ym9sID0gbmV3IFN5bWJvbCggIkxOVVgiICk7IA0KICAgICAgICAgICAgICAgIHN5bWJvbEdyb3Vw
LnNldCggc3ltYm9sICk7IA0KDQogICAgICAgICAgICAgICAgcXVpY2tmaXguZml4NDMuTWFya2V0
RGF0YVJlcXVlc3QgbWVzc2FnZSA9IG5ldyBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVz
dCggbWRSZXFJRCwgc3ViVHlwZSwgbWFya2V0RGVwdGggKTsgDQoNCiAgICAgICAgICAgICAgICBt
ZXNzYWdlLmFkZEdyb3VwKCBtYXJrZXREYXRhRW50cnlHcm91cCApOyANCiAgICAgICAgICAgICAg
ICBtZXNzYWdlLmFkZEdyb3VwKCBzeW1ib2xHcm91cCApOyANCg0KICAgICAgICAgICAgICAgIHF1
ZXJ5SGVhZGVyKCBtZXNzYWdlLmdldEhlYWRlcigpICk7IA0KDQpJIGFtIHVzaW5nIEZJWCB2ZXJz
aW9uIDQuMywgYW5kIFF1aWNrRklYIEVuZ2luZSB2ZXJzaW9uIDEuNy4wIA0KDQpJIGFtIG5vdCBz
dXJlIHdoYXQgdGhlIHByb2JsZW0gaXMsIGFueSBpbnB1dHMgd291bGQgYmUgdmVyeSBoZWxwZnVs
LiBJIHRyaWVkIHdpdGggZGlmZmVyZW50IFN5bWJvbHMsIGxpa2UgIlVTRC9FVVIiLCBldGMgYWxz
by4uIA0KDQoNCnRoYW5rcyANClIgU2hhbWFudGggDQoNCg0KICBOT1RJQ0UgDQoNClRoaXMgZS1t
YWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cywgd2hpY2ggbWF5IGNvbnRhaW4gY29uZmlk
ZW50aWFsIGluZm9ybWF0aW9uLCBhcmUgdG8gYmUgdmlld2VkIHNvbGVseSBieSB0aGUgaW50ZW5k
ZWQgcmVjaXBpZW50IG9mIEludGVncmFsIERldmVsb3BtZW50IENvcnAuICBJZiB0aGUgcmVhZGVy
IG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo
ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g
b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g
IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVk
aWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1haWwgYW5kIGFsbCBhdHRh
Y2htZW50cy4NCg0KDQo=

RE: [Quickfix-users] Problem with MarketDataRequest Message

[Andrew M. <an...@nm...>]

The executor only responds to NewOrderSingle.  It does not respond to =
MarketDataRequest so that is why you get Unsupported Message Type back.

-Andrew


________________________________________
From: qui...@li... =
[mailto:qui...@li...] On Behalf Of =
Shamanth
Sent: Friday, May 28, 2004 9:55 AM
Cc: qui...@li...
Subject: RE: [Quickfix-users] Problem with MarketDataRequest Message

Hi Oren
=20
I am using the example "executor" application as my server, I did not =
make any changes to the server code.
=20
I just wrote a java client and am trying to send a request.
=20
So I feel there is some problem with my code. Is the message correct?
=20
with regards
R Shamanth
-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Friday, May 28, 2004 7:57 PM
To: Shamanth
Cc: qui...@li...
Subject: Re: [Quickfix-users] Problem with MarketDataRequest Message
Looks like on the server you are passing the message on to a =
MessageCracker without overriding the onMessage method for =
MarketDataRequests.=20

--oren=20

On May 28, 2004, at 8:56 AM, Shamanth wrote:=20

Hi=20

I have a problem while testing QuickFIX Engine.=20

I am trying to send MarketDataRequest message and trying to receive a =
response from the QuickFIX Engine.=20

My MarketDataRequest Message is as shown below.=20

8=3DFIX.4.3=E2=98=BA9=3D109=E2=98=BA35=3DV=E2=98=BA34=3D544=E2=98=BA49=3D=
CLIENT2=E2=98=BA52=3D20040528-13:19:59.000=E2=98=BA56=3DTW=E2=98=BA146=3D=
1=E2=98=BA5=20
5=3DLNUX=E2=98=BA262=3DMARKETDATAID=E2=98=BA263=3D0=E2=98=BA264=3D0=E2=98=
=BA267=3D1=E2=98=BA269=3D0=E2=98=BA10=3D160=E2=98=BA=20

I keep getting the following response from the server.=20

8=3DFIX.4.3=E2=98=BA9=3D101=E2=98=BA35=3Dj=E2=98=BA34=3D541=E2=98=BA49=3D=
TW=E2=98=BA52=3D20040528-13:19:59.000=E2=98=BA56=3DCLIENT2=E2=98=BA45=3D5=
44=E2=98=BA58=3D=20
Unsupported Message =
Type=E2=98=BA372=3DV=E2=98=BA380=3D3=E2=98=BA10=3D184=E2=98=BA=20

The code that generates the MarketDataRequest is pasted below=20

                MDReqID mdReqID =3D new MDReqID( "MARKETDATAID" );=20
                SubscriptionRequestType subType =3D new =
SubscriptionRequestType( SubscriptionRequestType.SNAPSHOT );=20
                MarketDepth marketDepth =3D new MarketDepth( 0 );=20

                quickfix.fix43.MarketDataRequest.NoMDEntryTypes =
marketDataEntryGroup =3D new =
quickfix.fix43.MarketDataRequest.NoMDEntryTypes();=20

                MDEntryType mdEntryType =3D new MDEntryType( =
MDEntryType.BID );=20
                marketDataEntryGroup.set( mdEntryType );=20

                quickfix.fix43.MarketDataRequest.NoRelatedSym =
symbolGroup =3D new quickfix.fix43.MarketDataRequest.NoRelatedSym();=20

                Symbol symbol =3D new Symbol( "LNUX" );=20
                symbolGroup.set( symbol );=20

                quickfix.fix43.MarketDataRequest message =3D new =
quickfix.fix43.MarketDataRequest( mdReqID, subType, marketDepth );=20

                message.addGroup( marketDataEntryGroup );=20
                message.addGroup( symbolGroup );=20

                queryHeader( message.getHeader() );=20

I am using FIX version 4.3, and QuickFIX Engine version 1.7.0=20

I am not sure what the problem is, any inputs would be very helpful. I =
tried with different Symbols, like "USD/EUR", etc also..=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-users] Problem with MarketDataRequest Message

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

SGkgT3Jlbg0KIA0KSSBhbSB1c2luZyB0aGUgZXhhbXBsZSAiZXhlY3V0b3IiIGFwcGxpY2F0aW9u
IGFzIG15IHNlcnZlciwgSSBkaWQgbm90IG1ha2UgYW55IGNoYW5nZXMgdG8gdGhlIHNlcnZlciBj
b2RlLg0KIA0KSSBqdXN0IHdyb3RlIGEgamF2YSBjbGllbnQgYW5kIGFtIHRyeWluZyB0byBzZW5k
IGEgcmVxdWVzdC4NCiANClNvIEkgZmVlbCB0aGVyZSBpcyBzb21lIHByb2JsZW0gd2l0aCBteSBj
b2RlLiBJcyB0aGUgbWVzc2FnZSBjb3JyZWN0Pw0KIA0Kd2l0aCByZWdhcmRzDQpSIFNoYW1hbnRo
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPcmVuIE1pbGxlciBbbWFpbHRv
Om9yZW5AcXVpY2tmaXhlbmdpbmUub3JnXQ0KU2VudDogRnJpZGF5LCBNYXkgMjgsIDIwMDQgNzo1
NyBQTQ0KVG86IFNoYW1hbnRoDQpDYzogcXVpY2tmaXgtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0DQpTdWJqZWN0OiBSZTogW1F1aWNrZml4LXVzZXJzXSBQcm9ibGVtIHdpdGggTWFya2V0RGF0
YVJlcXVlc3QgTWVzc2FnZQ0KDQoNCg0KTG9va3MgbGlrZSBvbiB0aGUgc2VydmVyIHlvdSBhcmUg
cGFzc2luZyB0aGUgbWVzc2FnZSBvbiB0byBhIE1lc3NhZ2VDcmFja2VyIHdpdGhvdXQgb3ZlcnJp
ZGluZyB0aGUgb25NZXNzYWdlIG1ldGhvZCBmb3IgTWFya2V0RGF0YVJlcXVlc3RzLiANCg0KDQot
LW9yZW4gDQoNCg0KT24gTWF5IDI4LCAyMDA0LCBhdCA4OjU2IEFNLCBTaGFtYW50aCB3cm90ZTog
DQoNCg0KSGkgDQoNCg0KSSBoYXZlIGEgcHJvYmxlbSB3aGlsZSB0ZXN0aW5nIFF1aWNrRklYIEVu
Z2luZS4gDQoNCg0KSSBhbSB0cnlpbmcgdG8gc2VuZCBNYXJrZXREYXRhUmVxdWVzdCBtZXNzYWdl
IGFuZCB0cnlpbmcgdG8gcmVjZWl2ZSBhIHJlc3BvbnNlIGZyb20gdGhlIFF1aWNrRklYIEVuZ2lu
ZS4gDQoNCg0KTXkgTWFya2V0RGF0YVJlcXVlc3QgTWVzc2FnZSBpcyBhcyBzaG93biBiZWxvdy4g
DQoNCg0KOD1GSVguNC4z4pi6OT0xMDnimLozNT1W4pi6MzQ9NTQ04pi6NDk9Q0xJRU5UMuKYujUy
PTIwMDQwNTI4LTEzOjE5OjU5LjAwMOKYujU2PVRX4pi6MTQ2PTHimLo1IA0KDQo1PUxOVVjimLoy
NjI9TUFSS0VUREFUQUlE4pi6MjYzPTDimLoyNjQ9MOKYujI2Nz0x4pi6MjY5PTDimLoxMD0xNjDi
mLogDQoNCg0KSSBrZWVwIGdldHRpbmcgdGhlIGZvbGxvd2luZyByZXNwb25zZSBmcm9tIHRoZSBz
ZXJ2ZXIuIA0KDQoNCjg9RklYLjQuM+KYujk9MTAx4pi6MzU9auKYujM0PTU0MeKYujQ5PVRX4pi6
NTI9MjAwNDA1MjgtMTM6MTk6NTkuMDAw4pi6NTY9Q0xJRU5UMuKYujQ1PTU0NOKYujU4PSANCg0K
VW5zdXBwb3J0ZWQgTWVzc2FnZSBUeXBl4pi6MzcyPVbimLozODA9M+KYujEwPTE4NOKYuiANCg0K
DQpUaGUgY29kZSB0aGF0IGdlbmVyYXRlcyB0aGUgTWFya2V0RGF0YVJlcXVlc3QgaXMgcGFzdGVk
IGJlbG93IA0KDQoNCiAgICAgICAgICAgICAgICBNRFJlcUlEIG1kUmVxSUQgPSBuZXcgTURSZXFJ
RCggIk1BUktFVERBVEFJRCIgKTsgDQoNCiAgICAgICAgICAgICAgICBTdWJzY3JpcHRpb25SZXF1
ZXN0VHlwZSBzdWJUeXBlID0gbmV3IFN1YnNjcmlwdGlvblJlcXVlc3RUeXBlKCBTdWJzY3JpcHRp
b25SZXF1ZXN0VHlwZS5TTkFQU0hPVCApOyANCg0KICAgICAgICAgICAgICAgIE1hcmtldERlcHRo
IG1hcmtldERlcHRoID0gbmV3IE1hcmtldERlcHRoKCAwICk7IA0KDQoNCiAgICAgICAgICAgICAg
ICBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVzdC5Ob01ERW50cnlUeXBlcyBtYXJrZXRE
YXRhRW50cnlHcm91cCA9IG5ldyBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVzdC5Ob01E
RW50cnlUeXBlcygpOyANCg0KDQogICAgICAgICAgICAgICAgTURFbnRyeVR5cGUgbWRFbnRyeVR5
cGUgPSBuZXcgTURFbnRyeVR5cGUoIE1ERW50cnlUeXBlLkJJRCApOyANCg0KICAgICAgICAgICAg
ICAgIG1hcmtldERhdGFFbnRyeUdyb3VwLnNldCggbWRFbnRyeVR5cGUgKTsgDQoNCg0KICAgICAg
ICAgICAgICAgIHF1aWNrZml4LmZpeDQzLk1hcmtldERhdGFSZXF1ZXN0Lk5vUmVsYXRlZFN5bSBz
eW1ib2xHcm91cCA9IG5ldyBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVzdC5Ob1JlbGF0
ZWRTeW0oKTsgDQoNCg0KICAgICAgICAgICAgICAgIFN5bWJvbCBzeW1ib2wgPSBuZXcgU3ltYm9s
KCAiTE5VWCIgKTsgDQoNCiAgICAgICAgICAgICAgICBzeW1ib2xHcm91cC5zZXQoIHN5bWJvbCAp
OyANCg0KDQogICAgICAgICAgICAgICAgcXVpY2tmaXguZml4NDMuTWFya2V0RGF0YVJlcXVlc3Qg
bWVzc2FnZSA9IG5ldyBxdWlja2ZpeC5maXg0My5NYXJrZXREYXRhUmVxdWVzdCggbWRSZXFJRCwg
c3ViVHlwZSwgbWFya2V0RGVwdGggKTsgDQoNCg0KICAgICAgICAgICAgICAgIG1lc3NhZ2UuYWRk
R3JvdXAoIG1hcmtldERhdGFFbnRyeUdyb3VwICk7IA0KDQogICAgICAgICAgICAgICAgbWVzc2Fn
ZS5hZGRHcm91cCggc3ltYm9sR3JvdXAgKTsgDQoNCg0KICAgICAgICAgICAgICAgIHF1ZXJ5SGVh
ZGVyKCBtZXNzYWdlLmdldEhlYWRlcigpICk7IA0KDQoNCkkgYW0gdXNpbmcgRklYIHZlcnNpb24g
NC4zLCBhbmQgUXVpY2tGSVggRW5naW5lIHZlcnNpb24gMS43LjAgDQoNCg0KSSBhbSBub3Qgc3Vy
ZSB3aGF0IHRoZSBwcm9ibGVtIGlzLCBhbnkgaW5wdXRzIHdvdWxkIGJlIHZlcnkgaGVscGZ1bC4g
SSB0cmllZCB3aXRoIGRpZmZlcmVudCBTeW1ib2xzLCBsaWtlICJVU0QvRVVSIiwgZXRjIGFsc28u
LiANCg0KDQoNCg0KdGhhbmtzIA0KDQpSIFNoYW1hbnRoIA0KDQoNCg0KDQogIE5PVElDRSANCg0K
DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMsIHdoaWNoIG1heSBjb250
YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgYXJlIHRvIGJlIHZpZXdlZCBzb2xlbHkgYnkg
dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiBJbnRlZ3JhbCBEZXZlbG9wbWVudCBDb3JwLiAgSWYg
dGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs
IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZGlz
dHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBs
ZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBtYWlsIGFu
ZCBhbGwgYXR0YWNobWVudHMuDQoNCg0K

Re: [Quickfix-users] Problem with MarketDataRequest Message

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

Looks like on the server you are passing the message on to a =20
MessageCracker without overriding the onMessage method for =20
MarketDataRequests.

--oren

On May 28, 2004, at 8:56 AM, Shamanth wrote:

> Hi
>
> I have a problem while testing QuickFIX Engine.
>
> I am trying to send MarketDataRequest message and trying to receive a =20=

> response from the QuickFIX Engine.
>
> My MarketDataRequest Message is as shown below.
>
> 8=3DFIX.4.3=E2=98=BA9=3D109=E2=98=BA35=3DV=E2=98=BA34=3D544=E2=98=BA49=3D=
CLIENT2=E2=98=BA52=3D20040528-13:19:=20
> 59.000=E2=98=BA56=3DTW=E2=98=BA146=3D1=E2=98=BA5
> 5=3DLNUX=E2=98=BA262=3DMARKETDATAID=E2=98=BA263=3D0=E2=98=BA264=3D0=E2=98=
=BA267=3D1=E2=98=BA269=3D0=E2=98=BA10=3D160=E2=98=BA
>
> I keep getting the following response from the server.
>
> 8=3DFIX.4.3=E2=98=BA9=3D101=E2=98=BA35=3Dj=E2=98=BA34=3D541=E2=98=BA49=3D=
TW=E2=98=BA52=3D20040528-13:19:=20
> 59.000=E2=98=BA56=3DCLIENT2=E2=98=BA45=3D544=E2=98=BA58=3D
> Unsupported Message Type=E2=98=BA372=3DV=E2=98=BA380=3D3=E2=98=BA10=3D18=
4=E2=98=BA
>
> The code that generates the MarketDataRequest is pasted below
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 MDReqID mdReqID =3D new MDReqID( "MARKETDATAID" );
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 SubscriptionRequestType subType =3D new =20
> SubscriptionRequestType( SubscriptionRequestType.SNAPSHOT );
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 MarketDepth marketDepth =3D new MarketDepth( 0 );
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 quickfix.fix43.MarketDataRequest.NoMDEntryTypes =20
> marketDataEntryGroup =3D new =20
> quickfix.fix43.MarketDataRequest.NoMDEntryTypes();
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 MDEntryType mdEntryType =3D new MDEntryType( =20
> MDEntryType.BID );
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 marketDataEntryGroup.set( mdEntryType );
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 quickfix.fix43.MarketDataRequest.NoRelatedSym =20
> symbolGroup =3D new quickfix.fix43.MarketDataRequest.NoRelatedSym();
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Symbol symbol =3D new Symbol( "LNUX" );
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 symbolGroup.set( symbol );
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 quickfix.fix43.MarketDataRequest message =3D new =20
> quickfix.fix43.MarketDataRequest( mdReqID, subType, marketDepth );
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 message.addGroup( marketDataEntryGroup );
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 message.addGroup( symbolGroup );
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 queryHeader( message.getHeader() );
>
> I am using FIX version 4.3, and QuickFIX Engine version 1.7.0
>
> I am not sure what the problem is, any inputs would be very helpful. I =
=20
> tried with different Symbols, like "USD/EUR", etc also..
>
>
>
> thanks
>  R Shamanth
>
>
>
> =C2=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.=C2=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.=C2=A0 If you have received this message in error, =
=20
> please immediately notify the sender and delete the mail and all =20
> attachments.

[Quickfix-users] Problem with MarketDataRequest Message

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

Hi

I have a problem while testing QuickFIX Engine.

I am trying to send MarketDataRequest message and trying to receive a =
response from the QuickFIX Engine.

My MarketDataRequest Message is as shown below.

8=3DFIX.4.3?9=3D109?35=3DV?34=3D544?49=3DCLIENT2?52=3D20040528-13:19:59.0=
00?56=3DTW?146=3D1?5
5=3DLNUX?262=3DMARKETDATAID?263=3D0?264=3D0?267=3D1?269=3D0?10=3D160?

I keep getting the following response from the server.

8=3DFIX.4.3?9=3D101?35=3Dj?34=3D541?49=3DTW?52=3D20040528-13:19:59.000?56=
=3DCLIENT2?45=3D544?58=3D
Unsupported Message Type?372=3DV?380=3D3?10=3D184?

The code that generates the MarketDataRequest is pasted below

		MDReqID mdReqID =3D new MDReqID( "MARKETDATAID" );
		SubscriptionRequestType subType =3D new SubscriptionRequestType( =
SubscriptionRequestType.SNAPSHOT );
		MarketDepth marketDepth =3D new MarketDepth( 0 );

		quickfix.fix43.MarketDataRequest.NoMDEntryTypes marketDataEntryGroup =
=3D new quickfix.fix43.MarketDataRequest.NoMDEntryTypes();
		MDEntryType mdEntryType =3D new MDEntryType( MDEntryType.BID );
		marketDataEntryGroup.set( mdEntryType );

		quickfix.fix43.MarketDataRequest.NoRelatedSym symbolGroup =3D new =
quickfix.fix43.MarketDataRequest.NoRelatedSym();
		Symbol symbol =3D new Symbol( "LNUX" );
		symbolGroup.set( symbol );

		quickfix.fix43.MarketDataRequest message =3D new =
quickfix.fix43.MarketDataRequest( mdReqID, subType, marketDepth );
		message.addGroup( marketDataEntryGroup );
		message.addGroup( symbolGroup );

		queryHeader( message.getHeader() );

I am using FIX version 4.3, and QuickFIX Engine version 1.7.0

I am not sure what the problem is, any inputs would be very helpful. I =
tried with different Symbols, like "USD/EUR", etc also..


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

[Quickfix-users] QuickFIX 1.7.1 Available

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

QuickFIX 1.7.1 is now available at http://www.quickfixengine.org/

Release notes are available at  
http://sourceforge.net/project/shownotes.php? 
group_id=37535&release_id=237222

So this is pretty significant for a point release.  For C++ users it  
will look pretty much like a point release, but for Java users it will  
look more significant.  For the most part the Message class has been  
beefed up giving you access to more versatile constructors, and finally  
iterators!  You can now iterate through all the fields in a message (as  
well as headers, trailers, and groups). Iterators return StringFields  
which contain the tag and a string representation of the fields value.

There are also some other nice things for everyone like the ability to  
programatically logoff. QuickFIX will also gracefully logoff when an  
initiator or acceptor is stopped. No more complaints from  
counter-parties about QF rudely hanging up on everyone.

Of course the problem with infinite resend requests has been fixed.   
Thanks to everyone who provided clues as to the nature of this problem  
and those who verified that it has gone away.  Once we were able to  
capture it in a test the fix for this was trivial.

I know I said it last time, but it is true once again.  Adoption of  
QuickFIX is getting bigger and bigger.  1.7.0 got 1000 downloads in the  
month of March.  Previous releases have generally garnered 300-400  
downloads in a month.  We have also seen even more major firms adopting  
or evaluating QuickFIX.  I think in general the acceptance of OSS  
software in finance is at a level never before seen.  This industry has  
always been quick to adapt to new things that add value and I'm glad  
that OSS is seen as one of those things.

--oren

Re: [Quickfix-users] custom messages/ message wrappers

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

Well in C++ the toString call is not a virtual method, so when it is 
sent across the wire as a base Message class, it would just end up 
being sent as a regular FIX message.  In order to do what you need, I 
think these are the steps you would have to take.

change the toString call on the Message class.  You can check the 
MsgType to do message specific logic for things like the logon if 
necessary.
change the fromString call so that it can parse these messages.
change the Parser so it can correctly read these new message types off 
the wire.

I think if you do all this, you may be able to reuse the rest of the 
QuickFIX library to communicate with this counterparty.

It is important that messages you send with toString can be read back 
in with fromString, otherwise the message stores will break.

On May 6, 2004, at 3:40 PM, Blain Sadler wrote:

> Thanks for your quick response!
>
> To answer your question, the client-side server (I know it's bizzare 
> sounding :-) talks real fix to the outside world and real fix + the 
> wrappers and a custom logon message to the inside.  The main advantage 
> it offers is that I can send any version fix message to it and it will 
> appropriately translate to the version that the message's destination 
> is talking, so my application need only speak one version of fix.
>
> Your idea about having a proxy is great, but I don't know if it is 
> best for this situation, I get into that below.
>
> The custom logon message is the real problem here.  An example:
>
> <proprietarycompanyname>
>    <msg msgtype="6" sendercompid="BuySide" targetcompid="SellSide" 
> username="guest" password="bighexadecimalstring" />
> </proprietarycompanyname>
>
> So it's really a Fixml (perhaps nonstandard) message.  After a little 
> more peeking into the code it looks like I could (as you suggested) 
> add a username and password field to the message in the toAdmin 
> callback, but then I still have the problem of getting quickfix to 
> format it as per above.
>
> My guess is that I might be able to overload the toString() method in 
> the FIX44::Logon class which I think quickfix calls before it sends 
> the message over the wire.  BUT... I don't know if I am going to break 
> the system or even if it is possible to overload that method at that 
> level.  If I can do this however, I might as well just throw in the 
> <proprietarycompanyname></proprietarycompanyname> in FIX44::Message 
> and not worry about the proxy.
>
> Anyway, if you could give me a little insight into the ramifications 
> of doing the above that would be fantastic.
>
> Thanks again for you help, you have a awesome library here, I just 
> hope I can use it!
>
> -B
>
>
> or...@qu... wrote:
>
>> Wow.  That's some requirement!  Do they have the ability to talk to 
>> any off the shelf FIX engines?  Doesn't
>> sound likely.
>> The custom logon is easy, you can add on any fields to the outgoing 
>> logon in the toAdmin callback.  Just add
>> whatever custom fields you need with setField.  If they are sending 
>> you custom fields, just add them to the
>> DataDictionary and you should have no problem pulling them out with 
>> getField.
>>
>> Now the <tag></tag> thing is weird!  You certainly could hack around 
>> the code to try to support this strange
>> behavior, but what I would probably do instead is to write a small 
>> proxy to handle this.  Essentially just
>> write a little server that will take a proper FIX message on one end, 
>> and add the <tag></tag> before sending to
>> the counterparty, and strip them out of messages you receive before 
>> sending to your application.  Another
>> advantage of having a proxy is that you could always swap in a new 
>> FIX engine if you ever wanted to switch.
>>
>>
>>> -------- Original Message --------
>>> Subject: [Quickfix-users] custom messages/ message wrappers
>>> From: "Blain Sadler" <bla...@tr...>
>>> Date: Thu, May 06, 2004 11:37 am
>>> To: qui...@li...
>>>
>>> Hi all,
>>>
>>> I am looking at integrating QuickFix as a part of a client 
>>> application
>>>
>>> communicating with a proprietary client side fix engine.  The main 
>>> problem that I am encountering is that this particular engine needs 
>>> a custom logon message, and for all messages to be wrapped in 
>>> <tag></tag>
>>>
>>> with the raw fix message encompassed within.
>>>
>>> Being unfamiliar with the quickfix c++ codebase,My questions to the
>>> list are these:
>>> 1) Where in the code would I go about tacking on and removing the 
>>> <tag></tag> pairs for incoming and outgoing messages?
>>> 2) How should I go about dealing with the custom logon and logon 
>>> response messages, subclass FIXxx::Logon?  Plug it into the socket's 
>>> receiving code?
>>>
>>> My thanks in advance for any help
>>>
>>> -B
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Sleepycat Software
>>> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>>> deliver higher performing products faster, at low TCO.
>>> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>> _______________________________________________
>>> Quickfix-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Sleepycat Software
>> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>> deliver higher performing products faster, at low TCO.
>> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>> _______________________________________________
>> Quickfix-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>
>>
>>
>>
>
>
>
>

Re: [Quickfix-users] custom messages/ message wrappers

[Blain S. <bla...@tr...>]

Thanks for your quick response!

To answer your question, the client-side server (I know it's bizzare 
sounding :-) talks real fix to the outside world and real fix + the 
wrappers and a custom logon message to the inside.  The main advantage 
it offers is that I can send any version fix message to it and it will 
appropriately translate to the version that the message's destination is 
talking, so my application need only speak one version of fix.

Your idea about having a proxy is great, but I don't know if it is best 
for this situation, I get into that below.

The custom logon message is the real problem here.  An example:

<proprietarycompanyname>
    <msg msgtype="6" sendercompid="BuySide" targetcompid="SellSide" 
username="guest" password="bighexadecimalstring" />
</proprietarycompanyname>

So it's really a Fixml (perhaps nonstandard) message.  After a little 
more peeking into the code it looks like I could (as you suggested) add 
a username and password field to the message in the toAdmin callback, 
but then I still have the problem of getting quickfix to format it as 
per above.

My guess is that I might be able to overload the toString() method in 
the FIX44::Logon class which I think quickfix calls before it sends the 
message over the wire.  BUT... I don't know if I am going to break the 
system or even if it is possible to overload that method at that level.  
If I can do this however, I might as well just throw in the 
<proprietarycompanyname></proprietarycompanyname> in FIX44::Message and 
not worry about the proxy.

Anyway, if you could give me a little insight into the ramifications of 
doing the above that would be fantastic.

Thanks again for you help, you have a awesome library here, I just hope 
I can use it!

-B

 

or...@qu... wrote:

>Wow.  That's some requirement!  Do they have the ability to talk to any off the shelf FIX engines?  Doesn't
>sound likely.  
>
>The custom logon is easy, you can add on any fields to the outgoing logon in the toAdmin callback.  Just add
>whatever custom fields you need with setField.  If they are sending you custom fields, just add them to the
>DataDictionary and you should have no problem pulling them out with getField.
>
>Now the <tag></tag> thing is weird!  You certainly could hack around the code to try to support this strange
>behavior, but what I would probably do instead is to write a small proxy to handle this.  Essentially just
>write a little server that will take a proper FIX message on one end, and add the <tag></tag> before sending to
>the counterparty, and strip them out of messages you receive before sending to your application.  Another
>advantage of having a proxy is that you could always swap in a new FIX engine if you ever wanted to switch.
>
>  
>
>>-------- Original Message --------
>>Subject: [Quickfix-users] custom messages/ message wrappers
>>From: "Blain Sadler" <bla...@tr...>
>>Date: Thu, May 06, 2004 11:37 am
>>To: qui...@li...
>>
>>Hi all,
>>
>>I am looking at integrating QuickFix as a part of a client application
>>
>>communicating with a proprietary client side fix engine.  The main 
>>problem that I am encountering is that this particular engine needs a 
>>custom logon message, and for all messages to be wrapped in <tag></tag>
>>
>>with the raw fix message encompassed within.
>>
>>Being unfamiliar with the quickfix c++ codebase,My questions to the
>>list 
>>are these:
>>1) Where in the code would I go about tacking on and removing the 
>><tag></tag> pairs for incoming and outgoing messages?
>>2) How should I go about dealing with the custom logon and logon 
>>response messages, subclass FIXxx::Logon?  Plug it into the socket's 
>>receiving code?
>>
>>My thanks in advance for any help
>>
>>-B
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>Quickfix-users mailing list
>>Qui...@li...
>>https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Quickfix-users mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
>  
>

RE: [Quickfix-users] custom messages/ message wrappers

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

Wow.  That's some requirement!  Do they have the ability to talk to any off the shelf FIX engines?  Doesn't
sound likely.  

The custom logon is easy, you can add on any fields to the outgoing logon in the toAdmin callback.  Just add
whatever custom fields you need with setField.  If they are sending you custom fields, just add them to the
DataDictionary and you should have no problem pulling them out with getField.

Now the <tag></tag> thing is weird!  You certainly could hack around the code to try to support this strange
behavior, but what I would probably do instead is to write a small proxy to handle this.  Essentially just
write a little server that will take a proper FIX message on one end, and add the <tag></tag> before sending to
the counterparty, and strip them out of messages you receive before sending to your application.  Another
advantage of having a proxy is that you could always swap in a new FIX engine if you ever wanted to switch.

> -------- Original Message --------
> Subject: [Quickfix-users] custom messages/ message wrappers
> From: "Blain Sadler" <bla...@tr...>
> Date: Thu, May 06, 2004 11:37 am
> To: qui...@li...
> 
> Hi all,
> 
> I am looking at integrating QuickFix as a part of a client application
> 
> communicating with a proprietary client side fix engine.  The main 
> problem that I am encountering is that this particular engine needs a 
> custom logon message, and for all messages to be wrapped in <tag></tag>
> 
> with the raw fix message encompassed within.
> 
> Being unfamiliar with the quickfix c++ codebase,My questions to the
> list 
> are these:
> 1) Where in the code would I go about tacking on and removing the 
> <tag></tag> pairs for incoming and outgoing messages?
> 2) How should I go about dealing with the custom logon and logon 
> response messages, subclass FIXxx::Logon?  Plug it into the socket's 
> receiving code?
> 
> My thanks in advance for any help
> 
> -B
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

[Quickfix-users] custom messages/ message wrappers

[Blain S. <bla...@tr...>]

Hi all,

I am looking at integrating QuickFix as a part of a client application 
communicating with a proprietary client side fix engine.  The main 
problem that I am encountering is that this particular engine needs a 
custom logon message, and for all messages to be wrapped in <tag></tag> 
with the raw fix message encompassed within.

Being unfamiliar with the quickfix c++ codebase,My questions to the list 
are these:
1) Where in the code would I go about tacking on and removing the 
<tag></tag> pairs for incoming and outgoing messages?
2) How should I go about dealing with the custom logon and logon 
response messages, subclass FIXxx::Logon?  Plug it into the socket's 
receiving code?

My thanks in advance for any help

-B

[Quickfix-users] Start Time / End Time working?

[<ren...@ya...>]

Hi,
We are using QuickFix 1.7.0 and we would like use the StartTime and EndTime tags, in order to reset the session when we want (instead of deleting the store files). We have written 2 little software: an initiator and an acceptor that communicate in FIX using Quickfix.
 
For the acceptor, we set the Start Time to 00:00:00, and the End Time to 00:00:00. Then we start the acceptor.
 
For the initiator, 
1. if we set the Start Time to 00:00:00, and the End Time to 00:00:00, no problem. As soon as the initiator is started, connection is setup, logon accepted... Everything works fine.
1. if we set for instance the Start Time to 15:30:00, and the End Time to 15:32:00, there is a problem. We start the initiator at 15:29:00 (GMT), wait... and nothing happens. Even if we wait for one heartbeat to go (30s), nothing happens. There is no connection, no logon.
 
I have read it was broken in 1.6. I wanted to know if it had been fixed in 1.7.0?
Renaud  
 
 

		
---------------------------------
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !

[Quickfix-users] Integrating SNMP Into Quickfix

[Kaczmarek, T. <TKa...@Cr...>]

Is their anyone working on integrating snmp into Quickfix?
How do any present users monitor Quickfix with snmp.

We presently use OpenNms which uses joesnmp, and am looking at enhancing
the monitoring capabilities of OpenNms for Quickfix, presently I use a
simplistic approach of using TCP port monitor but need to enhance that
to catch as many potential errors as possible.


Any feedback would be greatly appreciated.

At present the approach is logging and to use use scripts outside of
Quickfix, but if Quickfix were able to send traps itself it would be a
welcome enhancement.

Thanks,

-- 
Ted Kaczmarek<tka...@cr...>
Network Engineer
201-459-9500-ext 276
cell 973-563-6182

DISCLAIMER
e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.
REGARDING PRIVACY AND CONFIDENTIALITY
Crown Financial Group may, at its discretion, monitor and review the content
of all e-mail communications.

Re: [Quickfix-users] Peforming application-specific actions at creation of the initiator thread

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

Yeah, I see that.  I'll probably change that code to something like 
this.

   onStop();
   if( m_threadid );
     thread_join( m_threadid );
   m_threadid = 0;

On Apr 26, 2004, at 11:10 AM, Igo...@ub... wrote:

>
> OK, just looked at that, but it still doesn't seem that simple, as in 
> this
> case it seems I would have no way to terminate the thread that's 
> calling
> block().
>
> The block() method ends up SocketInitiator::onStart(), calling
> SocketConnector::block() in a loop that won't exit until the private 
> flag
> Initiator::m_stop is set to true. The only way to do that is to call
> Initiator::stop(), but stop() won't do anything unless the thread is
> created by Initiator::start(), as it checks the private variable
> Initiator::m_threadid, set by Initiator::start().
>
> Cheers,
> Igor
>
> ------- Oren Miller <or...@qu...> -------
> Well, start() is really a convenience method.  What you should do if
> you want more control over the thread is to spawn one yourself and call
> block() on the initiator instead.  This will run the initiator entirely
> in one thread and give you control over code that is run at startup and
> wind down of that thread.
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] Peforming application-specific actions at creation of the initiator thread

[<Igo...@ub...>]

OK, just looked at that, but it still doesn't seem that simple, as in this
case it seems I would have no way to terminate the thread that's calling
block().

The block() method ends up SocketInitiator::onStart(), calling
SocketConnector::block() in a loop that won't exit until the private flag
Initiator::m_stop is set to true. The only way to do that is to call
Initiator::stop(), but stop() won't do anything unless the thread is
created by Initiator::start(), as it checks the private variable
Initiator::m_threadid, set by Initiator::start().

Cheers,
Igor

------- Oren Miller <or...@qu...> -------
Well, start() is really a convenience method.  What you should do if
you want more control over the thread is to spawn one yourself and call
block() on the initiator instead.  This will run the initiator entirely
in one thread and give you control over code that is run at startup and
wind down of that thread.

Re: [Quickfix-users] Peforming application-specific actions at creation of the initiator thread

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

Well, start() is really a convenience method.  What you should do if 
you want more control over the thread is to spawn one yourself and call 
block() on the initiator instead.  This will run the initiator entirely 
in one thread and give you control over code that is run at startup and 
wind down of that thread.

On Apr 26, 2004, at 3:17 AM, Igo...@ub... wrote:

>
> It is a requirement of our architecture that a database initialisation
> routine be called from each thread.
>
> But that aside, this looks like a more general requirement that some
> initialisation code needs to be executed at the beginning of the 
> thread.
>
>
> ------- Oren Miller <or...@qu...> -------
> Igor,
>
> What is the reason for needing to connect to your database in that
> thread?  Can't you just connect to it before you call start() on the
> initiator?
>
> --oren
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] Peforming application-specific actions at creation of the initiator thread

[<Igo...@ub...>]

It is a requirement of our architecture that a database initialisation
routine be called from each thread.

But that aside, this looks like a more general requirement that some
initialisation code needs to be executed at the beginning of the thread.


------- Oren Miller <or...@qu...> -------
Igor,

What is the reason for needing to connect to your database in that
thread?  Can't you just connect to it before you call start() on the
initiator?

--oren