quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] FIX 5.0 Support

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

Oren -

How about FAST FIX support? In the past, it's been mentioned that FAST FIX support was "in development", but nothing much further has been stated.

FAST FIX is VERY hot right now, with several exchanges including hometown CME moving to it for market data distribution.

Can you give any updates on when/if FAST FIX will be supported?

Thanks,

Brian Erst

----- Original Message ----
From: Oren Miller <or...@qu...>
To: jwa...@co...
Cc: qui...@li...
Sent: Thursday, January 3, 2008 2:34:13 PM
Subject: Re: [Quickfix-developers] FIX 5.0 Support


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

A release has not gone out in some time because what is out now is  
very stable and none of the changes in svn are truly critical.  For  
this same reason there have not been a ton of svn commits.  The  
product is mature and the goals are to remain simple and effective  
which means steering clear of feature creep.  FIX 5.0 support has not  
been forthcoming because demand has been low to non-existent.  If you  
really want 5.0 supports soon, then yes, you should look into  
purchasing a product which supports it.

--oren

On Jan 3, 2008, at 1:41 PM, Jay Walters wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> So looking at the time since last release (15 months), lack of  
> traffic on the list concerning this issue, low number of SVN  
> commits (67) during the past year and no reponse to my FIX 5.0  
> question; I should buy a FIX 5.0 compatible engine right?
>
> Or does one of the paid support companies help out in this situation?
>
> Cheers
>
>
 ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] FIX 5.0 Support

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

A release has not gone out in some time because what is out now is  
very stable and none of the changes in svn are truly critical.  For  
this same reason there have not been a ton of svn commits.  The  
product is mature and the goals are to remain simple and effective  
which means steering clear of feature creep.  FIX 5.0 support has not  
been forthcoming because demand has been low to non-existent.  If you  
really want 5.0 supports soon, then yes, you should look into  
purchasing a product which supports it.

--oren

On Jan 3, 2008, at 1:41 PM, Jay Walters wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> So looking at the time since last release (15 months), lack of  
> traffic on the list concerning this issue, low number of SVN  
> commits (67) during the past year and no reponse to my FIX 5.0  
> question; I should buy a FIX 5.0 compatible engine right?
>
> Or does one of the paid support companies help out in this situation?
>
> Cheers
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] FIX 5.0 Support

[Jay W. <jwa...@co...>]

So looking at the time since last release (15 months), lack of traffic on the list concerning this issue, low number of SVN commits (67) during the past year and no reponse to my FIX 5.0 question; I should buy a FIX 5.0 compatible engine right?  

Or does one of the paid support companies help out in this situation?

Cheers

[Quickfix-developers] How to know what is wrong with test

[<Nil...@co...>]

Hi

=0D

I am new to QuickFix. Just downloaded and installed the QuickFix 1.12.4
and truing out the C++ test provided.=0D

=0D

I have build the QuickFix.lib first and than test_unit, test_acceptance
and test_acceptance_runner projects.

=0D

When I run the command "runut debug [port]" - I get the following
output, which suggest 6 test cases have been failed. I would like to
know why they have failed and how to fix it.

=0D

D:\myProjects\ExSim\QuickFix\source-v0\test>runut debug [port]

=0D

D:\myProjects\ExSim\QuickFix\source-v0\test>echo off

<ut>

  <output>

........................................................................
........

................................FFFF....................................
.......F

F.....

  </output>

  <results total=3D"166" failures=3D"6">

    <failure  line=3D "0" file=3D "unknown">

      <test>

        <![CDATA[ class CPPTest::Test<class FIX::MessageStore> *]]>

      </test>

      <text>

        <![CDATA[ assert(no futher information available)]]>

      </text>

    </failure>

    <failure  line=3D "0" file=3D "unknown">

      <test>

        <![CDATA[ class CPPTest::Test<class FIX::MessageStore> *]]>

      </test>

      <text>

        <![CDATA[ assert(no futher information available)]]>

      </text>

    </failure>

    <failure  line=3D "0" file=3D "unknown">

      <test>

        <![CDATA[ class CPPTest::Test<class FIX::MessageStore> *]]>

      </test>

      <text>

        <![CDATA[ assert(no futher information available)]]>

      </text>

    </failure>

    <failure  line=3D "0" file=3D "unknown">

      <test>

        <![CDATA[ class CPPTest::Test<class FIX::MessageStore> *]]>

      </test>

      <text>

        <![CDATA[ assert(no futher information available)]]>

      </text>

    </failure>

    <failure  line=3D "49" file=3D ".\C++\test\SocketServerTestCase.cpp">

      <test>

        <![CDATA[ class FIX::SocketServerTestCase::accept]]>

      </test>

      <text>

        <![CDATA[ assert(clientS1 > 0)]]>

      </text>

    </failure>

    <failure  line=3D "98" file=3D ".\C++\test\SocketServerTestCase.cpp">

      <test>

        <![CDATA[ class FIX::SocketServerTestCase::block]]>

      </test>

      <text>

        <![CDATA[ assert(clientS >=3D 0)]]>

      </text>

    </failure>

  </results>

</ut>

=0D

D:\myProjects\ExSim\QuickFix\source-v0\test>

=0D

Also would like to know what the use of the following project. Please
assume that I am only interested in C++ project, the goal is to learn
how to use the quickfix implementation in my project.

=0D

Example_executor_cpp

Example_order_match

Example_tradeclient

Test_acceptance_runner

Test_acceptance (Looks like a test program for acceptance testing, if so
how is it different from the test_unit)

Test_unit (Probably test program for unit testing - what are the test
cases it is executing)

Test_performance

=0D

Thanks & Regards
-Nilesh

=0D



This e-mail and any files transmitted with it are for the sole use of the=
 intended recipient(s) and may contain confidential and privileged=
 information.
If you are not the intended recipient, please contact the sender by reply=
 e-mail and destroy all copies of the original message.=0D
Any unauthorised review, use, disclosure, dissemination, forwarding,=
 printing or copying of this email or any action taken in reliance on this=
 e-mail is strictly=0D
prohibited and may be unlawful.

Re: [Quickfix-developers] QuickFix performance?

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

One thing to note for the C# API, make sure you are disposing all  
your messages.  The ones you send as well as the ones you receive.   
This will make a BIG difference in high throughput systems.

--oren

On Dec 19, 2007, at 10:05 PM, Djalma Rosa dos Santos Filho wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> I don't know if this is the same, but we are also suffering with
> low-throughput message receiving when using quickfix in a C# GUI
> application in the moment when there is a remote connection sending
> thousands of messages. Because of this, we're planning to modify the
> application's architecture by adding some stuff like MVC, queues and
> threading pools to try to maximize the throughput. The current
> application design is inefficient and I believe in some reasons for
> that, things related to the way how Quickfix is working and some TCP
> socket issues...
> But, in order to know if maybe this is the same with you, let me ask
> you some questions for clarification.
> When you say that you could isolate quickfix performance, what exactly
> do you mean? Nothing in fromApp() ?
> Are you processing all messages in the context of the quickfix thread?
> How heavy is this message processing?
> Are you using the message cracker?
>
> Djalma
>
>
> On Dec 19, 2007 12:59 PM, Rick Lane <ric...@gm...> wrote:
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Greetings,
>>
>> Is there any documentation regarding the performance (e.g. message
>> throughput capabilities) of QuickFix?  I'm running into issues  
>> where it
>> seems that I'm receiving messages too slowly (I emailed the list a
>> couple days ago regarding fill notifications -- namely, if I place an
>> immediate-fill order for, say, 1000 contracts, it takes nearly 2.5
>> seconds to receive all of the fill notifications).  This may have
>> something to do with the CME (perhaps on the environment on which I'm
>> testing they throttle fill notifications) but I don't believe this is
>> the case.  I've pretty much eliminated any other threading/etc.  
>> that my
>> application is doing to try to isolate the performance solely to
>> QuickFix and I'm still seeing the same results.
>>
>> Has anyone run into this before, and is there some advice as to why
>> these notifications might be taking so long to be processed?
>>
>> Thanks,
>> RL
>>
>> --------------------------------------------------------------------- 
>> ----
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
>> marketplace
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
> marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] QuickFix performance?

[Rick L. <ric...@gm...>]

