quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] How do I manually reset my sequence number?

[Rodrick B. <rod...@gm...>]

Or have your broker EOD your session at the end of the trading day, and you
should probably do the same on your end.

On Nov 5, 2007 4:58 PM, Andrew Culross <And...@tw...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Check out the <Session>.seqnum in the store dir/db (or something close to
> that)
>
> The file/db table contains two seq number seperated by a colon - adjust
> the
> first one to your broker's seq num
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> mrvictory1999
> Sent: Monday, November 05, 2007 4:51 PM
> To: qui...@li...
> Subject: [Quickfix-developers] How do I manually reset my sequence number?
>
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I am connecting to a broker using QuickFix.  In the case where our
> sequence
> numbers get out of sync, I am having trouble re-syncing.
>
> Specifically, if my QuickFix engine believes the sequence number should be
> 200, but the broker thinks it should be 300, I'll get a message like:
> MsgSeqNum too low, expecting 300 but received 200 Logon
>
> QuickFix will then repeatedly try to log in, incrementing the sequence
> number each time. So after 100 tries, it'll be at the right number.
>
> I need to know how to manually set my sequence number to 300 so that I can
> skip the 100 reconnect attempts.
>
> Thanks for your help!
> Matt
> --
> View this message in context:
>
> http://www.nabble.com/How-do-I-manually-reset-my-sequence-number--tf4754663.
> html#a13596466
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-- 
Rodrick R. Brown
http://www.rodrickbrown.com

[Quickfix-developers] setNextTargetMsgSeqNum is C#?

[mvictoryAtgmail <mvi...@gm...>]

I've noticed that both Java and C++ Session classes have implementations of
setNextSenderMsgSeqNum and setNextTargetMsgSeqNum 

For the life of me, I can't find the equivalent functions in C#.  I've
searched the source code and these forums but am not finding anything.  Does
the C# Session class have some other way of accomplishing the same thing?
Thanks.
-- 
View this message in context: http://www.nabble.com/setNextTargetMsgSeqNum-is-C---tf4760292.html#a13613565
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] MySQLStore

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

It does exist.  Make sure you bring in the proper header file.

--oren

On Nov 6, 2007, at 8:48 AM, sli...@ai... wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Greetings,
>
> I'm considering using a MySQL message store mechanism, however I  
> don't see what class I need to instantiate to create it.  I assumed  
> it would follow in the form like the FileStoreFactory:
>
> SessionSettings settings = new SessionSettings("QuickFix/ 
> settings.txt");
> FileStoreFactory storeFactory = new FileStoreFactory(settings);
>
> But be something like:
>
> MySQLStoreFactory storeFactory = new MySQLStoreFactory(settings);
>
> However nothing like this exists.  Am I supposed to still treat  
> this as a "FileStore" even though it's storing in MySQL?
>
> Thanks.
>
>
> Check Out the new free AIM(R) Mail -- Unlimited storage and  
> industry-leading spam and email virus protection.
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/ 
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] MySQLStore

[<sli...@ai...>]

Greetings,

I'm considering using a MySQL message store mechanism, however I don't see what class I need to instantiate to create it.? I assumed it would follow in the form like the FileStoreFactory:

SessionSettings settings = new SessionSettings("QuickFix/settings.txt");
FileStoreFactory storeFactory = new FileStoreFactory(settings);

But be something like:

MySQLStoreFactory storeFactory = new MySQLStoreFactory(settings);

However nothing like this exists.? Am I supposed to still treat this as a "FileStore" even though it's storing in MySQL?

Thanks.



________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.

Re: [Quickfix-developers] Disconnect socket meanwhile resending messages is treated when resent is finished (version 1.12.4)

[Djalma R. d. S. F. <drs...@gm...>]

Hi,

I had this problem too. However, my solution was a little bit different, I
am using some code from SNV trunk and I am not sure if in this newer version
Session::send returns false for application messages if connection is
broken, there are some changes in sendRaw. Thus, I preferred to check with
isLoggedOn() to break the loop.

Djalma