Djalma,

Good question. By "isolating" QuickFix, I mean I simply have a main 
thread (the QuickFix thread) that handles all of the messages.  My first 
thought was that maybe "cracking" the messages was causing overhead, so 
I removed that -- so I basically only have a method that submits the New 
Order Single request, and of course my fromApp() that does nothing other 
than increments a message counter looks to see if the message is an 
OrdStatus.FILLED and it then displays the total time taken, as well as 
the total number of messages.

In my "full" program, I have several threads that handle notifying order 
"listeners" (if I have one program that submits order A and another 
program that submits order B, and order A gets filled, I have a thread 
that properly routes ExecutionReports to the intended recipient), I also 
have market-data threads (that is outside the scope of QuickFix), etc., 
etc., and by isolate, I only meant I had a single QuickFix thread 
processing the messages.

Before I dive any deeper into this issue, I'm going to test on a new 
network because I have a suspicion the network I'm on has some serious 
limitations (for other market-data related projects, we would get a ton 
of missed/dropped packets, etc.).

Thanks for the response -- I'll let the group know what I find.

Rick

Djalma Rosa dos Santos Filho wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> I don't know if this is the same, but we are also suffering with
> low-throughput message receiving when using quickfix in a C# GUI
> application in the moment when there is a remote connection sending
> thousands of messages. Because of this, we're planning to modify the
> application's architecture by adding some stuff like MVC, queues and
> threading pools to try to maximize the throughput. The current
> application design is inefficient and I believe in some reasons for
> that, things related to the way how Quickfix is working and some TCP
> socket issues...
> But, in order to know if maybe this is the same with you, let me ask
> you some questions for clarification.
> When you say that you could isolate quickfix performance, what exactly
> do you mean? Nothing in fromApp() ?
> Are you processing all messages in the context of the quickfix thread?
> How heavy is this message processing?
> Are you using the message cracker?
>
> Djalma
>
>
> On Dec 19, 2007 12:59 PM, Rick Lane <ric...@gm...> wrote:
>   
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Greetings,
>>
>> Is there any documentation regarding the performance (e.g. message
>> throughput capabilities) of QuickFix?  I'm running into issues where it
>> seems that I'm receiving messages too slowly (I emailed the list a
>> couple days ago regarding fill notifications -- namely, if I place an
>> immediate-fill order for, say, 1000 contracts, it takes nearly 2.5
>> seconds to receive all of the fill notifications).  This may have
>> something to do with the CME (perhaps on the environment on which I'm
>> testing they throttle fill notifications) but I don't believe this is
>> the case.  I've pretty much eliminated any other threading/etc. that my
>> application is doing to try to isolate the performance solely to
>> QuickFix and I'm still seeing the same results.
>>
>> Has anyone run into this before, and is there some advice as to why
>> these notifications might be taking so long to be processed?
>>
>> Thanks,
>> RL
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>     
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>   

Re: [Quickfix-developers] QuickFix performance?

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

Hi Rick,

I don't know if this is the same, but we are also suffering with
low-throughput message receiving when using quickfix in a C# GUI
application in the moment when there is a remote connection sending
thousands of messages. Because of this, we're planning to modify the
application's architecture by adding some stuff like MVC, queues and
threading pools to try to maximize the throughput. The current
application design is inefficient and I believe in some reasons for
that, things related to the way how Quickfix is working and some TCP
socket issues...
But, in order to know if maybe this is the same with you, let me ask
you some questions for clarification.
When you say that you could isolate quickfix performance, what exactly
do you mean? Nothing in fromApp() ?
Are you processing all messages in the context of the quickfix thread?
How heavy is this message processing?
Are you using the message cracker?

Djalma


On Dec 19, 2007 12:59 PM, Rick Lane <ric...@gm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Greetings,
>
> Is there any documentation regarding the performance (e.g. message
> throughput capabilities) of QuickFix?  I'm running into issues where it
> seems that I'm receiving messages too slowly (I emailed the list a
> couple days ago regarding fill notifications -- namely, if I place an
> immediate-fill order for, say, 1000 contracts, it takes nearly 2.5
> seconds to receive all of the fill notifications).  This may have
> something to do with the CME (perhaps on the environment on which I'm
> testing they throttle fill notifications) but I don't believe this is
> the case.  I've pretty much eliminated any other threading/etc. that my
> application is doing to try to isolate the performance solely to
> QuickFix and I'm still seeing the same results.
>
> Has anyone run into this before, and is there some advice as to why
> these notifications might be taking so long to be processed?
>
> Thanks,
> RL
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] QuickFix performance?

[Rick L. <ric...@gm...>]

Greetings,

Is there any documentation regarding the performance (e.g. message 
throughput capabilities) of QuickFix?  I'm running into issues where it 
seems that I'm receiving messages too slowly (I emailed the list a 
couple days ago regarding fill notifications -- namely, if I place an 
immediate-fill order for, say, 1000 contracts, it takes nearly 2.5 
seconds to receive all of the fill notifications).  This may have 
something to do with the CME (perhaps on the environment on which I'm 
testing they throttle fill notifications) but I don't believe this is 
the case.  I've pretty much eliminated any other threading/etc. that my 
application is doing to try to isolate the performance solely to 
QuickFix and I'm still seeing the same results.

Has anyone run into this before, and is there some advice as to why 
these notifications might be taking so long to be processed?

Thanks,
RL

Re: [Quickfix-developers] Message Recovery for previous days.

[Bharath K. N <bha...@gm...>]

Thank you. Acceptor side is not under our control.The acceptor side has a
application which will replay messages for the previous session in case the
messages are not available.




Djalma Rosa dos Santos Filho wrote:
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Hi Bharath,
> 
> IMHO, this is a request that should be handled in the application
> layer and not in the session layer, maybe with a user defined message
> you must create and not using the fix resend request.
> 
> When session is reset, quickfix simply empties the store to start
> another brand new session, this means that all your messages from the
> previous session are simply deleted at 17:30 CST. I believe that this
> is the correct behaviour, because message resending using Resend
> Request must work only for the current session.
> 
> But in order to be able to respond to this kind of recovery request,
> your acceptor side must have the ability to backup all messages from
> previous day. If the acceptor side is under your control and is also
> using quickfix, I suggest that you modify the reset() method of the
> quickfix store you are using there to make a copy of the messages
> somewhere else before the regular implementation removes all of them.
> With this backup the application will be able to replay all messages,
> maybe with a PossResend indication.
> 
> Djalma
> 
> 
> On Dec 12, 2007 9:22 PM, Bharath Kumar N <bha...@gm...> wrote:
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>> Hi All,
>>       We are implementing the Initiator side using Quickfix\J version
>> 1.3.0.The FIX version is FIX.4.2.
>> We are getting the daily fix trades/messages from the acceptor side.The
>> acceptor side resets the session every day at 17:30 CST.
>>
>> Here are a few the setting from my cfg properties file.
>>
>> [session]
>> BeginString=FIX.4.2
>> ConnectionType=initiator
>> SenderCompID=XXXX
>> TargetCompID=YYYY
>> StartTime=00:00:00
>> EndTime=23:59:59
>> #Reset the sequence number
>> ResetOnDisconnect=Y
>>
>> The fix cleint application (initiator) at our end saves the messages into
>> a
>> table in the database as soon as a message is available.
>>
>> I have a few questions on how to implement the following logic:
>>
>> 1) The acceptor sends in the messages.Lets say that the application at
>> our
>> end which listens and saves the messages into the DB breaks down, but the
>> the acceptor keeps on sending the message.
>> To recover these messages we restart the fix client and at at logon ,we
>> send
>> a RESEND request from startseqNum 1 to endSeqNum 0 and get in all the
>> messages for the day.Check for duplicates using the unique key ExecID and
>> save into the database the missing messages.
>>
>> Since the session is reset everyday at 17:30 CST on the acceptor
>> side.What
>> if we want to process the trades for the day after the session is reset
>> at
>> the acceptor end ? How do we get the missing trades for the day after
>> 17:30
>> CST ?
>>
>> Appreciate all the help.
>>
>> Thanks
>> Bharath
>> --
>> View this message in context:
>> http://www.nabble.com/Message-Recovery-for-previous-days.-tp14305075p14305075.html
>> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>>
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 

-- 
View this message in context: http://www.nabble.com/Message-Recovery-for-previous-days.-tp14305075p14399839.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] Message Recovery for previous days.

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

Hi Bharath,

IMHO, this is a request that should be handled in the application
layer and not in the session layer, maybe with a user defined message
you must create and not using the fix resend request.

When session is reset, quickfix simply empties the store to start
another brand new session, this means that all your messages from the
previous session are simply deleted at 17:30 CST. I believe that this
is the correct behaviour, because message resending using Resend
Request must work only for the current session.

But in order to be able to respond to this kind of recovery request,
your acceptor side must have the ability to backup all messages from
previous day. If the acceptor side is under your control and is also
using quickfix, I suggest that you modify the reset() method of the
quickfix store you are using there to make a copy of the messages
somewhere else before the regular implementation removes all of them.
With this backup the application will be able to replay all messages,
maybe with a PossResend indication.

Djalma


On Dec 12, 2007 9:22 PM, Bharath Kumar N <bha...@gm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hi All,
>       We are implementing the Initiator side using Quickfix\J version
> 1.3.0.The FIX version is FIX.4.2.
> We are getting the daily fix trades/messages from the acceptor side.The
> acceptor side resets the session every day at 17:30 CST.
>
> Here are a few the setting from my cfg properties file.
>
> [session]
> BeginString=FIX.4.2
> ConnectionType=initiator
> SenderCompID=XXXX
> TargetCompID=YYYY
> StartTime=00:00:00
> EndTime=23:59:59
> #Reset the sequence number
> ResetOnDisconnect=Y
>
> The fix cleint application (initiator) at our end saves the messages into a
> table in the database as soon as a message is available.
>
> I have a few questions on how to implement the following logic:
>
> 1) The acceptor sends in the messages.Lets say that the application at our
> end which listens and saves the messages into the DB breaks down, but the
> the acceptor keeps on sending the message.
> To recover these messages we restart the fix client and at at logon ,we send
> a RESEND request from startseqNum 1 to endSeqNum 0 and get in all the
> messages for the day.Check for duplicates using the unique key ExecID and
> save into the database the missing messages.
>
> Since the session is reset everyday at 17:30 CST on the acceptor side.What
> if we want to process the trades for the day after the session is reset at
> the acceptor end ? How do we get the missing trades for the day after 17:30
> CST ?
>
> Appreciate all the help.
>
> Thanks
> Bharath
> --
> View this message in context: http://www.nabble.com/Message-Recovery-for-previous-days.-tp14305075p14305075.html
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Suchit REIKHY is out of the office.

[<suc...@am...>]

I will be out of the office starting  12/17/2007 and will not return until
01/02/2008.

I will respond to your message when I return.


This message and any attachments (the "message") is intended solely for 
the addressees and is confidential. If you receive this message in error, 
please delete it and immediately notify the sender. Any use not in accord 
with its purpose, any dissemination or disclosure, either whole or partial, 
is prohibited except formal approval. The internet can not guarantee the 
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) 
not therefore be liable for the message if modified. Please note that certain 
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

[Quickfix-developers] increasing message volume = performance issues?

[Rick L. <ric...@gm...>]

Greetings,

I'm doing some performance testing on my QuickFix application (which 
connects to the CME exchange), and I've noticed some peculiar behavior 
-- I wanted to throw it out there and see if anyone else has seen this, 
or if anyone has any suggestions as to the possible cause.

If I submit an immediate-fill order (if I sell the bid or buy the 
offer), depending on the size of the order (which loosely determines how 
many partial fill messages I will receive), my message rates vary 
hugely.  In fact, as the order size increases, the message rates 
decrease exponentially -- so if I hit the bid with a 100-lot order, I 
get roughly 2.5 partial-fill messages/ per millisecond/, if I increase 
that to 300, however, this number is cut in half.  At 1000, I get only 
0.3 partial-fill messages per ms. 

There very well may be something with how the CME disseminates its fill 
messages that is causing this (I'm not sure if they throttle messages 
depending on volume, etc.), and I've already inquired with them if this 
is the case and am currently awaiting their response.  In the meantime, 
however, I figured I'd ask the list if anyone else had seen anything 
like this.  I thought it might be a threading issue of my own, but to 
ensure it wasn't, I removed all of my threaded portions of my (with the 
exception of the c# gui thread) and it still occurs.

Any advice is greatly appreciated.

RL

Re: [Quickfix-developers] Message Recovery for previous days.

[Bharath K. N <bha...@gm...>]

Guys,
       Any  info on this will be very helpful.

THanks
Bharath



Bharath Kumar N wrote:
> 
> Hi All,
>       We are implementing the Initiator side using Quickfix\J version
> 1.3.0.The FIX version is FIX.4.2.
> We are getting the daily fix trades/messages from the acceptor side.The
> acceptor side resets the session every day at 17:30 CST.
> 
> Here are a few the setting from my cfg properties file.
> 
> [session]
> BeginString=FIX.4.2
> ConnectionType=initiator
> SenderCompID=XXXX
> TargetCompID=YYYY
> StartTime=00:00:00
> EndTime=23:59:59
> #Reset the sequence number
> ResetOnDisconnect=Y
> 
> The fix cleint application (initiator) at our end saves the messages into
> a table in the database as soon as a message is available.
> 
> I have a few questions on how to implement the following logic:
> 
> 1) The acceptor sends in the messages.Lets say that the application at our
> end which listens and saves the messages into the DB breaks down, but the
> the acceptor keeps on sending the message.
> To recover these messages we restart the fix client and at at logon ,we
> send a RESEND request from startseqNum 1 to endSeqNum 0 and get in all the
> messages for the day.Check for duplicates using the unique key ExecID and
> save into the database the missing messages.
> 
> Since the session is reset everyday at 17:30 CST on the acceptor side.What
> if we want to process the trades for the day after the session is reset at
> the acceptor end ? How do we get the missing trades for the day after
> 17:30 CST ?
> 
> Appreciate all the help.
> 
> Thanks
> Bharath
> 

-- 
View this message in context: http://www.nabble.com/Message-Recovery-for-previous-days.-tp14305075p14325481.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Reseting sequence numbers

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

This is probably a dumb question, but I'm wondering if there is a specific call that would allow you to reset sender and target sequence numbers for the next logon.

The idea here is that sometimes, the initiator and the acceptor are so out of sync (number of messages to be resent number in the hundreds or thousands) or is otherwise so messed up that it's better to start from scratch and ignore the built up history. (Some exchanges like SFE will error out if you request a gap-resend of greater than a few hundred and you can't really sync back up.) 

Expecting an operator to handle these exceptional cases by bringing down the application, clearing the data directories and bringing everything back up is asking a lot. In my homegrown FIX engine, I have a method that allows me to set a "reset on next login ONLY" and "recycle the connection" and I tie that to a drop-down menu. If we're in one of those exceptional cases, one quick click with a confirm and the app simply reconnects - resetting the sequence numbers in the process.

The only way I can think to do this in QuickFIX is to temporarily set the ResetOnLogon flag for the session to "true", recycle the connection and then set the flag back to "false" during the onLogon callback. For a brief period, I thought that perhaps the reset() method would work, but although it resets the sequence numbers and disconnects, it does not end up setting the ResetSeqNumFlag on the next Logon message (because none of the m_resetOnXXX members are set).

As I said, I can work around this, but was wondering if there was a more straightforward way to do so.

- Brian Erst

[Quickfix-developers] Message Recovery for previous days.

[Bharath K. N <bha...@gm...>]

Hi All,
      We are implementing the Initiator side using Quickfix\J version
1.3.0.The FIX version is FIX.4.2.
We are getting the daily fix trades/messages from the acceptor side.The
acceptor side resets the session every day at 17:30 CST.

Here are a few the setting from my cfg properties file.

[session]
BeginString=FIX.4.2
ConnectionType=initiator
SenderCompID=XXXX
TargetCompID=YYYY
StartTime=00:00:00
EndTime=23:59:59
#Reset the sequence number
ResetOnDisconnect=Y

The fix cleint application (initiator) at our end saves the messages into a
table in the database as soon as a message is available.

I have a few questions on how to implement the following logic:

1) The acceptor sends in the messages.Lets say that the application at our
end which listens and saves the messages into the DB breaks down, but the
the acceptor keeps on sending the message.
To recover these messages we restart the fix client and at at logon ,we send
a RESEND request from startseqNum 1 to endSeqNum 0 and get in all the
messages for the day.Check for duplicates using the unique key ExecID and
save into the database the missing messages.

Since the session is reset everyday at 17:30 CST on the acceptor side.What
if we want to process the trades for the day after the session is reset at
the acceptor end ? How do we get the missing trades for the day after 17:30
CST ?

Appreciate all the help.

Thanks
Bharath
-- 
View this message in context: http://www.nabble.com/Message-Recovery-for-previous-days.-tp14305075p14305075.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Upgrading from NON FIX based solution | consulting required

[Hanan H. <han...@gm...>]

Hi All,

 

I am looking for a consulting for upgrading an existing in house automated
system to a FIX based solution.

The job targets are:

1. Definition of the FIX based required solution.

2. Comparing existing products VS developing using QF engine 

 

Just a few words regarding the existing| required solutions details.

 

The Existing system description:

I have multiple clients (about 10-15 ) connected to Desktop application
trading system. 

            All of the orders sending and status is done via a proprietary
API (COM based).

            each automated system sends a few orders a second.

 

A new FIX based solution description

1. Each Client is a FIX acceptor application

            Use NewOrderSingle()  + SendToTarget("Your FIX server").  to
send a new order 

Each client would have its own config file, and each client would have a
SenderCompID which you specify.  When the client calls the SendToTarget it
would be sending it to your FIX acceptor app, which has been configured to
accept connections from each of your clients.

 

2. The FIX server would not only be an acceptor, but it could conceivably
also be configured to have its own instance of an initiator.

That acceptor app could then connect as an initiator to a broker FIX server
and act as a gateway to the broker for all of my clients.

 

 

Best regards,

Hanan Harush

[Quickfix-developers] Problems with Socket Iniator

[Mark H. <mar...@ho...>]

My program is able to pass the settings from the config file to the socket =
initiator and connect to my gateway although I am getting a config error th=
at I have yet to debug.  This is not my main concern, although it may be re=
lated to my larger problem.I am getting a ConfigError after line 264 of soc=
ketinitiator.cpp when SocketInitiator::getHost() calls .getString.  I can't=
 seem to find anything wrong with my config file.This might be a rare insta=
nce, but this issue is really troublesome because I am writing a virtual us=
er for LoadRunner in which three DLLs are created by three functions, each =
basically acting as its own program.  These DLLs are Initialize, Actions, a=
nd Terminate.  So in debug mode, after Initialize executes, the program nev=
er moved onto Actions, the client is disconnected, and the debugger gets st=
uck while showing:First-chance exception at 0x100d9a0a (AdaptTrader.dll) in=
 mdrv.exe: 0xC0000005: Access violation reading location 0x00000000.Then:Un=
handled exception at 0x100d9a0a (AdaptTrader.dll) in mdrv.exe: 0xC0000005: =
Access violation reading location 0x00000000.When the program is run as a v=
user, it disconnects and eventually crashes with:R6025 Pure Virtual Functio=
n CallOptimally I need the connection to stay active from Initialize() to A=
ctions() both of which are int functions that currently return 0.I do have =
a program that uses quickfix to create virtual loadrunner users written in =
vb and it does not have this issue.Please let me know what code, files, and=
 information you need to help me overcome this issue.Thanks,Mark
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE=
!
http://www.windowslive.com/share.html?ocid=3DTXT_TAGLM_Wave2_sharelife_1120=
07=

[Quickfix-developers] FIX 5.0 Support

[Jay W. <jwa...@co...>]

Any news on FIX 5.0 support?  Some time ago I see it was a high priority item, but I don't see any traffic on the list regarding the progress.

Re: [Quickfix-developers] How to handle Sessions with SubIds

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

Ahh sorry, you are correct, it is SessionSettings not DataDictionary  
you need.  Like you said you can get it from Initiator/Acceptor, but  
also you passed it in to begin with so you should already have it  
from then.  Once you have the SessionSettings, you can pass in a  
sessionID to get the sessions settings dictionary.  From there you  
can use getString() to get the value.  So your code should look  
something like this.

const Dictionary& dictionary = sessionSettings.get( sessionID );
if( dictionary.has("SenderCompID" ) )
{
   std::cerr << "Has TargetSubID = ' << dictionary.getString 
("SenderCompID");
}

On Dec 7, 2007, at 4:03 PM, Mike Perik wrote:

> Sorry, but I don't see how I can use the Session to
> get to the Session's config parameters.
>
> The Session->getDataDictionary() just seems to return
> a dictionary of all available fields this particular
> session.  There is no
> DataDictionary::getFieldValue(...) method.
>
> What am I missing?
>
> It looks like I can only get the SessionSettings by
> using the Acceptor/Initiator objects.  I guess I could
> pass the Acceptor/Initiator object to the application
> so I can reference it.
>
> It just seems like I should be able to get a Session's
> SessionSettings from it.
>
>
> Here's what I've got so far:
>
>
> void Application::toAdmin( FIX::Message& message,
>                            const FIX::SessionID&
> sessionID )
> {
>     std::cerr << "Application::toAdmin(): " <<
> message.toString() << std::endl;
>     FIX::Session *session =
> FIX::Session::lookupSession(sessionID);
>     if (session != NULL)
>     {
>         std::cerr << "Found Session" << std::endl;
>     }
>     const FIX::DataDictionary& dd =
> session->getDataDictionary();
>     int tag = -1;
>     if (dd.getFieldTag("TargetSubID", tag) &&
> dd.hasFieldValue(dd.getFieldTag("TargetSubID", tag)))
>     {
> // Never makes it to here
>         std::cerr << "Has TargetSubID = " << tag <<
> std::endl;
>     }
>     if (dd.getFieldTag("SenderSubID", tag) &&
> dd.hasFieldValue(dd.getFieldTag("SenderSubID", tag)))
>     {
> // Never makes it to here
>         std::cerr << "Has SenderSubID = " << tag <<
> std::endl;
>     }
> }
>
> --- Oren Miller <or...@qu...> wrote:
>
>> You need access to the DataDictionary object.  You
>> can get this from
>> the Session object with getDataDictionary().  This
>> will allow you to
>> look up the settings for that session.  Then yes,
>> you will need to
>> add the subids to the message with
>> message.getHeader().setField().
>>
>> --oren
>>
>> On Dec 6, 2007, at 5:21 PM, Mike Perik wrote:
>>
>>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/
>>> html/index.html
>>> QuickFIX Support:
>> http://www.quickfixengine.org/services.html
>>>
>>> Just to clarify, I would still need to manually
>> set
>>> those fields in the to...()/from...() methods if
>> the
>>> Session have them configured.
>>>
>>> I've looked at the interfaces for the Session
>> object
>>> and I can't figure out how to get a handle to the
>>> SessionSettings object in the to...()/from...()
>>> methods.
>>>
>>> In C++ I would think you would do something like
>>>
>>> Session *s = Session::getSession(sessionID);
>>> -- I know there is no method on the Session object
>>> called getSessionSettings() but I thought the
>> Session
>>> would know it's own settings.
>>> SessionSettings *ss = s->getSessionSettings();
>>>
>>>
>>> How do you get the SessionSettings object for a
>>> session?
>>>
>>>
>>>
>>>
>>> Mike
>>>
>>> --- Oren Miller <or...@qu...> wrote:
>>>
>>>> Mike,
>>>>
>>>> My suggestion if you want to do something like
>> this
>>>> would be to add a
>>>> SenderSubID and TargetSubID field to the
>>>> configuration file, and you
>>>> can then look these up based on the session.
>> This
>>>> is probably
>>>> something we will be adding support for in the
>>>> future.
>>>>
>>>> --oren
>>>>
>>>> On Dec 6, 2007, at 12:03 PM, Mike Perik wrote:
>>>>
>>>>> QuickFIX Documentation:
>>>> http://www.quickfixengine.org/quickfix/doc/
>>>>> html/index.html
>>>>> QuickFIX Support:
>>>> http://www.quickfixengine.org/services.html
>>>>>
>>>>> Thought I was already subscribed to the
>> developer
>>>>> mailing list and was wondering where my previous
>>>> email
>>>>> had gone, so I'll try again.
>>>>>
>>>>> I'm investigating QuickFix for use as a gateway.
>>>> I
>>>>> need to be able to have sessions that use SubIds
>>>>> (TargetSubID/SenderSubID).
>>>>>
>>>>> What is the best way to set the subid(s)?
>>>>>
>>>>> I've been hacking at the code to make the
>> subid(s)
>>>> an
>>>>> optional part of the SessionID and have made
>> some
>>>>> progress but I'm only going to where the issues
>>>> pop up
>>>>> (ie code doesn't build, sessions can't be
>> found).
>>>>> Does anyone see a problem with making the
>> subid(s)
>>>> an
>>>>> optional part of the SessionID?
>>>>>
>>>>> The other thought I had is to require a
>>>>> SessionQualifier on all sessions and use the
>>>> qualifier
>>>>> to look up any additional tags (ie.
>>>>> TargetSubId/SenderSubId) that need to be
>> populated
>>>>> before the message is sent.
>>>>>
>>>>> Anyone else have any ideas/solutions on how to
>> do
>>>>> this?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> ______________________________________________________________________
>>>>
>>>>> ______________
>>>>> Never miss a thing.  Make Yahoo your home page.
>>>>> http://www.yahoo.com/r/hs
>>>>>
>>>>>
>>>>
>>>
>>
> ----------------------------------------------------------------------
>>>>
>>>>> ---
>>>>> SF.Net email is sponsored by: The Future of
>> Linux
>>>> Business White Paper
>>>>> from Novell.  From the desktop to the data
>> center,
>>>> Linux is going
>>>>> mainstream.  Let it simplify your IT future.
>>>>>
>>>>
>>>
>>
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>>>> _______________________________________________
>>>>> Quickfix-developers mailing list
>>>>> Qui...@li...
>>>>>
>>>>
>>>
>>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
> ______________________________________________________________________
>>
>>> ______________
>>> Be a better friend, newshound, and
>>> know-it-all with Yahoo! Mobile.  Try it now.
>> http://
>>>
>> mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>>>
>>>
>>>
>>
> ----------------------------------------------------------------------
>>
>>> ---
>>> SF.Net email is sponsored by:
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>>
>>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>
>>
>
>
>
>        
> ______________________________________________________________________ 
> ______________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/ 
> newsearch/category.php?category=shopping
>