On Nov 6, 2007 9:49 AM, Tron Fix <tr...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi all,
>
> I saw that when quickfix is resending messages (nextResendRequest
> function into Session class), it can happen a socket disconnection and
> the library is going on into this loop, saving messages into log but
> doing nothing with them (socket not longer exists).
> Maybe it could be added some control, so if socket failed to send a
> message, we go out the loop and stops resending.
>
> Now we have this lines to send the message (Session.cpp:405 to 412)
>
> if ( resend( msg ) )
> {
> if ( begin ) generateSequenceReset( begin, msgSeqNum );
> send( msg.toString(messageString));
>
> m_state.onEvent( "Resending Message: "
> + IntConvertor::convert( msgSeqNum ) );
> begin = 0;
>
> This could be added:
>
> if ( resend( msg ) )
> {
> if ( begin ) generateSequenceReset( begin, msgSeqNum );
> // ** ADDED SOCKET CONTROL: send failed, break loop!
> if (!send( msg.toString(messageString) ))
> break;
> // ***
> m_state.onEvent( "Resending Message: "
> + IntConvertor::convert( msgSeqNum ) );
> begin = 0;
>
> I tested in my quickfix application and it works, the application
> finishes resending when socket is disconnected.
> What do you think, do you see something wrong in this approach?
>
> Regards,
> Abel Monroy
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Disconnect socket meanwhile resending messages is treated when resent is finished (version 1.12.4)

[Tron F. <tr...@gm...>]

Hi all,

I saw that when quickfix is resending messages (nextResendRequest
function into Session class), it can happen a socket disconnection and
the library is going on into this loop, saving messages into log but
doing nothing with them (socket not longer exists).
Maybe it could be added some control, so if socket failed to send a
message, we go out the loop and stops resending.

Now we have this lines to send the message (Session.cpp:405 to 412)

if ( resend( msg ) )
{
if ( begin ) generateSequenceReset( begin, msgSeqNum );
send( msg.toString(messageString));

m_state.onEvent( "Resending Message: "
+ IntConvertor::convert( msgSeqNum ) );
begin = 0;

This could be added:

if ( resend( msg ) )
{
if ( begin ) generateSequenceReset( begin, msgSeqNum );
// ** ADDED SOCKET CONTROL: send failed, break loop!
if (!send( msg.toString(messageString) ))
break;
// ***
m_state.onEvent( "Resending Message: "
+ IntConvertor::convert( msgSeqNum ) );
begin = 0;

I tested in my quickfix application and it works, the application
finishes resending when socket is disconnected.
What do you think, do you see something wrong in this approach?

Regards,
Abel Monroy

Re: [Quickfix-developers] How do I manually reset my sequence number?

[Andrew C. <And...@Tw...>]

Check out the <Session>.seqnum in the store dir/db (or something close =
to
that)

The file/db table contains two seq number seperated by a colon - adjust =
the
first one to your broker's seq num

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
mrvictory1999
Sent: Monday, November 05, 2007 4:51 PM
To: qui...@li...
Subject: [Quickfix-developers] How do I manually reset my sequence =
number?


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


I am connecting to a broker using QuickFix.  In the case where our =
sequence
numbers get out of sync, I am having trouble re-syncing.

Specifically, if my QuickFix engine believes the sequence number should =
be
200, but the broker thinks it should be 300, I'll get a message like:
MsgSeqNum too low, expecting 300 but received 200 Logon

QuickFix will then repeatedly try to log in, incrementing the sequence
number each time. So after 100 tries, it'll be at the right number.

I need to know how to manually set my sequence number to 300 so that I =
can
skip the 100 reconnect attempts.

Thanks for your help!
Matt
--=20
View this message in context:
http://www.nabble.com/How-do-I-manually-reset-my-sequence-number--tf47546=
63.
html#a13596466
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Quickfix-developers mailing list =
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] How do I manually reset my sequence number?

[mrvictory1999 <nab...@xo...>]

I am connecting to a broker using QuickFix.  In the case where our sequence
numbers get out of sync, I am having trouble re-syncing.

Specifically, if my QuickFix engine believes the sequence number should be
200, but the broker thinks it should be 300, I'll get a message like:
MsgSeqNum too low, expecting 300 but received 200 Logon

QuickFix will then repeatedly try to log in, incrementing the sequence
number each time. So after 100 tries, it'll be at the right number.

I need to know how to manually set my sequence number to 300 so that I can
skip the 100 reconnect attempts.

Thanks for your help!
Matt
-- 
View this message in context: http://www.nabble.com/How-do-I-manually-reset-my-sequence-number--tf4754663.html#a13596466
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] MySQL store schema

[Djalma R. d. S. F. <drs...@gm...>]

You can find the scripts to create the db schema in src/sql/mysql.

On Nov 5, 2007 5:15 PM,  <sli...@ai...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Greetings,
>
>  I'm just getting started using Quickfix, and am curious as to the speed differences between using a MySQL message storage mechanism versus file storage.  Additionally, where would I go to get the MySQL db schema so I can configure my system to allow for this type of storage?
>
>  Thanks in advance.
>  ________________________________
>  Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] MySQL store schema

[<sli...@ai...>]

Greetings,



I'm just getting started using Quickfix, and am curious as to the speed 
differences between using a MySQL message storage mechanism versus file 
storage.? Additionally, where would I go to get the MySQL db schema so I 
can configure my system to allow for this type of storage?



Thanks in advance.

________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.

Re: [Quickfix-developers] .NET stopping and starting initiator

[Patrick W. <pw...@ka...>]

Thanks for the replies.

I think I have fixed this (for my own implementation). I discovered that
the CPPMessageStore.m_pUnmanaged was being deleted twice and worked out
that it was due to me obtaining a pointer to the messagestore in my
dotnet class:

        public virtual void onLogon(SessionID session_)
        {
            _messageStore =3D =
Session.lookupSession(session_).getStore();
	  }

Where _messageStore is defined as follows:
protected QuickFix.MessageStore _messageStore;

When I unload the above class I find that if I call SuppressFinalize the
error goes away:
        public virtual void Shutdown()
        {
            GC.SuppressFinalize(_messageStore);
            _messageStore =3D null;
            =20
        }

If I omit the suppressfinalize the underlying messagestore is double
deleted and the files can remain locked. Note that calling Dispose()
didn't help and the error remained even if I waited a few minutes for
the GC to do its job.=20

Patrick


-----Original Message-----
From: Francis Gingras [mailto:fr...@at...]=20
Sent: Wednesday, 31 October 2007 6:39 AM
To: Patrick Wright
Subject: RE: [Quickfix-developers] .NET stopping and starting initiator

Patrick,

I have had the same problem in various projects (and QF builds) for
years.
Disposing does not help in my case, nor does forcing garbage collection.
I
never figured out how to solve it so if you do please post the
resolution!

Thanks,

Francis


-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Tuesday, October 30, 2007 12:07
To: Patrick Wright
Cc: qui...@li...
Subject: Re: [Quickfix-developers] .NET stopping and starting initiator

Have you tried disposing the initiator?

--oren

On Oct 24, 2007, at 7:08 PM, Patrick Wright wrote:


	QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
	QuickFIX Support: http://www.quickfixengine.org/services.html


	Hi,

	=20

	When a socket initiator is stopped the storage files are still
in
use so that starting it again causes an error ('cannot open body file').

	I get the problem when using the .NET version of QuickFix 1.12.4
but
I notice that there is at least one other thread asking about this
problem.

	Here is the relevant code section copied from that previous
thread:

	=20

	> settings =3D new SessionSettings(configFile);

	> storeFactory =3D new
	> FileStoreFactory(settings); logFactory =3D new
FileLogFactory(settings);
	> messageFactory =3D new DefaultMessageFactory(); initiator =3D new
	> ThreadedSocketInitiator(this, storeFactory, settings,
logFactory,
	> messageFactory);
	>
	>...
	> initiator.start();
	>...
	> initiator.stop();
	> initiator =3D null;
	> settings =3D null;
	> storeFactory =3D null;
	> logFactory =3D null;
	> messageFactory =3D null;
	> ----------------------------------------
=09
	> At this point all of the four storage files are still locked
(can't be
	> opened in notepad). Forcing garbage collection doesn't help.

	=20

	My question is:

	Has anyone managed to work around/fix this problem?

	I am using QuickFix from a .NET 2.0 WinForms app in C#.

	=20

	Thanks,

	Patrick Wright

	=20

=09
------------------------------------------------------------------------
-
	This SF.net email is sponsored by: Splunk Inc.
	Still grepping through log files to find problems?  Stop.
	Now Search log events and configuration files using AJAX and a
browser.
	Download your FREE copy of Splunk now >>
http://get.splunk.com/_______________________________________________
	Quickfix-developers mailing list
	Qui...@li...
	https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Quickfix-developers Digest, Vol 17, Issue 10

[Ian S. <dar...@gm...>]

I was able to run the run_executor_python script you mentioned. When I
ran the executor.py directly, my mouse changed shape and the window
manager got weird in linux. Running the script file instead I was able
to get it working. With some directory shuffling and and to prove I
could, I was able to call executor.py directly. After comparing the
two files, I found the issue was linked to my use of
quickfix.Application rather than having written my own version of the
same class used in the script also called Application. Another example
I found uses MyApplication() instead but doesn't mention anything
about it. Long story (3.5 weeks) short, I needed to inherit rather
than instantiate.

Ian Smith

> Message: 2
> Date: Tue, 30 Oct 2007 09:43:37 -0500
> From: "Chris Busbey" <cb...@co...>
> Subject: Re: [Quickfix-developers] Python library errors
> To: qui...@li...
> Message-ID:
>         <67c...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Were you able to run the run_executor_python script in the bin directory?
>
> <http://www.quickfixengine.org/services.html>
> >
> > Hello,
> >
> > I would greatly appreciate assistance with python for Quickfix
> > My major issue is that there are no working examples of a
> > Python connection working. I tested my config file using Banzai, and
> > things are working for that connection now. On my compiled version
> > with Python 2.5 included, I get the following error:
> > NotImplementedError: No matching function for overloaded
> > 'new_SocketAcceptorBase' I have read through all of the documentation
> > I can find, and all of the python examples have flaws errors and bugs.
> > I fixed a few in order to make the code below, but I'm still having
> > serious issues. Maybe this is simple, and I just need to vary the
> > parameters I pass to SocketAcceptor.
> >
> > Building Python with quickfix took a very long time, I'm going to go
> > through the process again and try to write up better examples so other
> > people have a more "copy+paste" experience.
> >
> > Here is the error and code, from a terminal session.
> > import quickfix
> > def connecttest(file):
> >         try:
> >                 settings = quickfix.SessionSettings(file)
> >                 application = Application()
> >                 storeFactory = quickfix.FileStoreFactory(settings)
> >                 logFactory = quickfix.FileLogFactory(settings)
> >                 acceptor = quickfix.SocketAcceptor(application,
> > storeFactory,
> > settings, logFactory)
> >                 acceptor.start()
> >                 # while condition == true: do something
> >                 acceptor.stop()
> >         except quickfix.ConfigError, e:
> >                 print e
> >
> > connecttest("/tmp/config.ini")
> >
> > Traceback (most recent call last):
> >   File "<pyshell#41>", line 1, in <module>
> >     connecttest("/tmp/config.ini")
> >   File "<pyshell#40>", line 7, in connecttest
> >     acceptor = quickfix.SocketAcceptor(application, storeFactory,
> > settings, logFactory)
> >   File "/usr/lib/python2.5/site-packages/quickfix.py", line 19982, in
> > __init__
> >     def __init__(self, application, storeFactory, settings, logFactory):
> >   File "/usr/lib/python2.5/site-packages/quickfix.py", line 19940, in
> > __init__
> >     this = _quickfix.new_SocketAcceptorBase(*args) #orig
> > NotImplementedError: No matching function for overloaded
> > 'new_SocketAcceptorBase'
> >
> > --
> > Ian Smith
> >

Re: [Quickfix-developers] Custom Messages/Classes Tutorial

[Brian E. <azz...@ya...>]

Feel free. Make any changes you think need to be made - a lot of it was guesswork. You'll probably have to flesh out the Java/Ruby/Python stuff.

- Brian

----- Original Message ----
From: Oren Miller <or...@qu...>
To: Brian Erst <azz...@ya...>
Cc: qui...@li...
Sent: Tuesday, October 30, 2007 2:18:58 PM
Subject: Re: [Quickfix-developers] Custom Messages/Classes Tutorial


QuickFIX Documentation:
 http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Fantastic work Brian.  I'll try to incorporate this into the standard documentation if you don't mind.

--oren

On Oct 30, 2007, at 2:04 PM, Brian Erst wrote:

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


 I decided to write a little tutorial on adding custom messages that act exactly like QuickFIX classes, as I haven't found anything in the mailing lists (and nothing in the documentation) that covers this subject. Oren, et al, feel free to critique, adapt and extend as needed.

Everything below assumes you are working on a Windows machine using VS2005 - most of the steps should be identical in other environments. Using these techniques will cause you to create a customized version of QuickFIX - you will need to repeat most of these steps whenever you wish to upgrade to a new version of QuickFIX.

Customizing QuickFIX with New Message Classes and Fields

Many counterparties have extended the FIX standard with custom messages and fields. If the only changes are a couple of custom fields, this tutorial is serious overkill; you are much better off simply defining the custom fields directly:
#include "quickfix/Field.h"

  namespace FIX
  {
    USER_DEFINE_STRING(MyStringField, 6123);
    USER_DEFINE_PRICE(MyPriceField, 8756);
  }Even if your counterparty has defined a new outbound message, you can simply create a Message object and set the fields manually.

If, however, your counterparty has created a whole host of new messages, inbound and outbound, you may want to build support for those messages directly into QuickFIX. In order to do this, you will need to create a custom build. This requires a couple of tools you may not have lying around, some comfort editing XML files and projects, a little understanding about the differences in how QuickFIX builds source code for different languages and a little fortitude.

New Tools

QuickFIX uses a combination of XML, XSL and Ruby scripts in order to generate the source code of messages and fields. In the Windows environment, it requires two tools that many developers will not have handy: msxsl and Ruby. Fortunately, both of these tools are easy to get and free for use.

msxsl is a Microsoft tool that takes XML, transforms it using rules defined in XSL style sheets and outputs new files. As of this writing, it can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyId=2FB55371-C94E-4373-B0E9-DB4816552E41&displaylang=en. If that doesn't work, just use Google to look up "msxsl" - it's the first link returned. Place the msxsl.exe file somewhere on your PATH.

Ruby is a scripting language created by Yukihiro Matsumoto. It is similar to perl, python and other scripting languages. You can download the latest versions of Ruby from the following link: http://www.ruby-lang.org/en/downloads/  One caveat: the current version of the One-Click Installer for Ruby (1.8.6-25) has a bug in its modification of your PATH variable - it will wipe it out while adding the Ruby path. Save a copy of your PATH variable prior to install, and then restore it, making sure to keep/add the Ruby path.

Getting Prepared

Before building your custom version of QuickFIX, you should be sure to have the latest source code (currently 1.12.4). You will need the tools described above, as well as a copy of Visual Studio. Currently, VS 6.0, 2003 and 2005 are supported.

Get acquainted with the way the source code and projects are laid out. The subdirectories we're most interested in are .\quickfix (where the projects/solutions reside) and .\quickfix\spec (where the XML, XSL and code generation scripts reside).

Also, have a copy of your counterparty's documentation, and figure out which fields and/or messages you need to implement.

 Editing the XML/XSL
 
QuickFIX defines all of the FIX messages in terms of XML data dictionaries (FIX4n.XML, where 'n' is the minor version number) in the .\quickfix\spec directory. These data dictionaries are a two-fer: they not only control how QuickFIX validates messages at run-time, but they are also used to create the message classes, fields and field value constants. With a little care, you can add new messages and fields to the XML files and generate new classes using the provided generate script. If you have new fields, you may also need to edit one of the XSL files, but this is much simpler.

Two last things before we dive into editing the XML/XSL files. First, QuickFIX takes one shortcut when defining fields and message crackers - it assumes that FIX44.XML contains a superset of all messages and fields. This means that even if your counterparty uses FIX 4.2, you cannot just modify the FIX42.XML file. You must also create at least a "stub" copy of the messages and full copies of the fields in FIX44.XML. We'll see how in a minute.

Second, QuickFIX uses the "required" attribute of tags when generating constructors for message objects. If the required attribute is set to "Y", that field will become part of a constructor. Don't be tempted to set the required attribute to "Y" on the existing fields of an existing message. Even if your counterparty requires the RawData field on a Logon message, this is not the place to force that validation. If you do it here, much of the QuickFIX build will fail, as many of the acceptance tests will not be able to construct message objects that have suddenly gained a required parameter. Once you've built your custom version of QuickFIX, make a copy of your XML files to your deployment environment and modify those copies to make fields required at run-time. Perhaps a future version of QuickFIX could add another attribute that could distinguish between "required for constructors" and "required for run-time validation".

The various FIX4n.XML files are laid out in a standard way. The main node is <fix>, with the major and minor version numbers defined. The main subnodes are <header> (defining the header fields), <trailer> (defining the trailer fields), <messages> (a list message definitions supported by this version of FIX) and <fields> (a list of fields, and optional values, supported by this version of FIX). We're most interested in <messages> and <fields>, but as messages are simply groups of fields, let's look at fields first.

Adding New Fields

If your custom message(s) only use fields already defined in your version of FIX, you're in luck! You can skip this section. For the rest of us unfortunates, we will need to edit at least the XML and probably one XSL file (FieldNumbers.xsl).

If your counterparty has any sense at all (an iffy proposition considering that they created custom messages), they will confine their new fields to the proper User Defined Fields range of 5000-9999 defined in the FIX protocol. If not, and they've done something so stupid as to use tag numbers that exist in subsequent versions of the FIX specification - I'm sorry, but you've fallen out of the scope of this document. But you should be able to read on to get some idea as to what you might need to do.

For the rest of us, let's look at adding a new field. The ICE exchange has extended FIX 4.2 to add the field 9208 as CTICode, an integer field that can only contain the values 1-4, each of which has a specific meaning. To add this field to various messages, we need to define it within the <fields> node of FIX42.XML. This entails creating a new node <field> within the <fields> node. The best and easiest place to do this is at the end of the existing list. Just look for </fields> and move up a line.

We now need to create that new node. You will notice that the other fields have a very standardized format, with a couple of attributes and an optional list of values defined as subnodes. You can make a copy of an existing field that most closely matches your need and modify it, or just create a new one. It's pretty simple; here's the definition of CTICode:

    <field number="9208" name="CTICode" type="INT">
      <value enum="1" description="OWN_ACCOUNT"/>
      <value enum="2" description="HOUSE_ACCOUNT"/>
      <value enum="3" description="OTHER_BROKER_ACCOUNT"/>
      <value enum="4" description="CUSTOMER_ACCOUNT"/>
    </field>

We've just defined a new field. It has a number/value (9208), a name (CTICode) and a type (INT - integer). This field will now become a recognized, named field within QuickFIX (or, it will after we finish this process) and can be added to new and existing messages. It will also have a list of enumerated values, also named and usable throughout QuickFIX (in C++, the first value will become const int CTICode_OWN_ACCOUNT = 1 in Values.h).

Look at the existing fields to find examples of strings, currencies and amounts, as well as fields that do not have enumerated values (they're even simpler - just one line). You can also now modify existing messages to add this custom field - just be sure not to use the required="Y" attribute, as it will modify the constructors and cause the build to fail. You can set the required="Y" attribute in your deployment version of the XML if you need it at run-time.

But we're not done with this field. We have now extended the range of valid field numbers within the FIX 4.2 namespace - we've got to let the message generator know this. This is handled within the FieldNumbers.XSL stylesheet. Within that file, you will see some template text, one line of which is:

,FIX42_LastField=EncodedListStatusText,

You need to change this value to be the name of the field with the largest field number that you have added. In our case, the largest number is 9208, or CTICode, so we modify the line to be:

,FIX42_LastField=CTICode,

Save that change.

The final step in the process is that we have to add these fields to FIX44.XML. If you're lucky enough to have found a counterparty that actually uses FIX 4.4, you're done! If not, you have to add the same field definitions to the FIX44.XML file - the code generator scripts use this file only to generate fields and values. You should not, however, add the new fields to any of the messages that you modified in the other XML files unless you plan on using those fields with FIX 4.4.

Now, on to custom messages.

Adding New Messages
 
If you just read about adding fields, you'll find that adding messages is very similar. If you skipped that section, don't worry - it's pretty simple. 

Let's look at adding a new message. The ICE exchange has extended FIX 4.2 to add the message TraderLogout, defined as message type "CH". To add this message, we need to define any new fields it might use (as above), and then define it within the <messages> node of FIX42.XML. This entails creating a new node <message> within the <messages> node. The best and easiest place to do this is at the end of the existing list. Just look for </messages> and move up a line.
 
 We now need to create that new node. You will notice that the other messages have a very standardized format, with a couple of attributes and an list of fields defined as subnodes. You can make a copy of an existing message that most closely matches your need and modify it, or just create a new one. It's pretty simple; here's the definition of TraderLogout:
 
    <message name="TraderLogout" msgtype="CH" msgcat="app">
      <field name="ClientID" required="N"/>
      <field name="Username" required="Y"/>
    </message>    

 We've just defined a new message. It has a name (TraderLogout), a message type (tag 35 will be set to "CH") and a category (either "app" or "admin" - while it mostly just determines how the messages will be cracked, you will almost always be creating "app" messages). This message will now become a recognized, named class within QuickFIX (or, it will after we finish this process) with its own source code (in separate files for C++, Java and .Net, or as part of a larger file in Python and Ruby).
 
For our custom messages, feel free to use the required="Y" attribute - this is used by the code generator to add that field to the list of parameters on the class constructor. If the field is required, we might as well require it to construct the object.
 
 But we're not done with this message. The final step in the process is that we have to add these messages to FIX44.XML. If you're lucky enough to have found a counterparty that actually uses FIX 4.4, you're done! If not, you have to add a version of these messages to the FIX44.XML file - the code generator scripts use this file when defining the message types. Without modifying FIX44.XML, you will not be able to crack these new messages (and the build will fail). Unless you plan on using these messages with FIX 4.4, you do not actually have to fully define the message - there's no need to have fields in the message. In some cases, it is critical not to copy the whole message - any message that contains a field deprecated in FIX 4.4 (like ClientID) will not build properly if it exists in the 4.4 XML.
 
 Now that we've added our fields and messages, let's generate the source code.

 Generating the Source Code

This is the easiest part - assuming that everything was edited correctly and you have installed the msxsl and Ruby tools. From the command line, go to the .\quickfix\spec directory and type:

generate

This fires off a batch file that will generate the source code. Various nested batch files will be invoked, each of which use the msxsl and Ruby tools to generate code and, in the case of the Java build, modify the batch files themselves. 

The XML transforms via msxsl are done relatively quickly. These build the initial versions of the Field, FieldNumbers and Values files.

The Ruby scripts generate the bulk of the code (message and field classes) and take quite a while to complete. The scripts iterate through each of versions of FIX (4.1-4.4) and each of the languages (C++, Java, .Net, Python and Ruby). You can watch the code being updated by watching the .\quickfix\src\[language]\...\fix4n directories.

If things go badly, it's sometimes difficult to figure out why. The scripts don't do a lot of logging, so you may be in for some headscratching. Things to look out for are deprecated fields (a big problem - avoid this at all costs), fields from a subsequent version of FIX used in a prior version (example: a FIX 4.3 field in a 4.2 message - this can be handled by adding the field to the 4.2 XML) and improper formatting of the XML.

Good luck!

Building QuickFix (Visual Studio 2005)

I'd love to tell you that now that the code has been generated, that building it is a snap. It almost is! The problem is that in at least one case (.Net), the code generator has generated new source code files that have to be added to the build project. The C++ version primarily creates header files - as they are #included via other header files, they don't need to be added to a project in order for it to build, but you may want to for completeness sake.

In the case of .Net, you will need to add the generated .cs files to the project. This is pretty simple - in Visual Studio 2005, there is a quickfix_net_messages_vs8 project that contains all the version-specific code in subprojects (fix41-fix44). If you right-click one of those subprojects and "Add-->Existing Item...", you should easily be able to add the new files needed. The simplest way is to simply select all the .cs files in the appropriate subdirectory (e.g., fix42) and add them. Preexisting files will be ignored and the new files will be added.

You can now build the solution and, if everything went well, you will have a new set of .lib and .dll files that can be used as replacements for the standard QuickFIX libraries.

I have not used the Java, Ruby or Python versions, so building those are left as an exercise for the reader.

Using Your Custom Version of QuickFIX

Using the customized version of QuickFIX is exactly the same as the standard version - you just have to add .lib or .dll files to the right places and use the custom-generated header files. All other aspects of QuickFIX programming are the same.
 
I hope this tutorial has been helpful for anyone looking to use custom messages with QuickFIX. I wish I had had it when I started! Please let me know if I've missed anything or got some detail wrong - I'll need to know myself!

- Brian Erst
Thynk Software, Inc.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
 

Re: [Quickfix-developers] Custom Messages/Classes Tutorial

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

Fantastic work Brian.  I'll try to incorporate this into the standard  
documentation if you don't mind.

--oren

On Oct 30, 2007, at 2:04 PM, Brian Erst wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I decided to write a little tutorial on adding custom messages that  
> act exactly like QuickFIX classes, as I haven't found anything in  
> the mailing lists (and nothing in the documentation) that covers  
> this subject. Oren, et al, feel free to critique, adapt and extend  
> as needed.
>
> Everything below assumes you are working on a Windows machine using  
> VS2005 - most of the steps should be identical in other  
> environments. Using these techniques will cause you to create a  
> customized version of QuickFIX - you will need to repeat most of  
> these steps whenever you wish to upgrade to a new version of QuickFIX.
>
> Customizing QuickFIX with New Message Classes and Fields
>
> Many counterparties have extended the FIX standard with custom  
> messages and fields. If the only changes are a couple of custom  
> fields, this tutorial is serious overkill; you are much better off  
> simply defining the custom fields directly:
> #include "quickfix/Field.h"
>
>   namespace FIX
>   {
>     USER_DEFINE_STRING(MyStringField, 6123);
>     USER_DEFINE_PRICE(MyPriceField, 8756);
>   }
> Even if your counterparty has defined a new outbound message, you  
> can simply create a Message object and set the fields manually.
>
> If, however, your counterparty has created a whole host of new  
> messages, inbound and outbound, you may want to build support for  
> those messages directly into QuickFIX. In order to do this, you  
> will need to create a custom build. This requires a couple of tools  
> you may not have lying around, some comfort editing XML files and  
> projects, a little understanding about the differences in how  
> QuickFIX builds source code for different languages and a little  
> fortitude.
>
> New Tools
>
> QuickFIX uses a combination of XML, XSL and Ruby scripts in order  
> to generate the source code of messages and fields. In the Windows  
> environment, it requires two tools that many developers will not  
> have handy: msxsl and Ruby. Fortunately, both of these tools are  
> easy to get and free for use.
>
> msxsl is a Microsoft tool that takes XML, transforms it using rules  
> defined in XSL style sheets and outputs new files. As of this  
> writing, it can be found here: http://www.microsoft.com/downloads/ 
> details.aspx?FamilyId=2FB55371-C94E-4373-B0E9- 
> DB4816552E41&displaylang=en. If that doesn't work, just use Google  
> to look up "msxsl" - it's the first link returned. Place the  
> msxsl.exe file somewhere on your PATH.
>
> Ruby is a scripting language created by Yukihiro Matsumoto. It is  
> similar to perl, python and other scripting languages. You can  
> download the latest versions of Ruby from the following link:  
> http://www.ruby-lang.org/en/downloads/  One caveat: the current  
> version of the One-Click Installer for Ruby (1.8.6-25) has a bug in  
> its modification of your PATH variable - it will wipe it out while  
> adding the Ruby path. Save a copy of your PATH variable prior to  
> install, and then restore it, making sure to keep/add the Ruby path.
>
> Getting Prepared
>
> Before building your custom version of QuickFIX, you should be sure  
> to have the latest source code (currently 1.12.4). You will need  
> the tools described above, as well as a copy of Visual Studio.  
> Currently, VS 6.0, 2003 and 2005 are supported.
>
> Get acquainted with the way the source code and projects are laid  
> out. The subdirectories we're most interested in are .\quickfix  
> (where the projects/solutions reside) and .\quickfix\spec (where  
> the XML, XSL and code generation scripts reside).
>
> Also, have a copy of your counterparty's documentation, and figure  
> out which fields and/or messages you need to implement.
>
> Editing the XML/XSL
>
> QuickFIX defines all of the FIX messages in terms of XML data  
> dictionaries (FIX4n.XML, where 'n' is the minor version number) in  
> the .\quickfix\spec directory. These data dictionaries are a two- 
> fer: they not only control how QuickFIX validates messages at run- 
> time, but they are also used to create the message classes, fields  
> and field value constants. With a little care, you can add new  
> messages and fields to the XML files and generate new classes using  
> the provided generate script. If you have new fields, you may also  
> need to edit one of the XSL files, but this is much simpler.
>
> Two last things before we dive into editing the XML/XSL files.  
> First, QuickFIX takes one shortcut when defining fields and message  
> crackers - it assumes that FIX44.XML contains a superset of all  
> messages and fields. This means that even if your counterparty uses  
> FIX 4.2, you cannot just modify the FIX42.XML file. You must also  
> create at least a "stub" copy of the messages and full copies of  
> the fields in FIX44.XML. We'll see how in a minute.
>
> Second, QuickFIX uses the "required" attribute of tags when  
> generating constructors for message objects. If the required  
> attribute is set to "Y", that field will become part of a  
> constructor. Don't be tempted to set the required attribute to "Y"  
> on the existing fields of an existing message. Even if your  
> counterparty requires the RawData field on a Logon message, this is  
> not the place to force that validation. If you do it here, much of  
> the QuickFIX build will fail, as many of the acceptance tests will  
> not be able to construct message objects that have suddenly gained  
> a required parameter. Once you've built your custom version of  
> QuickFIX, make a copy of your XML files to your deployment  
> environment and modify those copies to make fields required at run- 
> time. Perhaps a future version of QuickFIX could add another  
> attribute that could distinguish between "required for  
> constructors" and "required for run-time validation".
>
> The various FIX4n.XML files are laid out in a standard way. The  
> main node is <fix>, with the major and minor version numbers  
> defined. The main subnodes are <header> (defining the header  
> fields), <trailer> (defining the trailer fields), <messages> (a  
> list message definitions supported by this version of FIX) and  
> <fields> (a list of fields, and optional values, supported by this  
> version of FIX). We're most interested in <messages> and <fields>,  
> but as messages are simply groups of fields, let's look at fields  
> first.
>
> Adding New Fields
>
> If your custom message(s) only use fields already defined in your  
> version of FIX, you're in luck! You can skip this section. For the  
> rest of us unfortunates, we will need to edit at least the XML and  
> probably one XSL file (FieldNumbers.xsl).
>
> If your counterparty has any sense at all (an iffy proposition  
> considering that they created custom messages), they will confine  
> their new fields to the proper User Defined Fields range of  
> 5000-9999 defined in the FIX protocol. If not, and they've done  
> something so stupid as to use tag numbers that exist in subsequent  
> versions of the FIX specification - I'm sorry, but you've fallen  
> out of the scope of this document. But you should be able to read  
> on to get some idea as to what you might need to do.
>
> For the rest of us, let's look at adding a new field. The ICE  
> exchange has extended FIX 4.2 to add the field 9208 as CTICode, an  
> integer field that can only contain the values 1-4, each of which  
> has a specific meaning. To add this field to various messages, we  
> need to define it within the <fields> node of FIX42.XML. This  
> entails creating a new node <field> within the <fields> node. The  
> best and easiest place to do this is at the end of the existing  
> list. Just look for </fields> and move up a line.
>
> We now need to create that new node. You will notice that the other  
> fields have a very standardized format, with a couple of attributes  
> and an optional list of values defined as subnodes. You can make a  
> copy of an existing field that most closely matches your need and  
> modify it, or just create a new one. It's pretty simple; here's the  
> definition of CTICode:
>
>     <field number="9208" name="CTICode" type="INT">
>       <value enum="1" description="OWN_ACCOUNT"/>
>       <value enum="2" description="HOUSE_ACCOUNT"/>
>       <value enum="3" description="OTHER_BROKER_ACCOUNT"/>
>       <value enum="4" description="CUSTOMER_ACCOUNT"/>
>     </field>
>
> We've just defined a new field. It has a number/value (9208), a  
> name (CTICode) and a type (INT - integer). This field will now  
> become a recognized, named field within QuickFIX (or, it will after  
> we finish this process) and can be added to new and existing  
> messages. It will also have a list of enumerated values, also named  
> and usable throughout QuickFIX (in C++, the first value will become  
> const int CTICode_OWN_ACCOUNT = 1 in Values.h).
>
> Look at the existing fields to find examples of strings, currencies  
> and amounts, as well as fields that do not have enumerated values  
> (they're even simpler - just one line). You can also now modify  
> existing messages to add this custom field - just be sure not to  
> use the required="Y" attribute, as it will modify the constructors  
> and cause the build to fail. You can set the required="Y" attribute  
> in your deployment version of the XML if you need it at run-time.
>
> But we're not done with this field. We have now extended the range  
> of valid field numbers within the FIX 4.2 namespace - we've got to  
> let the message generator know this. This is handled within the  
> FieldNumbers.XSL stylesheet. Within that file, you will see some  
> template text, one line of which is:
>
> ,FIX42_LastField=EncodedListStatusText,
>
> You need to change this value to be the name of the field with the  
> largest field number that you have added. In our case, the largest  
> number is 9208, or CTICode, so we modify the line to be:
>
> ,FIX42_LastField=CTICode,
>
> Save that change.
>
> The final step in the process is that we have to add these fields  
> to FIX44.XML. If you're lucky enough to have found a counterparty  
> that actually uses FIX 4.4, you're done! If not, you have to add  
> the same field definitions to the FIX44.XML file - the code  
> generator scripts use this file only to generate fields and values.  
> You should not, however, add the new fields to any of the messages  
> that you modified in the other XML files unless you plan on using  
> those fields with FIX 4.4.
>
> Now, on to custom messages.
>
> Adding New Messages
>
> If you just read about adding fields, you'll find that adding  
> messages is very similar. If you skipped that section, don't worry  
> - it's pretty simple.
>
> Let's look at adding a new message. The ICE exchange has extended  
> FIX 4.2 to add the message TraderLogout, defined as message type  
> "CH". To add this message, we need to define any new fields it  
> might use (as above), and then define it within the <messages> node  
> of FIX42.XML. This entails creating a new node <message> within the  
> <messages> node. The best and easiest place to do this is at the  
> end of the existing list. Just look for </messages> and move up a  
> line.
>
> We now need to create that new node. You will notice that the other  
> messages have a very standardized format, with a couple of  
> attributes and an list of fields defined as subnodes. You can make  
> a copy of an existing message that most closely matches your need  
> and modify it, or just create a new one. It's pretty simple; here's  
> the definition of TraderLogout:
>
>     <message name="TraderLogout" msgtype="CH" msgcat="app">
>       <field name="ClientID" required="N"/>
>       <field name="Username" required="Y"/>
>     </message>
>
> We've just defined a new message. It has a name (TraderLogout), a  
> message type (tag 35 will be set to "CH") and a category (either  
> "app" or "admin" - while it mostly just determines how the messages  
> will be cracked, you will almost always be creating "app"  
> messages). This message will now become a recognized, named class  
> within QuickFIX (or, it will after we finish this process) with its  
> own source code (in separate files for C++, Java and .Net, or as  
> part of a larger file in Python and Ruby).
>
> For our custom messages, feel free to use the required="Y"  
> attribute - this is used by the code generator to add that field to  
> the list of parameters on the class constructor. If the field is  
> required, we might as well require it to construct the object.
>
> But we're not done with this message. The final step in the process  
> is that we have to add these messages to FIX44.XML. If you're lucky  
> enough to have found a counterparty that actually uses FIX 4.4,  
> you're done! If not, you have to add a version of these messages to  
> the FIX44.XML file - the code generator scripts use this file when  
> defining the message types. Without modifying FIX44.XML, you will  
> not be able to crack these new messages (and the build will fail).  
> Unless you plan on using these messages with FIX 4.4, you do not  
> actually have to fully define the message - there's no need to have  
> fields in the message. In some cases, it is critical not to copy  
> the whole message - any message that contains a field deprecated in  
> FIX 4.4 (like ClientID) will not build properly if it exists in the  
> 4.4 XML.
>
> Now that we've added our fields and messages, let's generate the  
> source code.
>
> Generating the Source Code
>
> This is the easiest part - assuming that everything was edited  
> correctly and you have installed the msxsl and Ruby tools. From the  
> command line, go to the .\quickfix\spec directory and type:
>
> generate
>
> This fires off a batch file that will generate the source code.  
> Various nested batch files will be invoked, each of which use the  
> msxsl and Ruby tools to generate code and, in the case of the Java  
> build, modify the batch files themselves.
>
> The XML transforms via msxsl are done relatively quickly. These  
> build the initial versions of the Field, FieldNumbers and Values  
> files.
>
> The Ruby scripts generate the bulk of the code (message and field  
> classes) and take quite a while to complete. The scripts iterate  
> through each of versions of FIX (4.1-4.4) and each of the languages  
> (C++, Java, .Net, Python and Ruby). You can watch the code being  
> updated by watching the .\quickfix\src\[language]\...\fix4n  
> directories.
>
> If things go badly, it's sometimes difficult to figure out why. The  
> scripts don't do a lot of logging, so you may be in for some  
> headscratching. Things to look out for are deprecated fields (a big  
> problem - avoid this at all costs), fields from a subsequent  
> version of FIX used in a prior version (example: a FIX 4.3 field in  
> a 4.2 message - this can be handled by adding the field to the 4.2  
> XML) and improper formatting of the XML.
>
> Good luck!
>
> Building QuickFix (Visual Studio 2005)
>
> I'd love to tell you that now that the code has been generated,  
> that building it is a snap. It almost is! The problem is that in at  
> least one case (.Net), the code generator has generated new source  
> code files that have to be added to the build project. The C++  
> version primarily creates header files - as they are #included via  
> other header files, they don't need to be added to a project in  
> order for it to build, but you may want to for completeness sake.
>
> In the case of .Net, you will need to add the generated .cs files  
> to the project. This is pretty simple - in Visual Studio 2005,  
> there is a quickfix_net_messages_vs8 project that contains all the  
> version-specific code in subprojects (fix41-fix44). If you right- 
> click one of those subprojects and "Add-->Existing Item...", you  
> should easily be able to add the new files needed. The simplest way  
> is to simply select all the .cs files in the appropriate  
> subdirectory (e.g., fix42) and add them. Preexisting files will be  
> ignored and the new files will be added.
>
> You can now build the solution and, if everything went well, you  
> will have a new set of .lib and .dll files that can be used as  
> replacements for the standard QuickFIX libraries.
>
> I have not used the Java, Ruby or Python versions, so building  
> those are left as an exercise for the reader.
>
> Using Your Custom Version of QuickFIX
>
> Using the customized version of QuickFIX is exactly the same as the  
> standard version - you just have to add .lib or .dll files to the  
> right places and use the custom-generated header files. All other  
> aspects of QuickFIX programming are the same.
>
> I hope this tutorial has been helpful for anyone looking to use  
> custom messages with QuickFIX. I wish I had had it when I started!  
> Please let me know if I've missed anything or got some detail wrong  
> - I'll need to know myself!
>
> - Brian Erst
> Thynk Software, Inc.
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/ 
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Custom Messages/Classes Tutorial

[Brian E. <azz...@ya...>]

I decided to write a little tutorial on adding custom messages that act exactly like QuickFIX classes, as I haven't found anything in the mailing lists (and nothing in the documentation) that covers this subject. Oren, et al, feel free to critique, adapt and extend as needed.

Everything below assumes you are working on a Windows machine using VS2005 - most of the steps should be identical in other environments. Using these techniques will cause you to create a customized version of QuickFIX - you will need to repeat most of these steps whenever you wish to upgrade to a new version of QuickFIX.

Customizing QuickFIX with New Message Classes and Fields

Many counterparties have extended the FIX standard with custom messages and fields. If the only changes are a couple of custom fields, this tutorial is serious overkill; you are much better off simply defining the custom fields directly:
#include "quickfix/Field.h"

  namespace FIX
  {
    USER_DEFINE_STRING(MyStringField, 6123);
    USER_DEFINE_PRICE(MyPriceField, 8756);
  }Even if your counterparty has defined a new outbound message, you can simply create a Message object and set the fields manually.

If, however, your counterparty has created a whole host of new messages, inbound and outbound, you may want to build support for those messages directly into QuickFIX. In order to do this, you will need to create a custom build. This requires a couple of tools you may not have lying around, some comfort editing XML files and projects, a little understanding about the differences in how QuickFIX builds source code for different languages and a little fortitude.

New Tools

QuickFIX uses a combination of XML, XSL and Ruby scripts in order to generate the source code of messages and fields. In the Windows environment, it requires two tools that many developers will not have handy: msxsl and Ruby. Fortunately, both of these tools are easy to get and free for use.

msxsl is a Microsoft tool that takes XML, transforms it using rules defined in XSL style sheets and outputs new files. As of this writing, it can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyId=2FB55371-C94E-4373-B0E9-DB4816552E41&displaylang=en. If that doesn't work, just use Google to look up "msxsl" - it's the first link returned. Place the msxsl.exe file somewhere on your PATH.

Ruby is a scripting language created by Yukihiro Matsumoto. It is similar to perl, python and other scripting languages. You can download the latest versions of Ruby from the following link: http://www.ruby-lang.org/en/downloads/  One caveat: the current version of the One-Click Installer for Ruby (1.8.6-25) has a bug in its modification of your PATH variable - it will wipe it out while adding the Ruby path. Save a copy of your PATH variable prior to install, and then restore it, making sure to keep/add the Ruby path.

Getting Prepared

Before building your custom version of QuickFIX, you should be sure to have the latest source code (currently 1.12.4). You will need the tools described above, as well as a copy of Visual Studio. Currently, VS 6.0, 2003 and 2005 are supported.

Get acquainted with the way the source code and projects are laid out. The subdirectories we're most interested in are .\quickfix (where the projects/solutions reside) and .\quickfix\spec (where the XML, XSL and code generation scripts reside).

Also, have a copy of your counterparty's documentation, and figure out which fields and/or messages you need to implement.


Editing the XML/XSL


QuickFIX defines all of the FIX messages in terms of XML data dictionaries (FIX4n.XML, where 'n' is the minor version number) in the .\quickfix\spec directory. These data dictionaries are a two-fer: they not only control how QuickFIX validates messages at run-time, but they are also used to create the message classes, fields and field value constants. With a little care, you can add new messages and fields to the XML files and generate new classes using the provided generate script. If you have new fields, you may also need to edit one of the XSL files, but this is much simpler.

Two last things before we dive into editing the XML/XSL files. First, QuickFIX takes one shortcut when defining fields and message crackers - it assumes that FIX44.XML contains a superset of all messages and fields. This means that even if your counterparty uses FIX 4.2, you cannot just modify the FIX42.XML file. You must also create at least a "stub" copy of the messages and full copies of the fields in FIX44.XML. We'll see how in a minute.

Second, QuickFIX uses the "required" attribute of tags when generating constructors for message objects. If the required attribute is set to "Y", that field will become part of a constructor. Don't be tempted to set the required attribute to "Y" on the existing fields of an existing message. Even if your counterparty requires the RawData field on a Logon message, this is not the place to force that validation. If you do it here, much of the QuickFIX build will fail, as many of the acceptance tests will not be able to construct message objects that have suddenly gained a required parameter. Once you've built your custom version of QuickFIX, make a copy of your XML files to your deployment environment and modify those copies to make fields required at run-time. Perhaps a future version of QuickFIX could add another attribute that could distinguish between "required for constructors" and "required for run-time validation".

The various FIX4n.XML files are laid out in a standard way. The main node is <fix>, with the major and minor version numbers defined. The main subnodes are <header> (defining the header fields), <trailer> (defining the trailer fields), <messages> (a list message definitions supported by this version of FIX) and <fields> (a list of fields, and optional values, supported by this version of FIX). We're most interested in <messages> and <fields>, but as messages are simply groups of fields, let's look at fields first.

Adding New Fields

If your custom message(s) only use fields already defined in your version of FIX, you're in luck! You can skip this section. For the rest of us unfortunates, we will need to edit at least the XML and probably one XSL file (FieldNumbers.xsl).

If your counterparty has any sense at all (an iffy proposition considering that they created custom messages), they will confine their new fields to the proper User Defined Fields range of 5000-9999 defined in the FIX protocol. If not, and they've done something so stupid as to use tag numbers that exist in subsequent versions of the FIX specification - I'm sorry, but you've fallen out of the scope of this document. But you should be able to read on to get some idea as to what you might need to do.

For the rest of us, let's look at adding a new field. The ICE exchange has extended FIX 4.2 to add the field 9208 as CTICode, an integer field that can only contain the values 1-4, each of which has a specific meaning. To add this field to various messages, we need to define it within the <fields> node of FIX42.XML. This entails creating a new node <field> within the <fields> node. The best and easiest place to do this is at the end of the existing list. Just look for </fields> and move up a line.

We now need to create that new node. You will notice that the other fields have a very standardized format, with a couple of attributes and an optional list of values defined as subnodes. You can make a copy of an existing field that most closely matches your need and modify it, or just create a new one. It's pretty simple; here's the definition of CTICode:

    <field number="9208" name="CTICode" type="INT">
      <value enum="1" description="OWN_ACCOUNT"/>
      <value enum="2" description="HOUSE_ACCOUNT"/>
      <value enum="3" description="OTHER_BROKER_ACCOUNT"/>
      <value enum="4" description="CUSTOMER_ACCOUNT"/>
    </field>

We've just defined a new field. It has a number/value (9208), a name (CTICode) and a type (INT - integer). This field will now become a recognized, named field within QuickFIX (or, it will after we finish this process) and can be added to new and existing messages. It will also have a list of enumerated values, also named and usable throughout QuickFIX (in C++, the first value will become const int CTICode_OWN_ACCOUNT = 1 in Values.h).

Look at the existing fields to find examples of strings, currencies and amounts, as well as fields that do not have enumerated values (they're even simpler - just one line). You can also now modify existing messages to add this custom field - just be sure not to use the required="Y" attribute, as it will modify the constructors and cause the build to fail. You can set the required="Y" attribute in your deployment version of the XML if you need it at run-time.

But we're not done with this field. We have now extended the range of valid field numbers within the FIX 4.2 namespace - we've got to let the message generator know this. This is handled within the FieldNumbers.XSL stylesheet. Within that file, you will see some template text, one line of which is:

,FIX42_LastField=EncodedListStatusText,

You need to change this value to be the name of the field with the largest field number that you have added. In our case, the largest number is 9208, or CTICode, so we modify the line to be:

,FIX42_LastField=CTICode,

Save that change.

The final step in the process is that we have to add these fields to FIX44.XML. If you're lucky enough to have found a counterparty that actually uses FIX 4.4, you're done! If not, you have to add the same field definitions to the FIX44.XML file - the code generator scripts use this file only to generate fields and values. You should not, however, add the new fields to any of the messages that you modified in the other XML files unless you plan on using those fields with FIX 4.4.

Now, on to custom messages.

Adding New Messages


If you just read about adding fields, you'll find that adding messages is very similar. If you skipped that section, don't worry - it's pretty simple. 

Let's look at adding a new message. The ICE exchange has extended FIX 4.2 to add the message TraderLogout, defined as message type "CH". To add this message, we need
to define any new fields it might use (as above), and then define it within the <messages> node of FIX42.XML. This entails
creating a new node <message> within the <messages> node. The
best and easiest place to do this is at the end of the existing list.
Just look for </messages> and move up a line.



We now need to create that new node. You will notice that the other
messages have a very standardized format, with a couple of attributes and
an list of fields defined as subnodes. You can make a copy of
an existing message that most closely matches your need and modify it, or
just create a new one. It's pretty simple; here's the definition of TraderLogout:


    <message name="TraderLogout" msgtype="CH" msgcat="app">
      <field name="ClientID" required="N"/>
      <field name="Username" required="Y"/>
    </message>    


We've just defined a new message. It has a name
(TraderLogout), a message type (tag 35 will be set to "CH") and a category (either "app" or "admin" - while it mostly just determines how the messages will be cracked, you will almost always be creating "app" messages). This message will now become a
recognized, named class within QuickFIX (or, it will after we finish
this process) with its own source code (in separate files for C++, Java and .Net, or as part of a larger file in Python and Ruby).


For our custom messages, feel free to use the required="Y" attribute - this is used by the code generator to add that field to the list of parameters on the class constructor. If the field is required, we might as well require it to construct the object.



But we're not done with this message. The final step in the process is that we have to add these messages to
FIX44.XML. If you're lucky enough to have found a counterparty that
actually uses FIX 4.4, you're done! If not, you have to add a version of these messages to the FIX44.XML file - the code generator scripts use this file when defining the message types. Without modifying FIX44.XML, you will not be able to crack these new messages (and the build will fail). Unless you plan on using these messages with FIX 4.4, you do not actually have to fully define the message - there's no need to have fields in the message. In some cases, it is critical not to copy the whole message - any message that contains a field deprecated in FIX 4.4 (like ClientID) will not build properly if it exists in the 4.4 XML.



Now that we've added our fields and messages, let's generate the source code.

 Generating the Source Code

This is the easiest part - assuming that everything was edited correctly and you have installed the msxsl and Ruby tools. From the command line, go to the .\quickfix\spec directory and type:

generate

This fires off a batch file that will generate the source code. Various nested batch files will be invoked, each of which use the msxsl and Ruby tools to generate code and, in the case of the Java build, modify the batch files themselves. 

The XML transforms via msxsl are done relatively quickly. These build the initial versions of the Field, FieldNumbers and Values files.

The Ruby scripts generate the bulk of the code (message and field classes) and take quite a while to complete. The
scripts iterate through each of versions of FIX (4.1-4.4) and
each of the languages (C++, Java, .Net, Python and Ruby). You can watch the code being updated by watching the .\quickfix\src\[language]\...\fix4n directories.

If things go badly, it's sometimes difficult to figure out why. The scripts don't do a lot of logging, so you may be in for some headscratching. Things to look out for are deprecated fields (a big problem - avoid this at all costs), fields from a subsequent version of FIX used in a prior version (example: a FIX 4.3 field in a 4.2 message - this can be handled by adding the field to the 4.2 XML) and improper formatting of the XML.

Good luck!

Building QuickFix (Visual Studio 2005)

I'd love to tell you that now that the code has been generated, that building it is a snap. It almost is! The problem is that in at least one case (.Net), the code generator has generated new source code files that have to be added to the build project. The C++ version primarily creates header files - as they are #included via other header files, they don't need to be added to a project in order for it to build, but you may want to for completeness sake.

In the case of .Net, you will need to add the generated .cs files to the project. This is pretty simple - in Visual Studio 2005, there is a quickfix_net_messages_vs8 project that contains all the version-specific code in subprojects (fix41-fix44). If you right-click one of those subprojects and "Add-->Existing Item...", you should easily be able to add the new files needed. The simplest way is to simply select all the .cs files in the appropriate subdirectory (e.g., fix42) and add them. Preexisting files will be ignored and the new files will be added.

You can now build the solution and, if everything went well, you will have a new set of .lib and .dll files that can be used as replacements for the standard QuickFIX libraries.

I have not used the Java, Ruby or Python versions, so building those are left as an exercise for the reader.

Using Your Custom Version of QuickFIX

Using the customized version of QuickFIX is exactly the same as the standard version - you just have to add .lib or .dll files to the right places and use the custom-generated header files. All other aspects of QuickFIX programming are the same.


I hope this tutorial has been helpful for anyone looking to use custom messages with QuickFIX. I wish I had had it when I started! Please let me know if I've missed anything or got some detail wrong - I'll need to know myself!

- Brian Erst
Thynk Software, Inc.

Re: [Quickfix-developers] .NET stopping and starting initiator

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

Have you tried disposing the initiator?

--oren

On Oct 24, 2007, at 7:08 PM, Patrick Wright wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
>
>
> When a socket initiator is stopped the storage files are still in =20
> use so that starting it again causes an error (=91cannot open body =20
> file=92).
>
> I get the problem when using the .NET version of QuickFix 1.12.4 =20
> but I notice that there is at least one other thread asking about =20
> this problem.
>
> Here is the relevant code section copied from that previous thread:
>
>
>
> > settings =3D new SessionSettings(configFile);
>
> > storeFactory =3D new
> > FileStoreFactory(settings); logFactory =3D new FileLogFactory=20
> (settings);
> > messageFactory =3D new DefaultMessageFactory(); initiator =3D new
> > ThreadedSocketInitiator(this, storeFactory, settings, logFactory,
> > messageFactory);
> >
> >...
> > initiator.start();
> >...
> > initiator.stop();
> > initiator =3D null;
> > settings =3D null;
> > storeFactory =3D null;
> > logFactory =3D null;
> > messageFactory =3D null;
> > ----------------------------------------
>
> > At this point all of the four storage files are still locked =20
> (can't be
> > opened in notepad). Forcing garbage collection doesn't help.
>
>
>
> My question is:
>
> Has anyone managed to work around/fix this problem?
>
> I am using QuickFix from a .NET 2.0 WinForms app in C#.
>
>
>
> Thanks,
>
> Patrick Wright
>
>
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =20
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/=20
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Python library errors

[Chris B. <cb...@co...>]

Hi,

Were you able to run the run_executor_python script in the bin directory?

<http://www.quickfixengine.org/services.html>
>
> Hello,
>
> I would greatly appreciate assistance with python for Quickfix
> My major issue is that there are no working examples of a
> Python connection working. I tested my config file using Banzai, and
> things are working for that connection now. On my compiled version
> with Python 2.5 included, I get the following error:
> NotImplementedError: No matching function for overloaded
> 'new_SocketAcceptorBase' I have read through all of the documentation
> I can find, and all of the python examples have flaws errors and bugs.
> I fixed a few in order to make the code below, but I'm still having
> serious issues. Maybe this is simple, and I just need to vary the
> parameters I pass to SocketAcceptor.
>
> Building Python with quickfix took a very long time, I'm going to go
> through the process again and try to write up better examples so other
> people have a more "copy+paste" experience.
>
> Here is the error and code, from a terminal session.
> import quickfix
> def connecttest(file):
>         try:
>                 settings = quickfix.SessionSettings(file)
>                 application = Application()
>                 storeFactory = quickfix.FileStoreFactory(settings)
>                 logFactory = quickfix.FileLogFactory(settings)
>                 acceptor = quickfix.SocketAcceptor(application,
> storeFactory,
> settings, logFactory)
>                 acceptor.start()
>                 # while condition == true: do something
>                 acceptor.stop()
>         except quickfix.ConfigError, e:
>                 print e
>
> connecttest("/tmp/config.ini")
>
> Traceback (most recent call last):
>   File "<pyshell#41>", line 1, in <module>
>     connecttest("/tmp/config.ini")
>   File "<pyshell#40>", line 7, in connecttest
>     acceptor = quickfix.SocketAcceptor(application, storeFactory,
> settings, logFactory)
>   File "/usr/lib/python2.5/site-packages/quickfix.py", line 19982, in
> __init__
>     def __init__(self, application, storeFactory, settings, logFactory):
>   File "/usr/lib/python2.5/site-packages/quickfix.py", line 19940, in
> __init__
>     this = _quickfix.new_SocketAcceptorBase(*args) #orig
> NotImplementedError: No matching function for overloaded
> 'new_SocketAcceptorBase'
>
> --
> Ian Smith
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Initiator and Acceptor in a single app?

[Alexey Z. <ale...@gm...>]

There is one problem though - your initiator and acceptor will share the 
same sessions list (it's static).
So you have to be careful with your CompIDs.


Regards,
        Alexey.


Oren Miller wrote:
> Yes, this has been done many times.  You will have no problem creating 
> an acceptor and initiator object in the same application and sharing a 
> configuration file.
>
> --oren
>
> On Oct 30, 2007, at 8:55 AM, John Haldi wrote:
>
>> Is it possible to create a QuickFIX application which acts as both an 
>> initiator and an acceptor?
>

Re: [Quickfix-developers] Initiator and Acceptor in a single app?

[Ajay K. <Aja...@tr...>]

Yes, that's not a problem. The order router architecture you have
described is not unusal, and QuickFIX will handle it just fine.

=20

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
John Haldi
Sent: Tuesday, October 30, 2007 9:56 AM
To: qui...@li...
Subject: [Quickfix-developers] Initiator and Acceptor in a single app?

=20

Is it possible to create a QuickFIX application which acts as both an
initiator and an acceptor?

=20

<snip>

Re: [Quickfix-developers] Initiator and Acceptor in a single app?

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

Yes, this has been done many times.  You will have no problem  
creating an acceptor and initiator object in the same application and  
sharing a configuration file.

--oren

On Oct 30, 2007, at 8:55 AM, John Haldi wrote:

> Is it possible to create a QuickFIX application which acts as both  
> an initiator and an acceptor?

[Quickfix-developers] Initiator and Acceptor in a single app?

[John H. <jr...@ya...>]

Is it possible to 
create a QuickFIX application which acts as both an initiator and an 
acceptor?

 

Here's the business 
requirements for an application I'm looking to build:

 

Our trading office 
has 10 traders who each need to be able to create and send orders to a single 
broker.  I have successfully created an initiator application which connects to 
the broker and can send new orders (and handle cancel/replaces, etc) by polling 
a database which is populated with orders by a trading order entry client 
application which sits in front of each of the 10 traders.  The flow is 
basically as follows:

 

- A trader enters an 
order and the details are written to the database as a new 
order

- The QuickFIX 
initiator application periodically (5x per second) polls the db for 
new orders.  If it finds them it sends them.

- As ExecReports 
come back from the broker, the db is updated with order status 
information

- The trader sees 
updated order status by polling the db for order status 
changes

 

I need to improve 
the speed with which orders are entered into the system by traders and then 
taken by the initiator application and passed along to the broker.  
Is it 
possible to create a single QuickFIX application which can act as an initiator 
(to the broker) as well as an acceptor (to each of the trading clients)?  In 
other words, could I create my QuickFIX application such that it behaves like an 
order router?  Ideally it would accept FIX connections from each of the 10 
trading client applications (which act as initiators), and then orders created 
by the trading client would pass through to my QuickFIX "router", which would 
then send it along directly to the broker.  Or is this not a valid way of 
configuration a QuickFIX application (i.e. it has to be either an initiator or 
an acceptor, but it can't be both)?

 

I'm hoping that I 
can have an acceptor object as well as an initiator object in the same 
application and define them both in the config file.  My goal is to eliminate 
the latency introduced by the use of the db for communications.  If this is not 
a valid construct, am I correct in assuming that the best way to tackle this 
requirement is to create an initiator application which connects to the broker, 
and then create and use my own socket connections between my initiator 
application and the 10 trading clients?

 

Many thanks in 
advance for any advice,

 

   
John

--------------------------------------
jo...@ha...

Re: [Quickfix-developers] Processing messages in batches

[Djalma R. d. S. F. <drs...@gm...>]

Hi Jeff,

I believe that you need to provide your own persistence mechanism to
guarantee this kind of transaction you want.  There are several
solutions, you can use a flat file, a RDBMS, mqseries, activeMQ or
whatever.

ThreadedSocket classes are useful only if your application creates
more than one FIX connection. In quickfix you have only two choices: 1
thread to manage all sessions activities or 1-thread-per-connection.

Djalma

On 10/23/07, jgoodman999 <jef...@cm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I have an application right now that has a class that implements Application
> to process all the messages.  It processes one message at a time, stores in
> our database and sends events to the user's front end of the change.  The
> problem is that if I have hundreds of messages at once coming in, then I am
> sending notifications very quickly and its slowing the front end down.  I
> would like to read a message, insert, read a message, insert, etc until I
> receive 50 messages or so, then commit and send all events at once.  The
> problem is once I am done processing one message and return, it is gone so
> if the server crashes somewhere before 50, The messages that have not been
> committed will be gone and wont be resent on startup.  Any suggestions.
> Also, It seems that Quickfix must be single threaded since we must process
> the messages in the order they arrive, correct?  So what benefit does the
> multithreaded socket have?
> --
> View this message in context: http://www.nabble.com/Processing-messages-in-batches-tf4679528.html#a13370932
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Tried to send a reject while not logged on

[Djalma R. d. S. F. <drs...@gm...>]

Hi,

For the guys with more background, I would like to ask if there is
(was) a reason why QF doesn't send a logout (35=5)  to reject a logon
request with an invalid field?

Please, see logs bellow. It is clear that it can't send the reject
(35=3), but with current  implementation the acceptor can't know the
reason why it is being disconnected. Is there a chance to improve
this?

----------------------------------
Initiator
----------------------------------
20071029-17:05:29.830 : Created session
20071029-17:05:31.985 : Connecting to localhost on port 7012
20071029-17:05:32.017 : Connection succeeded
20071029-17:05:32.173 : Initiated logon request
20071029-17:05:32.532 : Message 1 Rejected: Tag not defined for this
message type:10008
20071029-17:05:32.548 : Tried to send a reject while not logged on
20071029-17:05:42.591 : Timed out waiting for logon response
20071029-17:05:42.591 : Disconnecting

----------------------------------
Acceptor
----------------------------------
20071029-17:05:25.722 : Created session
20071029-17:05:32.438 : Received logon request
20071029-17:05:32.501 : Responding to logon request
20071029-17:05:42.606 : Socket Error: Connection reset by peer.
20071029-17:05:42.606 : Disconnecting

TIA
Djalma

Re: [Quickfix-developers] sample code to read price log file and resend

[Djalma R. d. S. F. <drs...@gm...>]

Hi Jitesh,

See if code bellow helps you. It reads a standard quickfix log file,
parses each line (ignoring admin messages) and send them to a target
session.

Djalma
----------------------------------------------------
std::ifstream file;
file.open(g_config.inputFile.c_str(), std::ios_base::in);
if (!file.is_open())
{
	std::cout << "could not open file " <<  g_config.inputFile << std::endl;
	exit(-1);
}

// read line by line
//std::string line;
CStdString line;
int lineno = 1;
//g_messagesToSend.clear();
// get session information
FIX::SessionID sessionID(
g_config.beginString,
!g_config.newSenderCompID.empty()?g_config.newSenderCompID:g_config.senderCompID,
!g_config.newTargetCompID.empty()?g_config.newTargetCompID:g_config.targetCompID);

const FIX::Session * const pSession = FIX::Session::lookupSession( sessionID );
ASSERT(NULL != pSession);
if (NULL == pSession) throw std::runtime_error(_T("SESSION NOT FOUND!"));
const FIX::DataDictionary * const pDD = pSession->getDataDictionary();

while (getline(file, line, '\n') )
{
	// print the result
	if ( !FIX::Message::isAdminMsgType( FIX::identifyType( line ) ) )
	{
		
			std::cout << line << std::endl << std::endl;
			FIX::Message messageToSend(line, *pDD, true);
			Session::sendToTarget(messageToSend, sessionID);
	}
	++lineno;
}

if (file.is_open())
	file.close();

On 10/19/07, JiteshT <ji...@ed...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hello,
>
> Does anyone have some sample code I can use to read a price message log
> file, and send out the read messages on a socket?
>
> thanks,
>
> Jitesh
> --
> View this message in context: http://www.nabble.com/sample-code-to-read-price-log-file-and-resend-tf4655439.html#a13301931
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Design question: creating several SocketAcceptor/Initiator

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

Yoav, this is a reasonable thing to do. It just means that you will  
need a configuration file for each host.  If that is acceptable then  
you can set your system up this way no problem.

--oren

On Oct 26, 2007, at 5:08 PM, Yoav wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
> My company is developing a FOREX trading system and will most  
> likely use QuickFIX for the FIX implementation component.
> I'm new to QuickFIX and one of the first questions that just rose  
> was this:
> I can see that one SocketAcceptor/Initiator instance can handle  
> many connections to different hosts.
> The direction in my company though is to have one instance of  
> SocketAcceptor/Initiator per host.
> That means the same process that handles connections to many hosts  
> will have many instances of the class.
> Is that a reasonable decision? Is there a reason why we shouldn't  
> do that?
> I'm mostly interested in the performance aspect of this decision.
>
> Thanks in advance,
> Yoav
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>