Re: [Quickfix-developers] How to handle Sessions with SubIds

[Mike P. <mic...@ya...>]

Sorry, but I don't see how I can use the Session to
get to the Session's config parameters. 

The Session->getDataDictionary() just seems to return
a dictionary of all available fields this particular
session.  There is no
DataDictionary::getFieldValue(...) method.

What am I missing?

It looks like I can only get the SessionSettings by
using the Acceptor/Initiator objects.  I guess I could
pass the Acceptor/Initiator object to the application
so I can reference it.

It just seems like I should be able to get a Session's
SessionSettings from it.


Here's what I've got so far:


void Application::toAdmin( FIX::Message& message,
                           const FIX::SessionID&
sessionID )
{
    std::cerr << "Application::toAdmin(): " <<
message.toString() << std::endl;
    FIX::Session *session =
FIX::Session::lookupSession(sessionID);
    if (session != NULL)
    {
        std::cerr << "Found Session" << std::endl;
    }
    const FIX::DataDictionary& dd =
session->getDataDictionary();
    int tag = -1;
    if (dd.getFieldTag("TargetSubID", tag) &&
dd.hasFieldValue(dd.getFieldTag("TargetSubID", tag)))
    {
// Never makes it to here
        std::cerr << "Has TargetSubID = " << tag <<
std::endl;
    }
    if (dd.getFieldTag("SenderSubID", tag) &&
dd.hasFieldValue(dd.getFieldTag("SenderSubID", tag)))
    {
// Never makes it to here
        std::cerr << "Has SenderSubID = " << tag <<
std::endl;
    }
}

--- Oren Miller <or...@qu...> wrote:

> You need access to the DataDictionary object.  You
> can get this from  
> the Session object with getDataDictionary().  This
> will allow you to  
> look up the settings for that session.  Then yes,
> you will need to  
> add the subids to the message with
> message.getHeader().setField().
> 
> --oren
> 
> On Dec 6, 2007, at 5:21 PM, Mike Perik wrote:
> 
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/ 
> > html/index.html
> > QuickFIX Support:
> http://www.quickfixengine.org/services.html
> >
> > Just to clarify, I would still need to manually
> set
> > those fields in the to...()/from...() methods if
> the
> > Session have them configured.
> >
> > I've looked at the interfaces for the Session
> object
> > and I can't figure out how to get a handle to the
> > SessionSettings object in the to...()/from...()
> > methods.
> >
> > In C++ I would think you would do something like
> >
> > Session *s = Session::getSession(sessionID);
> > -- I know there is no method on the Session object
> > called getSessionSettings() but I thought the
> Session
> > would know it's own settings.
> > SessionSettings *ss = s->getSessionSettings();
> >
> >
> > How do you get the SessionSettings object for a
> > session?
> >
> >
> >
> >
> > Mike
> >
> > --- Oren Miller <or...@qu...> wrote:
> >
> >> Mike,
> >>
> >> My suggestion if you want to do something like
> this
> >> would be to add a
> >> SenderSubID and TargetSubID field to the
> >> configuration file, and you
> >> can then look these up based on the session. 
> This
> >> is probably
> >> something we will be adding support for in the
> >> future.
> >>
> >> --oren
> >>
> >> On Dec 6, 2007, at 12:03 PM, Mike Perik wrote:
> >>
> >>> QuickFIX Documentation:
> >> http://www.quickfixengine.org/quickfix/doc/
> >>> html/index.html
> >>> QuickFIX Support:
> >> http://www.quickfixengine.org/services.html
> >>>
> >>> Thought I was already subscribed to the
> developer
> >>> mailing list and was wondering where my previous
> >> email
> >>> had gone, so I'll try again.
> >>>
> >>> I'm investigating QuickFix for use as a gateway.
> >> I
> >>> need to be able to have sessions that use SubIds
> >>> (TargetSubID/SenderSubID).
> >>>
> >>> What is the best way to set the subid(s)?
> >>>
> >>> I've been hacking at the code to make the
> subid(s)
> >> an
> >>> optional part of the SessionID and have made
> some
> >>> progress but I'm only going to where the issues
> >> pop up
> >>> (ie code doesn't build, sessions can't be
> found).
> >>> Does anyone see a problem with making the
> subid(s)
> >> an
> >>> optional part of the SessionID?
> >>>
> >>> The other thought I had is to require a
> >>> SessionQualifier on all sessions and use the
> >> qualifier
> >>> to look up any additional tags (ie.
> >>> TargetSubId/SenderSubId) that need to be
> populated
> >>> before the message is sent.
> >>>
> >>> Anyone else have any ideas/solutions on how to
> do
> >>> this?
> >>>
> >>> Thanks,
> >>> Mike
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
______________________________________________________________________
> >>
> >>> ______________
> >>> Never miss a thing.  Make Yahoo your home page.
> >>> http://www.yahoo.com/r/hs
> >>>
> >>>
> >>
> >
>
----------------------------------------------------------------------
> >>
> >>> ---
> >>> SF.Net email is sponsored by: The Future of
> Linux
> >> Business White Paper
> >>> from Novell.  From the desktop to the data
> center,
> >> Linux is going
> >>> mainstream.  Let it simplify your IT future.
> >>>
> >>
> >
>
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >>> _______________________________________________
> >>> Quickfix-developers mailing list
> >>> Qui...@li...
> >>>
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >>>
> >>
> >>
> >
> >
> >
> >
> >        
> >
>
______________________________________________________________________
> 
> > ______________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile.  Try it now. 
> http:// 
> >
> mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> >
> >
> >
>
----------------------------------------------------------------------
> 
> > ---
> > SF.Net email is sponsored by:
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> 
> 



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Quickfix-developers] How to handle Sessions with SubIds

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

You need access to the DataDictionary object.  You can get this from  
the Session object with getDataDictionary().  This will allow you to  
look up the settings for that session.  Then yes, you will need to  
add the subids to the message with message.getHeader().setField().

--oren

On Dec 6, 2007, at 5:21 PM, Mike Perik wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Just to clarify, I would still need to manually set
> those fields in the to...()/from...() methods if the
> Session have them configured.
>
> I've looked at the interfaces for the Session object
> and I can't figure out how to get a handle to the
> SessionSettings object in the to...()/from...()
> methods.
>
> In C++ I would think you would do something like
>
> Session *s = Session::getSession(sessionID);
> -- I know there is no method on the Session object
> called getSessionSettings() but I thought the Session
> would know it's own settings.
> SessionSettings *ss = s->getSessionSettings();
>
>
> How do you get the SessionSettings object for a
> session?
>
>
>
>
> Mike
>
> --- Oren Miller <or...@qu...> wrote:
>
>> Mike,
>>
>> My suggestion if you want to do something like this
>> would be to add a
>> SenderSubID and TargetSubID field to the
>> configuration file, and you
>> can then look these up based on the session.  This
>> is probably
>> something we will be adding support for in the
>> future.
>>
>> --oren
>>
>> On Dec 6, 2007, at 12:03 PM, Mike Perik wrote:
>>
>>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/
>>> html/index.html
>>> QuickFIX Support:
>> http://www.quickfixengine.org/services.html
>>>
>>> Thought I was already subscribed to the developer
>>> mailing list and was wondering where my previous
>> email
>>> had gone, so I'll try again.
>>>
>>> I'm investigating QuickFix for use as a gateway.
>> I
>>> need to be able to have sessions that use SubIds
>>> (TargetSubID/SenderSubID).
>>>
>>> What is the best way to set the subid(s)?
>>>
>>> I've been hacking at the code to make the subid(s)
>> an
>>> optional part of the SessionID and have made some
>>> progress but I'm only going to where the issues
>> pop up
>>> (ie code doesn't build, sessions can't be found).
>>> Does anyone see a problem with making the subid(s)
>> an
>>> optional part of the SessionID?
>>>
>>> The other thought I had is to require a
>>> SessionQualifier on all sessions and use the
>> qualifier
>>> to look up any additional tags (ie.
>>> TargetSubId/SenderSubId) that need to be populated
>>> before the message is sent.
>>>
>>> Anyone else have any ideas/solutions on how to do
>>> this?
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>>
>>
> ______________________________________________________________________
>>
>>> ______________
>>> Never miss a thing.  Make Yahoo your home page.
>>> http://www.yahoo.com/r/hs
>>>
>>>
>>
> ----------------------------------------------------------------------
>>
>>> ---
>>> SF.Net email is sponsored by: The Future of Linux
>> Business White Paper
>>> from Novell.  From the desktop to the data center,
>> Linux is going
>>> mainstream.  Let it simplify your IT future.
>>>
>>
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>>
>>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>
>>
>
>
>
>
>        
> ______________________________________________________________________ 
> ______________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now.  http:// 
> mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Problems receiving the SecurityList message

[BRACKLEY, A. G. <And...@rb...>]

Thanks=20for=20this.=20This=20is=20indeed=20my=20problem=20although=20the=20=
specification=20I
was=20looking=20at=20has=20Symbol=20required=20=3D=20"N".

Anyway,=20I've=20copied=20the=20FIX44.xml=20file=20to=20another=20file=20a=
nd=20moved=20field
48=20(SecurityID)=20to=20be=20the=20first=20field=20in=20the=20instrument=20=
list=20and=20set
this=20as=20my=20DataDictionary.=20QuickFix=20now=20parses=20the=20message=
=20correctly=20and
sets=20up=20the=20repeating=20groups=20correctly=20too.



=20=20_____=20=20

From:=20Oren=20Miller=20[mailto:or...@qu...]=20
Sent:=2006=20December=202007=2017:53
To:=20BRACKLEY,=20Andrew,=20GBM
Cc:=20q...@li...
Subject:=20Re:=20[Quickfix-developers]=20Problems=20receiving=20the=20Secu=
rityList
message


The=20problem=20probably=20you=20are=20having=20probably=20has=20to=20do=20=
with=20the
Instrument=20component.=20=20If=20you=20look=20at=20the=20definition,=20it=
=20looks=20like
this.=20

<component=20name=3D"Instrument">
=20=20<field=20name=3D"Symbol"=20required=3D"Y"/>
=20=20<field=20name=3D"SymbolSfx"=20required=3D"N"/>
=20=20<field=20name=3D"SecurityID"=20required=3D"N"/>
=20=20<field=20name=3D"SecurityIDSource"=20required=3D"N"/>
=20=20...
</component>


As=20you=20notice=20the=20symbol=20field=20is=20required=20for=20this=20co=
mponent.=20=20This=20is
particularly=20important=20since=20it=20is=20also=20the=20first=20field=20=
in=20the=20group.
FIX=20always=20requires=20that=20the=20first=20field=20defined=20for=20a=20=
group=20be=20present
because=20that=20is=20the=20field=20that=20acts=20as=20the=20delimiter.=20=
=20So=20quickfix=20is
looking=20for=20the=20symbol=20in=20order=20to=20know=20when=20the=20first=
=20group=20begins,=20and
when=20it=20ends=20and=20a=20new=20group=20starts.=20=20Since=20it=20never=
=20hits=20the=20field,=20the
others=20are=20not=20considered=20part=20of=20the=20group=20and=20added=20=
to=20the=20main
message=20body.


--oren

On=20Dec=206,=202007,=20at=2010:20=20AM,=20BRACKLEY,=20Andrew,=20GBM=20wro=
te:


QuickFIX=20Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
<http://www.quickfixengine.org/quickfix/doc/html/index.html>=20
QuickFIX=20Support:=20http://www.quickfixengine.org/services.html
<http://www.quickfixengine.org/services.html>=20


Thanks=20for=20the=20response=20although=20it=20doesn't=20appear=20to=20be=
=20a=20custom=20field.
I've=20checked=20through=20all=20the=20fields=20in=20the=20groups=20and=20=
can't=20see=20anything
out=20of=20place.=20=20I've=20written=20a=20small=20test=20app=20that=20pa=
rses=20the=20message=20and
sends=20it=20through=20the=20QuickFix=20code=20to=20generate=20its=20inter=
nal=20structures
and=20ended=20up=20with=20something=20that=20looked=20incorrect.

From=20the=20message=20I=20receive=20from=20the=20client=20that=20is=20sho=
wn=20below=20(I've
formatted=20it=20for=20clarity)=20the=20XML=20generated=20from=20QuickFix=20=
looks=20wrong.

I'm=20seeing=20this:

<body>
=20=20=20<field=20number=3D"146"><![CDATA[2]]></field>
=20=20=20<group>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308379]]></field>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308380]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[2]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[1]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[4]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[2]]></field>

Whereas=20I'd=20expect=20to=20see:

=20=20=20<field=20number=3D"146"><![CDATA[2]]></field>
=20=20=20<group>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308379]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[2]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[4]]></field>
=20=20=20</group>
=20=20=20<group>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308380]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[1]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[2]]></field>
=20=20=20</group>

The=20formatted=20message=20quickfix=20receives=20is:

8=3DFIX.4.4=019=3D653=0135=3Dy=0149=3DTFSICAP=0156=3DRBS=0134=3D3=0152=3D2=
0071203-15:48:59=01

320=3Db703dc7b-47f4-4d81-a3ce-1150a14eb0d0=01
322=3D55=01
560=3D0=01
146=3D2=01

=20=20=2048=3D308379=01
=20=20=20711=3D1=01
=20=20=20=20=20=20310=3D2=01
=20=20=20=20=20=20763=3D0=01
=20=20=20=20=20=20318=3DEUR=01
=20=20=20=20=20=20879=3D10=01
=20=20=20=20=20=20810=3D0.05=01
=20=20=20555=3D2=01
=20=20=20=20=20=20600=3DEUR/USD=01
=20=20=20=20=20=20=20=20=20609=3DOPT=01
=20=20=20=20=20=20=20=20=20764=3DC=01
=20=20=20=20=20=20=20=20=20611=3D20071204=01
=20=20=20=20=20=20=20=20=20248=3D20071206=01
=20=20=20=20=20=20=20=20=20249=3D20071205=01
=20=20=20=20=20=20=20=20=20613=3DD=01
=20=20=20=20=20=20=20=20=20598=3DNY=01
=20=20=20=20=20=20=20=20=20942=3DEUR=01
=20=20=20=20=20=20=20=20=20620=3DON=01
=20=20=20=20=20=20=20=20=20624=3DB=01
=20=20=20=20=20=20=20=20=20556=3DUSD=01
=20=20=20=20=20=20600=3DEUR/USD=01
=20=20=20=20=20=20=20=20=20609=3DOPT=01
=20=20=20=20=20=20=20=20=20764=3DP=01
=20=20=20=20=20=20=20=20=20611=3D20071204=01
=20=20=20=20=20=20=20=20=20248=3D20071206=01
=20=20=20=20=20=20=20=20=20249=3D20071205=01
=20=20=20=20=20=20=20=20=20613=3DD=01
=20=20=20=20=20=20=20=20=20598=3DNY=01
=20=20=20=20=20=20=20=20=20942=3DEUR=01
=20=20=20=20=20=20=20=20=20620=3DON=01
=20=20=20=20=20=20=20=20=20624=3DB=01
=20=20=20=20=20=20=20=20=20556=3DUSD=01

=20=20=2048=3D308380=01
=20=20=20711=3D1=01
=20=20=20=20=20=20310=3D2=01
=20=20=20=20=20=20763=3D0=01
=20=20=20=20=20=20318=3DEUR=01
=20=20=20=20=20=20879=3D10=01
=20=20=20=20=20=20=20=20=20=20810=3D0.05=01
=20=20=20555=3D2=01
=20=20=20=20=20=20=20=20=20=20600=3DEUR/USD=01
=20=20=20=20=20=20=20=20=20=20=20=20=20609=3DOPT=01
=20=20=20=20=20=20=20=20=20=20=20=20=20764=3DC=01
=20=20=20=20=20=20=20=20=20=20=20=20=20611=3D20071210=01
=20=20=20=20=20=20=20=20=20=20=20=20=20248=3D20071212=01
=20=20=20=20=20=20=20=20=20=20=20=20=20249=3D20071205=01
=20=20=20=20=20=20=20=20=20=20=20=20=20613=3DD=01
=20=20=20=20=20=20=20=20=20=20=20=20=20598=3DNY=01
=20=20=20=20=20=20=20=20=20=20=20=20=20942=3DEUR=01
=20=20=20=20=20=20=20=20=20=20=20=20=20620=3D1W=01
=20=20=20=20=20=20=20=20=20=20=20=20=20624=3DB=01
=20=20=20=20=20=20=20=20=20=20=20=20=20556=3DUSD=01
=20=20=20=20=20=20=20=20=20=20600=3DEUR/USD=01
=20=20=20=20=20=20=20=20=20=20=20=20=20609=3DOPT=01
=20=20=20=20=20=20=20=20=20=20=20=20=20764=3DP=01
=20=20=20=20=20=20=20=20=20=20=20=20=20611=3D20071210=01
=20=20=20=20=20=20=20=20=20=20=20=20=20248=3D20071212=01
=20=20=20=20=20=20=20=20=20=20=20=20=20249=3D20071205=01
=20=20=20=20=20=20=20=20=20=20=20=20=20613=3DD=01
=20=20=20=20=20=20=20=20=20=20=20=20=20598=3DNY=01
=20=20=20=20=20=20=20=20=20=20=20=20=20942=3DEUR=01
=20=20=20=20=20=20=20=20=20=20=20=20=20620=3D1W=01
=20=20=20=20=20=20=20=20=20=20=20=20=20624=3DB=01
=20=20=20=20=20=20=20=20=20=20=20=20=20556=3DUSD=01
10=3D230=01

And=20from=20this=20QuickFix=20generates=20the=20following=20structure=20x=
ml.

<message>
=20=20<header>
=20=20=20=20<field=20number=3D"8"><![CDATA[FIX.4.4]]></field>
=20=20=20=20<field=20number=3D"9"><![CDATA[653]]></field>
=20=20=20=20<field=20number=3D"35"><![CDATA[y]]></field>
=20=20=20=20<field=20number=3D"34"><![CDATA[3]]></field>
=20=20=20=20<field=20number=3D"49"><![CDATA[TFSICAP]]></field>
=20=20=20=20<field=20number=3D"52"><![CDATA[20071203-15:48:59]]></field>
=20=20=20=20<field=20number=3D"56"><![CDATA[RBS]]></field>
=20=20</header>
=20=20<body>
=20=20=20=20<field=20number=3D"146"><![CDATA[2]]></field>
=20=20=20=20<field
number=3D"320"><![CDATA[b703dc7b-47f4-4d81-a3ce-1150a14eb0d0]]></field>
=20=20=20=20<field=20number=3D"322"><![CDATA[55]]></field>
=20=20=20=20<field=20number=3D"560"><![CDATA[0]]></field>
=20=20=20=20<group>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308379]]></field>
=20=20=20=20=20=20<field=20number=3D"48"><![CDATA[308380]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[2]]></field>
=20=20=20=20=20=20<field=20number=3D"711"><![CDATA[1]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[4]]></field>
=20=20=20=20=20=20<field=20number=3D"555"><![CDATA[2]]></field>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"600"><![CDATA[EUR/USD]]></field=
>
=20=20=20=20=20=20=20=20<field=20number=3D"609"><![CDATA[OPT]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"764"><![CDATA[C]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"611"><![CDATA[20071204]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"248"><![CDATA[20071206]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"249"><![CDATA[20071205]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"598"><![CDATA[NY]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"942"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"613"><![CDATA[D]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"620"><![CDATA[ON]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"624"><![CDATA[B]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"556"><![CDATA[USD]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"600"><![CDATA[EUR/USD]]></field=
>
=20=20=20=20=20=20=20=20<field=20number=3D"609"><![CDATA[OPT]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"764"><![CDATA[P]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"611"><![CDATA[20071204]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"248"><![CDATA[20071206]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"249"><![CDATA[20071205]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"598"><![CDATA[NY]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"942"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"613"><![CDATA[D]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"620"><![CDATA[ON]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"624"><![CDATA[B]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"556"><![CDATA[USD]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"600"><![CDATA[EUR/USD]]></field=
>
=20=20=20=20=20=20=20=20<field=20number=3D"609"><![CDATA[OPT]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"764"><![CDATA[C]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"611"><![CDATA[20071210]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"248"><![CDATA[20071212]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"249"><![CDATA[20071205]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"598"><![CDATA[NY]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"942"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"613"><![CDATA[D]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"620"><![CDATA[1W]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"624"><![CDATA[B]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"556"><![CDATA[USD]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"600"><![CDATA[EUR/USD]]></field=
>
=20=20=20=20=20=20=20=20<field=20number=3D"609"><![CDATA[OPT]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"764"><![CDATA[P]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"611"><![CDATA[20071210]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"248"><![CDATA[20071212]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"249"><![CDATA[20071205]]></fiel=
d>
=20=20=20=20=20=20=20=20<field=20number=3D"598"><![CDATA[NY]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"942"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"613"><![CDATA[D]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"620"><![CDATA[1W]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"624"><![CDATA[B]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"556"><![CDATA[USD]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"310"><![CDATA[2]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"763"><![CDATA[0]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"318"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"879"><![CDATA[10]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"810"><![CDATA[0.05]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20=20=20<group>
=20=20=20=20=20=20=20=20<field=20number=3D"310"><![CDATA[2]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"763"><![CDATA[0]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"318"><![CDATA[EUR]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"879"><![CDATA[10]]></field>
=20=20=20=20=20=20=20=20<field=20number=3D"810"><![CDATA[0.05]]></field>
=20=20=20=20=20=20</group>
=20=20=20=20</group>
=20=20</body>
=20=20<trailer>
=20=20=20=20<field=20number=3D"10"><![CDATA[230]]></field>
=20=20</trailer>
</message>


Andrew=20Brackley
RBS=20Global=20Banking=20&=20Markets
Office:=20+44=2020=207085=205495=20=20=20|=20=20Fax:=20+44=2020=207085=202=
081

-----Original=20Message-----
From:=20q...@li...
<mailto:qui...@li...>=20=20[
mailto:qui...@li...
<mailto:qui...@li...>=20]=20On=20Beha=
lf
Of=20Brian=20Erst
Sent:=2005=20December=202007=2016:02
To:=20BRACKLEY,=20Andrew,=20GBM;=20q...@li...urceforge.n=
et
<mailto:qui...@li...>=20
Subject:=20Re:=20[Quickfix-developers]=20Problems=20receiving=20the=20Secu=
rityList
message

QuickFIX=20Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
<http://www.quickfixengine.org/quickfix/doc/html/index.html>=20
QuickFIX=20Support:=20http://www.quickfixengine.org/services.html
<http://www.quickfixengine.org/services.html>=20




************************************************************************
***********

The=20Royal=20Bank=20of=20Scotland=20plc.=20Registered=20in=20Scotland=20N=
o=2090312.
Registered=20Office:=2036=20St=20Andrew=20Square,=20Edinburgh=20EH2=202YB.=
=20

Authorised=20and=20regulated=20by=20the=20Financial=20Services=20Authority=
=20

=20

This=20e-mail=20message=20is=20confidential=20and=20for=20use=20by=20the=20=


addressee=20only.=20If=20the=20message=20is=20received=20by=20anyone=20oth=
er=20

than=20the=20addressee,=20please=20return=20the=20message=20to=20the=20sen=
der=20

by=20replying=20to=20it=20and=20then=20delete=20the=20message=20from=20you=
r=20

computer.=20Internet=20e-mails=20are=20not=20necessarily=20secure.=20The=20=


Royal=20Bank=20of=20Scotland=20plc=20does=20not=20accept=20responsibility=20=
for=20

changes=20made=20to=20this=20message=20after=20it=20was=20sent.=20



Whilst=20all=20reasonable=20care=20has=20been=20taken=20to=20avoid=20the=20=


transmission=20of=20viruses,=20it=20is=20the=20responsibility=20of=20the=20=
recipient=20to=20

ensure=20that=20the=20onward=20transmission,=20opening=20or=20use=20of=20t=
his=20

message=20and=20any=20attachments=20will=20not=20adversely=20affect=20its=20=


systems=20or=20data.=20No=20responsibility=20is=20accepted=20by=20The=20

Royal=20Bank=20of=20Scotland=20plc=20in=20this=20regard=20and=20the=20reci=
pient=20should=20carry


out=20such=20virus=20and=20other=20checks=20as=20it=20considers=20appropri=
ate.=20

Visit=20our=20websites=20at:=20

www.rbs.com=20<http://www.rbs.com>=20

www.rbs.com/gbm=20<http://www.rbs.com/gbm>=20

www.rbsgc.com=20<http://www.rbsgc.com>=20

************************************************************************
***********

______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il
<http://www.messagelabs.com/email>=20=20
______________________________________________________________________

------------------------------------------------------------------------
-
SF.Net=20email=20is=20sponsored=20by:=20The=20Future=20of=20Linux=20Busine=
ss=20White=20Paper
from=20Novell.=20=20From=20the=20desktop=20to=20the=20data=20center,=20Lin=
ux=20is=20going
mainstream.=20=20Let=20it=20simplify=20your=20IT=20future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___________________
____________________________
<http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4__________________
_____________________________>=20
Quickfix-developers=20mailing=20list
Qui...@li...
<mailto:Qui...@li...>=20
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
<https://lists.sourceforge.net/lists/listinfo/quickfix-developers>=20



______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________

Re: [Quickfix-developers] How to handle Sessions with SubIds

[Mike P. <mic...@ya...>]

Just to clarify, I would still need to manually set
those fields in the to...()/from...() methods if the
Session have them configured. 

I've looked at the interfaces for the Session object
and I can't figure out how to get a handle to the
SessionSettings object in the to...()/from...()
methods.

In C++ I would think you would do something like

Session *s = Session::getSession(sessionID);
-- I know there is no method on the Session object
called getSessionSettings() but I thought the Session
would know it's own settings.
SessionSettings *ss = s->getSessionSettings(); 


How do you get the SessionSettings object for a
session?




Mike

--- Oren Miller <or...@qu...> wrote:

> Mike,
> 
> My suggestion if you want to do something like this
> would be to add a  
> SenderSubID and TargetSubID field to the
> configuration file, and you  
> can then look these up based on the session.  This
> is probably  
> something we will be adding support for in the
> future.
> 
> --oren
> 
> On Dec 6, 2007, at 12:03 PM, Mike Perik wrote:
> 
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/ 
> > html/index.html
> > QuickFIX Support:
> http://www.quickfixengine.org/services.html
> >
> > Thought I was already subscribed to the developer
> > mailing list and was wondering where my previous
> email
> > had gone, so I'll try again.
> >
> > I'm investigating QuickFix for use as a gateway. 
> I
> > need to be able to have sessions that use SubIds
> > (TargetSubID/SenderSubID).
> >
> > What is the best way to set the subid(s)?
> >
> > I've been hacking at the code to make the subid(s)
> an
> > optional part of the SessionID and have made some
> > progress but I'm only going to where the issues
> pop up
> > (ie code doesn't build, sessions can't be found).
> > Does anyone see a problem with making the subid(s)
> an
> > optional part of the SessionID?
> >
> > The other thought I had is to require a
> > SessionQualifier on all sessions and use the
> qualifier
> > to look up any additional tags (ie.
> > TargetSubId/SenderSubId) that need to be populated
> > before the message is sent.
> >
> > Anyone else have any ideas/solutions on how to do
> > this?
> >
> > Thanks,
> > Mike
> >
> >
> >        
> >
>
______________________________________________________________________
> 
> > ______________
> > Never miss a thing.  Make Yahoo your home page.
> > http://www.yahoo.com/r/hs
> >
> >
>
----------------------------------------------------------------------
> 
> > ---
> > SF.Net email is sponsored by: The Future of Linux
> Business White Paper
> > from Novell.  From the desktop to the data center,
> Linux is going
> > mainstream.  Let it simplify your IT future.
> >
>
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> 
> 




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Quickfix-developers] How to handle Sessions with SubIds

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

Mike,

My suggestion if you want to do something like this would be to add a  
SenderSubID and TargetSubID field to the configuration file, and you  
can then look these up based on the session.  This is probably  
something we will be adding support for in the future.

--oren

On Dec 6, 2007, at 12:03 PM, Mike Perik wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Thought I was already subscribed to the developer
> mailing list and was wondering where my previous email
> had gone, so I'll try again.
>
> I'm investigating QuickFix for use as a gateway.  I
> need to be able to have sessions that use SubIds
> (TargetSubID/SenderSubID).
>
> What is the best way to set the subid(s)?
>
> I've been hacking at the code to make the subid(s) an
> optional part of the SessionID and have made some
> progress but I'm only going to where the issues pop up
> (ie code doesn't build, sessions can't be found).
> Does anyone see a problem with making the subid(s) an
> optional part of the SessionID?
>
> The other thought I had is to require a
> SessionQualifier on all sessions and use the qualifier
> to look up any additional tags (ie.
> TargetSubId/SenderSubId) that need to be populated
> before the message is sent.
>
> Anyone else have any ideas/solutions on how to do
> this?
>
> Thanks,
> Mike
>
>
>        
> ______________________________________________________________________ 
> ______________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] How to handle Sessions with SubIds

[Mike P. <mic...@ya...>]

Thought I was already subscribed to the developer
mailing list and was wondering where my previous email
had gone, so I'll try again.

I'm investigating QuickFix for use as a gateway.  I
need to be able to have sessions that use SubIds
(TargetSubID/SenderSubID).

What is the best way to set the subid(s)?

I've been hacking at the code to make the subid(s) an
optional part of the SessionID and have made some
progress but I'm only going to where the issues pop up
(ie code doesn't build, sessions can't be found). 
Does anyone see a problem with making the subid(s) an
optional part of the SessionID?

The other thought I had is to require a
SessionQualifier on all sessions and use the qualifier
to look up any additional tags (ie.
TargetSubId/SenderSubId) that need to be populated
before the message is sent.

Anyone else have any ideas/solutions on how to do
this?

Thanks,
Mike


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs