quickfix-developers — QuickFIX developers forum

[Quickfix-developers] isSameSession() problem when StartTime==EndTime

[Brendan B. <br...@ka...>]

Hi,

Suppose I have executor.cfg and tradeclient.cfg containing

StartTime=21:00:00
EndTime=21:00:00

Suppose it's 23:59:00 UTC and I run executor and tradeclient.
Sessions connect and login.

At 00:00:00 UTC the sessions disconnect and attempt to reconnect.

I think the problem is in:
SessionTime::isSameSession(const UtcTimeOnly& start,
			   const UtcTimeOnly& end,
			   const UtcTimeStamp& time1,
			   const UtcTimeStamp& time2) {

...
     UtcDate time1Date( time1 );
     UtcDate time2Date( time2 );

     if( start < end || start == end )
       return time1Date == time2Date;

}

In this case:
time1 = May 19 00:00:00; now
time2 = May 18 23:59:01; creation time

so time1Date != time2Date and the session is reset.

I tried searching the mail archives on sourceforge.net but the search
engine seems to be down (no results on any query).

Does anyone have a suggestion on how to handle this?

Regards,
Brendan

Re: [Quickfix-developers] MsgSeqNum too low logon err

[James R. <jam...@gm...>]

Zoran,

You could add the following to the initiator session config:

ResetOnLogout=3DY
ResetOnDisconnect=3DY

The big assumption here is that the vendor resets their sequence numbers
upon disconnection/logout. We have FIX vendor connections here that will
reset sequence numbers every day (but not intraday), as well as some that
will do so upon each  disconnection/logout.

-jr

On 5/18/06, Zoran Cetusic <zo...@av...> wrote:
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i=
ndex.html
> QuickFIX Support: http://www.quickfixengine.org/services.html We're using
> a simple initiator connection for our application. The application
> unexpectedly shut down after receiving a number of market data updates, a=
nd,
> now, it would appear that we continually get
>
> ... 58=3DMsgSeqNum too low, expecting 387 but received 1=0110=3D243=01
>
> from the server on the other end. Can anyone tell me what is the
> appropriate way to resolve this condition ?
>
> Thank you very much,
>
> --
> *Zoran Cetusic* | President & CEO
> *phone* +1.858.218.4496 | *fax* +1.858.675.4504
> *email:* zo...@av...* | web * www.avalonsoft.com
>  <https://lists.sourceforge.net/lists/listinfo/quickfix-developers>
>

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

[Brad H. <Bra...@gb...>]

Hi Steve,

Along these lines, it'd be nice if a (far in the) future version made it
easy to insert MINA's IO and Protocol filters in the chain.  In addition
to making things like IP filtering trivial, using MINA 0.9+ and Java5
would make it very easy to add SSL support
(http://directory.apache.org/subprojects/mina/apidocs/org/apache/mina/fi
lter/SSLFilter.html). =20

Cheers,
Brad.

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Thursday, 18 May 2006 4:03 PM
Cc: qui...@li...
Subject: RE: [Quickfix-developers] Restricting acceptor to specific IP
address(es)

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

Hi Ajay,=20

I assume you aren't using QuickFIX/J but for those who are I
think this can already be done, but not as elegantly as it
could be. Each session has a "Responder" that encapsulates
the network connection. The Responder has a method for
accessing the remote IP address. You could use this information
in the Application logon callback to validate the remote IP=20
address. This is more a workaround than a recommended solution.=20
The Responder interface is public (by necessity) but I consider=20
it more of an internal interface and one that I'll probably=20
refactor at some point.

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Caleb Epstein
> Sent: Thursday, May 18, 2006 6:05 AM
> To: Ajay Kamdar
> Cc: Oren Miller; qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to=20
> specific IP address(es)
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
> > In general do you agree that having the engine itself=20
> support IP address
> > matching before establishing the FIX session is a much cleaner and
> > elegant solution than to have to work around with a=20
> separate firewall?
> > If we are in agreement in principle that this would be a=20
> good thing to
> > add to QuickFIX, then I can work on submitting a patch suitable for
> > wider consumption. Otherwise I can simply hack something up=20
> much more
> > quickly that is specific for my environment.
>=20
> I'm sure if you submitted a patch, it would be accepted.  If its
> useful to you, it is surely useful to others, just as long as it
> doesn't change the current default behavior.
>=20
> I submit that you'll probably want to support multiple addresses for
> each session, specified as dotted quads (e.g. A.B.C.D) or in
> address/mask format (e.g. A.B.C/24).
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] MsgSeqNum too low logon err

[Zoran C. <zo...@av...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We're using a simple initiator connection for our application. The
application unexpectedly shut down after receiving a number of market
data updates, and, now, it would appear that we continually get <br>
<br>
... 58=MsgSeqNum too low, expecting 387 but received 1
10=243
<br>
<br>
from the server on the other end. Can anyone tell me what is the
appropriate way to resolve this condition ? <br>
<br>
Thank you very much, <br>
<br>
<div class="moz-signature">-- <br>
<strong><span style="color: rgb(0, 0, 0);">Zoran Cetusic</span></strong><span
 style=""> </span><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);">| </span><span
 style="font-size: 7.5pt; color: blue;">President &amp; CEO</span><br>
<div class="moz-signature"><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);"><strong>phone</strong>
+1.858.218.4496 | <strong>fax</strong>
+1.858.675.4504</span><span style=""><o:p></o:p></span><br>
<strong><span style="font-size: 7.5pt; color: rgb(102, 102, 102);">email:</span></strong><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);"> <a
 href="mailto:zo...@av..."
 title="mailto:zo...@av...
zo...@av..."><span
 title="mailto:zo...@av...">zo...@av...</span></a><strong>
|
web </strong> <a href="http://www.avalonsoft.com/"
 title="http://www.avalonsoft.com">www.avalonsoft.com</a></span></div>
</div>
</body>
</html>

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

Well there is a natural hesitation to do something like this due to =20
the design philosophy of QuickFIX.  It is different from most vendors =20=

is that QuickFIX is designed to be a pure protocol implementation, =20
not a platform.  I'm just mentioning that because we look upon new =20
functionality that appears to be out of scope of the protocol with =20
suspicion.  In the end it means you have to sell harder to get it =20
into QuickFIX :).

One issue I have with this it feels like we are implementing firewall =20=

like functionality into the engine.  And in the end, a firewall is =20
going to do a much better job of it as that is its design.

And that leads to this problem.  Such functionality becomes =20
completely useless if you have any sort of gateway between you and =20
the client.  If you are using Stunnel for instance, having QuickFIX =20
filter by IP will do nothing at all.  So then do you build firewall =20
capabilities into Stunnel (maybe they do, I don't know)?  Or a more =20
relevant example coming up will be the presence of FIX over FAST =20
which will require FAST gateway.  So once again you must build this =20
functionality into the FAST gateway.  Or maybe you are coming into =20
QuickFIX from an application server.  Anything that stands between =20
your engine and the counterparty makes QuickFIX filtering pretty =20
useless.

In my mind the *real* feature request here, is for a QuickFIX =20
application to be able to get more details about the underlying =20
connection.  Something that has been requested in the past.  With =20
this capability you can look at the incoming IP and filter as you see =20=

fit if that is how you choose to use the information.  This is =20
something I feel more comfortable adding to the core library.

--oren

On May 17, 2006, at 2:57 PM, Ajay Kamdar wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Ok, removal of the single port restriction should make the firewall
> solution more palatable in many situations where the number of FIX
> sessions is not high and FIX session configuration is mostly static.
> However IMHO that is still a less than desirable solution for
> organizations (like mine) which have 100+ external FIX sessions, =20
> session
> configurations change often (especially in customer staging/test), and
> the FIX session configuration and onboarding is primarily handled by a
> non-technical client services team.
>
> In general do you agree that having the engine itself support IP =20
> address
> matching before establishing the FIX session is a much cleaner and
> elegant solution than to have to work around with a separate firewall?
> If we are in agreement in principle that this would be a good thing to
> add to QuickFIX, then I can work on submitting a patch suitable for
> wider consumption. Otherwise I can simply hack something up much more
> quickly that is specific for my environment.
>
> - Ajay
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Wednesday, May 17, 2006 3:39 PM
> To: Ajay Kamdar
> Cc: Caleb Epstein; qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
> address(es)
>
>
> The single port restriction is no longer true with the latest CVS
> source.  You can now assign the acceptor port on a per session basis.
>
> --oren
>
> On May 17, 2006, at 2:22 PM, Ajay Kamdar wrote:
>
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> A) The last time I checked, QuickFIX allowed only one Acceptor port
>> for
>> all the Sessions configured to run within one QuickFIX instance.
>> B) Say I have sessions S1 through S10 defined within the config file
>> with ConnectionType=3Dacceptor. All counter parties will have to =20
>> connect
>> to the single acceptor port in (A)
>> C) The allowed IP addresses for S1-S10 are respectively IP1 through
>> IP10
>> (i.e. IP1 can logon only to S1 but not to S2-S9, IP2 only to S2 but
>> not
>> to S1,S3-S9, etc.)
>>
>> Given the above scenario, I am afraid I don't get how the local
>> firewall
>> process would know enough to accept a socket connection from IP1
>> only if
>> FIX session that would get established (as determined by the =20
>> SessionID
>> composed of BeginString,SenderCompID,TargetCompID) is S1 but not
>> accept
>> the connection if IP1 is erroneously trying to establish sessions
>> S2-S9.
>> For that match to be made correctly, the FIX engine actually has to
>> also
>> match the IP address of the socket peer with the allowed IP addresses
>> for the Session before considering the FIX Session to have been
>> successfully established.
>>
>> - Ajay
>>
>> -----Original Message-----
>> From: Caleb Epstein [mailto:cal...@gm...]
>> Sent: Wednesday, May 17, 2006 2:48 PM
>> To: Ajay Kamdar
>> Cc: Oren Miller; Zoran Cetusic;
>> qui...@li...
>> Subject: Re: [Quickfix-developers] Restricting acceptor to =20
>> specific IP
>> address(es)
>>
>>
>> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
>>
>>> - The local firewall process would need to be understand the concept
>>> of FIX sessions
>>
>> Why?  Just restrict access to the port(s) your Acceptor is running
>> on to
>> the IPs you want to allow.
>>
>> --
>> Caleb Epstein
>> caleb dot epstein at gmail dot com
>>
>> ---------------------------------------------------------------------=20=

>> -
>> -----
>>
>> The information in this email is confidential and may be legally
>> privileged.
>> It is intended solely for the addressee. Access to this email by
>> anyone else
>> is unauthorized. If you are not the intended recipient, any
>> disclosure, copying,
>> distribution or any action taken or omitted to be taken in reliance
>> on it, is
>> prohibited and may be unlawful.
>>
>> TradeWeb reserves the right to monitor and review the content of
>> all messages sent
>> to or from this e-mail address. Messages sent to or from this e-
>> mail address may
>> be stored on the TradeWeb e-mail system.
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=12164=
2
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

[Steve B. <sb...@sm...>]

Hi Ajay,=20

I assume you aren't using QuickFIX/J but for those who are I
think this can already be done, but not as elegantly as it
could be. Each session has a "Responder" that encapsulates
the network connection. The Responder has a method for
accessing the remote IP address. You could use this information
in the Application logon callback to validate the remote IP=20
address. This is more a workaround than a recommended solution.=20
The Responder interface is public (by necessity) but I consider=20
it more of an internal interface and one that I'll probably=20
refactor at some point.

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Caleb Epstein
> Sent: Thursday, May 18, 2006 6:05 AM
> To: Ajay Kamdar
> Cc: Oren Miller; qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to=20
> specific IP address(es)
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
> > In general do you agree that having the engine itself=20
> support IP address
> > matching before establishing the FIX session is a much cleaner and
> > elegant solution than to have to work around with a=20
> separate firewall?
> > If we are in agreement in principle that this would be a=20
> good thing to
> > add to QuickFIX, then I can work on submitting a patch suitable for
> > wider consumption. Otherwise I can simply hack something up=20
> much more
> > quickly that is specific for my environment.
>=20
> I'm sure if you submitted a patch, it would be accepted.  If its
> useful to you, it is surely useful to others, just as long as it
> doesn't change the current default behavior.
>=20
> I submit that you'll probably want to support multiple addresses for
> each session, specified as dotted quads (e.g. A.B.C.D) or in
> address/mask format (e.g. A.B.C/24).
>=20
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

[Bill R. <rob...@ra...>]

> In general do you agree that having the engine itself support=20
> IP address matching before establishing the FIX session is a=20
> much cleaner and elegant solution than to have to work around=20
> with a separate firewall?

Depends really what you want to achieve with IP address matching. If it
should be a security or authorization solution, I disagree.=20
The underlying issue could be solved by proper FIX login messages (via
tag 553/554).

Robert

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
> In general do you agree that having the engine itself support IP address
> matching before establishing the FIX session is a much cleaner and
> elegant solution than to have to work around with a separate firewall?
> If we are in agreement in principle that this would be a good thing to
> add to QuickFIX, then I can work on submitting a patch suitable for
> wider consumption. Otherwise I can simply hack something up much more
> quickly that is specific for my environment.

I'm sure if you submitted a patch, it would be accepted.  If its
useful to you, it is surely useful to others, just as long as it
doesn't change the current default behavior.

I submit that you'll probably want to support multiple addresses for
each session, specified as dotted quads (e.g. A.B.C.D) or in
address/mask format (e.g. A.B.C/24).

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

Ok, removal of the single port restriction should make the firewall
solution more palatable in many situations where the number of FIX
sessions is not high and FIX session configuration is mostly static.
However IMHO that is still a less than desirable solution for
organizations (like mine) which have 100+ external FIX sessions, session
configurations change often (especially in customer staging/test), and
the FIX session configuration and onboarding is primarily handled by a
non-technical client services team.=20

In general do you agree that having the engine itself support IP address
matching before establishing the FIX session is a much cleaner and
elegant solution than to have to work around with a separate firewall?
If we are in agreement in principle that this would be a good thing to
add to QuickFIX, then I can work on submitting a patch suitable for
wider consumption. Otherwise I can simply hack something up much more
quickly that is specific for my environment.

- Ajay

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Wednesday, May 17, 2006 3:39 PM
To: Ajay Kamdar
Cc: Caleb Epstein; qui...@li...
Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
address(es)


The single port restriction is no longer true with the latest CVS =20
source.  You can now assign the acceptor port on a per session basis.

--oren

On May 17, 2006, at 2:22 PM, Ajay Kamdar wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> A) The last time I checked, QuickFIX allowed only one Acceptor port
> for
> all the Sessions configured to run within one QuickFIX instance.
> B) Say I have sessions S1 through S10 defined within the config file
> with ConnectionType=3Dacceptor. All counter parties will have to =
connect
> to the single acceptor port in (A)
> C) The allowed IP addresses for S1-S10 are respectively IP1 through =20
> IP10
> (i.e. IP1 can logon only to S1 but not to S2-S9, IP2 only to S2 but =20
> not
> to S1,S3-S9, etc.)
>
> Given the above scenario, I am afraid I don't get how the local
> firewall
> process would know enough to accept a socket connection from IP1 =20
> only if
> FIX session that would get established (as determined by the SessionID
> composed of BeginString,SenderCompID,TargetCompID) is S1 but not =20
> accept
> the connection if IP1 is erroneously trying to establish sessions =20
> S2-S9.
> For that match to be made correctly, the FIX engine actually has to =20
> also
> match the IP address of the socket peer with the allowed IP addresses
> for the Session before considering the FIX Session to have been
> successfully established.
>
> - Ajay
>
> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Wednesday, May 17, 2006 2:48 PM
> To: Ajay Kamdar
> Cc: Oren Miller; Zoran Cetusic;=20
> qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
> address(es)
>
>
> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
>
>> - The local firewall process would need to be understand the concept=20
>> of FIX sessions
>
> Why?  Just restrict access to the port(s) your Acceptor is running
> on to
> the IPs you want to allow.
>
> --
> Caleb Epstein
> caleb dot epstein at gmail dot com
>
> ----------------------------------------------------------------------
> -----
>
> The information in this email is confidential and may be legally
> privileged.
> It is intended solely for the addressee. Access to this email by =20
> anyone else
> is unauthorized. If you are not the intended recipient, any =20
> disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance =20
> on it, is
> prohibited and may be unlawful.
>
> TradeWeb reserves the right to monitor and review the content of
> all messages sent
> to or from this e-mail address. Messages sent to or from this e-=20
> mail address may
> be stored on the TradeWeb e-mail system.
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

The single port restriction is no longer true with the latest CVS =20
source.  You can now assign the acceptor port on a per session basis.

--oren

On May 17, 2006, at 2:22 PM, Ajay Kamdar wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> A) The last time I checked, QuickFIX allowed only one Acceptor port =20=

> for
> all the Sessions configured to run within one QuickFIX instance.
> B) Say I have sessions S1 through S10 defined within the config file
> with ConnectionType=3Dacceptor. All counter parties will have to =
connect
> to the single acceptor port in (A)
> C) The allowed IP addresses for S1-S10 are respectively IP1 through =20=

> IP10
> (i.e. IP1 can logon only to S1 but not to S2-S9, IP2 only to S2 but =20=

> not
> to S1,S3-S9, etc.)
>
> Given the above scenario, I am afraid I don't get how the local =20
> firewall
> process would know enough to accept a socket connection from IP1 =20
> only if
> FIX session that would get established (as determined by the SessionID
> composed of BeginString,SenderCompID,TargetCompID) is S1 but not =20
> accept
> the connection if IP1 is erroneously trying to establish sessions =20
> S2-S9.
> For that match to be made correctly, the FIX engine actually has to =20=

> also
> match the IP address of the socket peer with the allowed IP addresses
> for the Session before considering the FIX Session to have been
> successfully established.
>
> - Ajay
>
> -----Original Message-----
> From: Caleb Epstein [mailto:cal...@gm...]
> Sent: Wednesday, May 17, 2006 2:48 PM
> To: Ajay Kamdar
> Cc: Oren Miller; Zoran Cetusic;
> qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
> address(es)
>
>
> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
>
>> - The local firewall process would need to be understand the concept
>> of FIX sessions
>
> Why?  Just restrict access to the port(s) your Acceptor is running =20
> on to
> the IPs you want to allow.
>
> --=20
> Caleb Epstein
> caleb dot epstein at gmail dot com
>
> ----------------------------------------------------------------------=20=

> -----
>
> The information in this email is confidential and may be legally =20
> privileged.
> It is intended solely for the addressee. Access to this email by =20
> anyone else
> is unauthorized. If you are not the intended recipient, any =20
> disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance =20=

> on it, is
> prohibited and may be unlawful.
>
> TradeWeb reserves the right to monitor and review the content of =20
> all messages sent
> to or from this e-mail address. Messages sent to or from this e-=20
> mail address may
> be stored on the TradeWeb e-mail system.
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

A) The last time I checked, QuickFIX allowed only one Acceptor port for
all the Sessions configured to run within one QuickFIX instance.=20
B) Say I have sessions S1 through S10 defined within the config file
with ConnectionType=3Dacceptor. All counter parties will have to connect
to the single acceptor port in (A)
C) The allowed IP addresses for S1-S10 are respectively IP1 through IP10
(i.e. IP1 can logon only to S1 but not to S2-S9, IP2 only to S2 but not
to S1,S3-S9, etc.)

Given the above scenario, I am afraid I don't get how the local firewall
process would know enough to accept a socket connection from IP1 only if
FIX session that would get established (as determined by the SessionID
composed of BeginString,SenderCompID,TargetCompID) is S1 but not accept
the connection if IP1 is erroneously trying to establish sessions S2-S9.
For that match to be made correctly, the FIX engine actually has to also
match the IP address of the socket peer with the allowed IP addresses
for the Session before considering the FIX Session to have been
successfully established.

- Ajay

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...]=20
Sent: Wednesday, May 17, 2006 2:48 PM
To: Ajay Kamdar
Cc: Oren Miller; Zoran Cetusic;
qui...@li...
Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
address(es)


On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:

> - The local firewall process would need to be understand the concept=20
> of FIX sessions

Why?  Just restrict access to the port(s) your Acceptor is running on to
the IPs you want to allow.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

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

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:

> - The local firewall process would need to be understand the concept of F=
IX
> sessions

Why?  Just restrict access to the port(s) your Acceptor is running on
to the IPs you want to allow.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

I suppose that could be done. But the disadvantages of that are:
- The local firewall process would need to be understand the concept of
FIX sessions
- The configuration of a FIX session -- the standard QF settings and the
additional configuration of which IP addresses are allowed -- would not
be centralized in one place; or else the local firewall process would
need to be modified to  parse and understand the QF cfg file
- There are now two separate process to monitor (QF and LFW) instead of
just QF
=20
All commercial FIX engines I know of have support for restricting IP
addresses built into them. And having worked on the Appia FIX engine
code, I know first hand it is not all that difficult to do. I haven't
yet looked very closely at the QF source code, but in the next few days
will try to find some cycles to do so and submit a patch for the
ThreadedSocketAcceptor.
=20
Regards,
=20
- Ajay
=20
-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Wednesday, May 17, 2006 2:22 PM
To: Ajay Kamdar; Zoran Cetusic
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
address(es)



	Can't you run your own firewall process on the machine running
the FIX engine?
	=20
	--oren

		----- Original Message -----=20
		From: Ajay Kamdar <mailto:Aja...@tr...> =20
		To: Zoran Cetusic <mailto:zo...@av...> =20
		Cc: qui...@li...=20
		Sent: Wednesday, May 17, 2006 12:12 PM
		Subject: RE: [Quickfix-developers] Restricting acceptor
to specific IP address(es)

		The requirement typically is to restrict all IP
addresses by default, and even an allowed IP address (range) would be
limited to connect to only a specific FIX session. Since a firewall
wouldn't know anything about FIX session configuration it can't really
do the job. Additionally, in production environments that have tens or
hundreds of client connections, modifying the firewall configuration
every time a new client is brought onboard would be impractical. Except
in small shops, Network/firewall management and FIX infrastructure
support are typically handled by different teams, with network/firewall
changes often requiring a chain of approvals and having to fit into
specific change management windows (think change management and SOX) .=20
		=20
		Hence while using the firewall to restrict specific FIX
sessions to specific IP addresses might work for a small FIX
infrastructure, I am afraid it is not a very viable solution for a large
scale robust FIX infrastructure. This is something that is best done
within the FIX engine or by an API hook that allow an application to
apply the IP address check.
		=20
		- Ajay

			-----Original Message-----
			From: Zoran Cetusic
[mailto:zo...@av...]=20
			Sent: Wednesday, May 17, 2006 12:16 PM
			To: Ajay Kamdar
			Cc: qui...@li...
			Subject: Re: [Quickfix-developers] Restricting
acceptor to specific IP address(es)
		=09
		=09
			I would think in a production environment you
would be behind a firewall that would have the ability to block NAT to
your QuickFIX server from specific IP addresses.=20
		=09
			Ajay Kamdar wrote:=20

				How can QuickFIX be made to accept
connection attempts only from specific IP addresses and IP address
range? The allowed IP addresses and IP address range could be different
for each Session defined in the config file.
				=20
				Restricting the incoming FIX sessions to
specific IPs would I suppose be a common requirement for production
configurations. Am I missing some obvious configuration parameters to
make this happen? Or do the core QuickFIX acceptor classes have to be
modified for this to happen?
				=20
				Thanks,
				=20
				- Ajay

			=09
=09
________________________________________________________________________
			=09
				The information in this email is
confidential and may be legally privileged.
				It is intended solely for the addressee.
Access to this email by anyone else
				is unauthorized. If you are not the
intended recipient, any disclosure, copying,
				distribution or any action taken or
omitted to be taken in reliance on it, is
				prohibited and may be unlawful.
			=09
				TradeWeb reserves the right to monitor
and review the content of all messages sent
				to or from this e-mail address. Messages
sent to or from this e-mail address may
				be stored on the TradeWeb e-mail system.
			=09



			--=20
			Zoran Cetusic | President & CEO
		=09
			phone +1.858.218.4496 | fax +1.858.675.4504
			email: zo...@av...
<mailto:zo...@av...>  | web www.avalonsoft.com
<http://www.avalonsoft.com/>=20

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

MessageCan't you run your own firewall process on the machine running =
the FIX engine?

--oren
  ----- Original Message -----=20
  From: Ajay Kamdar=20
  To: Zoran Cetusic=20
  Cc: qui...@li...=20
  Sent: Wednesday, May 17, 2006 12:12 PM
  Subject: RE: [Quickfix-developers] Restricting acceptor to specific IP =
address(es)


  The requirement typically is to restrict all IP addresses by default, =
and even an allowed IP address (range) would be limited to connect to =
only a specific FIX session. Since a firewall wouldn't know anything =
about FIX session configuration it can't really do the job. =
Additionally, in production environments that have tens or hundreds of =
client connections, modifying the firewall configuration every time a =
new client is brought onboard would be impractical. Except in small =
shops, Network/firewall management and FIX infrastructure support are =
typically handled by different teams, with network/firewall changes =
often requiring a chain of approvals and having to fit into specific =
change management windows (think change management and SOX) .=20

  Hence while using the firewall to restrict specific FIX sessions to =
specific IP addresses might work for a small FIX infrastructure, I am =
afraid it is not a very viable solution for a large scale robust FIX =
infrastructure. This is something that is best done within the FIX =
engine or by an API hook that allow an application to apply the IP =
address check.

  - Ajay
    -----Original Message-----
    From: Zoran Cetusic [mailto:zo...@av...]=20
    Sent: Wednesday, May 17, 2006 12:16 PM
    To: Ajay Kamdar
    Cc: qui...@li...
    Subject: Re: [Quickfix-developers] Restricting acceptor to specific =
IP address(es)


    I would think in a production environment you would be behind a =
firewall that would have the ability to block NAT to your QuickFIX =
server from specific IP addresses.=20

    Ajay Kamdar wrote:=20
      How can QuickFIX be made to accept connection attempts only from =
specific IP addresses and IP address range? The allowed IP addresses and =
IP address range could be different for each Session defined in the =
config file.

      Restricting the incoming FIX sessions to specific IPs would I =
suppose be a common requirement for production configurations. Am I =
missing some obvious configuration parameters to make this happen? Or do =
the core QuickFIX acceptor classes have to be modified for this to =
happen?

      Thanks,

      - Ajay

      =
________________________________________________________________________

      The information in this email is confidential and may be legally =
privileged.
      It is intended solely for the addressee. Access to this email by =
anyone else
      is unauthorized. If you are not the intended recipient, any =
disclosure, copying,
      distribution or any action taken or omitted to be taken in =
reliance on it, is
      prohibited and may be unlawful.

      TradeWeb reserves the right to monitor and review the content of =
all messages sent
      to or from this e-mail address. Messages sent to or from this =
e-mail address may
      be stored on the TradeWeb e-mail system.





    --=20
    Zoran Cetusic | President & CEO

    phone +1.858.218.4496 | fax +1.858.675.4504
    email: zo...@av... | web www.avalonsoft.com

RE: [Quickfix-developers] Restricting acceptor to specific IP address(es)

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

The requirement typically is to restrict all IP addresses by default,
and even an allowed IP address (range) would be limited to connect to
only a specific FIX session. Since a firewall wouldn't know anything
about FIX session configuration it can't really do the job.
Additionally, in production environments that have tens or hundreds of
client connections, modifying the firewall configuration every time a
new client is brought onboard would be impractical. Except in small
shops, Network/firewall management and FIX infrastructure support are
typically handled by different teams, with network/firewall changes
often requiring a chain of approvals and having to fit into specific
change management windows (think change management and SOX) .=20
=20
Hence while using the firewall to restrict specific FIX sessions to
specific IP addresses might work for a small FIX infrastructure, I am
afraid it is not a very viable solution for a large scale robust FIX
infrastructure. This is something that is best done within the FIX
engine or by an API hook that allow an application to apply the IP
address check.
=20
- Ajay

	-----Original Message-----
	From: Zoran Cetusic [mailto:zo...@av...]=20
	Sent: Wednesday, May 17, 2006 12:16 PM
	To: Ajay Kamdar
	Cc: qui...@li...
	Subject: Re: [Quickfix-developers] Restricting acceptor to
specific IP address(es)
=09
=09
	I would think in a production environment you would be behind a
firewall that would have the ability to block NAT to your QuickFIX
server from specific IP addresses.=20
=09
	Ajay Kamdar wrote:=20

		How can QuickFIX be made to accept connection attempts
only from specific IP addresses and IP address range? The allowed IP
addresses and IP address range could be different for each Session
defined in the config file.
		=20
		Restricting the incoming FIX sessions to specific IPs
would I suppose be a common requirement for production configurations.
Am I missing some obvious configuration parameters to make this happen?
Or do the core QuickFIX acceptor classes have to be modified for this to
happen?
		=20
		Thanks,
		=20
		- Ajay

	=09
=09
________________________________________________________________________
	=09
		The information in this email is confidential and may be
legally privileged.
		It is intended solely for the addressee. Access to this
email by anyone else
		is unauthorized. If you are not the intended recipient,
any disclosure, copying,
		distribution or any action taken or omitted to be taken
in reliance on it, is
		prohibited and may be unlawful.
	=09
		TradeWeb reserves the right to monitor and review the
content of all messages sent
		to or from this e-mail address. Messages sent to or from
this e-mail address may
		be stored on the TradeWeb e-mail system.
	=09



	--=20
	Zoran Cetusic | President & CEO
=09
	phone +1.858.218.4496 | fax +1.858.675.4504
	email: zo...@av... <mailto:zo...@av...>  | web
www.avalonsoft.com <http://www.avalonsoft.com/>=20

[Quickfix-developers] Messages.h

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

Hello,

There is a problem in VC projects:
The file src/c++/Messages.h was removed in the latest versions, but 
still exist in the projects.


Regards,
		Alexey Zubko

Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

[Zoran C. <zo...@av...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I would think in a production environment you would be behind a
firewall that would have the ability to block NAT to your QuickFIX
server from specific IP addresses. <br>
<br>
Ajay Kamdar wrote:
<blockquote
 cite="mid...@us..."
 type="cite">
  <title>Message</title>
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2802" name="GENERATOR">
  <style></style>
  <div><span class="665130416-17052006"><font color="#0000ff"
 face="Arial" size="2">How can QuickFIX be made to accept connection
attempts only from specific IP addresses and IP address range? The
allowed IP addresses and IP address range could be different for each
Session defined in the config file.</font></span></div>
  <div><span class="665130416-17052006"></span>&nbsp;</div>
  <div><span class="665130416-17052006"><font color="#0000ff"
 face="Arial" size="2">Restricting the incoming FIX sessions to
specific IPs would I suppose be a common requirement for production
configurations. Am I missing some obvious configuration parameters to
make this happen? Or do the core QuickFIX acceptor classes have to be
modified for this to happen?</font></span></div>
  <div><span class="665130416-17052006"></span>&nbsp;</div>
  <div><span class="665130416-17052006"><font color="#0000ff"
 face="Arial" size="2">Thanks,</font></span></div>
  <div><span class="665130416-17052006"></span>&nbsp;</div>
  <div><span class="665130416-17052006"><font color="#0000ff"
 face="Arial" size="2">- Ajay</font></span></div>
  <p><br>
________________________________________________________________________<br>
  <br>
The information in this email is confidential and may be legally
privileged.<br>
It is intended solely for the addressee. Access to this email by anyone
else<br>
is unauthorized. If you are not the intended recipient, any disclosure,
copying,<br>
distribution or any action taken or omitted to be taken in reliance on
it, is<br>
prohibited and may be unlawful.<br>
  <br>
TradeWeb reserves the right to monitor and review the content of all
messages sent<br>
to or from this e-mail address. Messages sent to or from this e-mail
address may<br>
be stored on the TradeWeb e-mail system.<br>
  </p>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<strong><span style="color: rgb(0, 0, 0);">Zoran Cetusic</span></strong><span
 style=""> </span><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);">| </span><span
 style="font-size: 7.5pt; color: blue;">President &amp; CEO</span><br>
<div class="moz-signature"><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);"><strong>phone</strong>
+1.858.218.4496 | <strong>fax</strong>
+1.858.675.4504</span><span style=""><o:p></o:p></span><br>
<strong><span style="font-size: 7.5pt; color: rgb(102, 102, 102);">email:</span></strong><span
 style="font-size: 7.5pt; color: rgb(102, 102, 102);"> <a
 href="mailto:zo...@av..."
 title="mailto:zo...@av...
zo...@av..."><span
 title="mailto:zo...@av...">zo...@av...</span></a><strong>
|
web </strong> <a href="http://www.avalonsoft.com/"
 title="http://www.avalonsoft.com">www.avalonsoft.com</a></span></div>
</div>
</body>
</html>

[Quickfix-developers] Restricting acceptor to specific IP address(es)

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

How can QuickFIX be made to accept connection attempts only from
specific IP addresses and IP address range? The allowed IP addresses and
IP address range could be different for each Session defined in the
config file.
=20
Restricting the incoming FIX sessions to specific IPs would I suppose be
a common requirement for production configurations. Am I missing some
obvious configuration parameters to make this happen? Or do the core
QuickFIX acceptor classes have to be modified for this to happen?
=20
Thanks,
=20
- Ajay

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

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.

[Quickfix-developers] Nik Volpe is out of the office.

[Nick V. <ni...@ad...>]

I will be out of the office starting  17/05/2006 and will not return until
02/06/2006.

I will have limited access to email so will respond to your message when I
return.  However, for urgent matters, please contact me on 050 592 8047.

Thanks.


**************************************************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any  unauthorized use of the information contained
in this email or its attachments is prohibited.  If this email is received in
error, please contact the sender and delete the material from your
computer systems. Do not use, copy, or disclose the contents of this
email or any attachments.
Abu Dhabi Investment Authority (ADIA) accepts no responsibility for
the content of this email to the extent that the same consists of
statements and opinions made which are the senders own and not
made on behalf of ADIA.  Nor does ADIA accept any liability for any
errors or omissions in the content of this email caused by electronic
and technical failures.
Although ADIA has taken reasonable precautions to ensure that no
viruses are present in this email, ADIA accepts no responsibility for
any loss or damage arising from the use of this email or its
attachments.
**************************************************************************************************************

[Quickfix-developers] Re: isLoggedOn()

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

Yes, isLoggedOn will return false if the session is disconnected for  
any reason.  See the disconnect() method.

--oren

On May 16, 2006, at 11:47 AM, Shawn Yarbrough wrote:

> Does isLoggedOn properly reflect a "Socket Error: Connection reset  
> by peer" error that I'm seeing in my QuickFIX log today?  From the  
> QuickFIX source it looks as if isLoggedOn only tells you if logon  
> messages were sent and received.
>
> Does isLoggedOn become false after a successful logon followed by  
> the reset socket error?  I need to detect the error somehow.
>
>
> Shawn Yarbrough
>

[Quickfix-developers] isLoggedOn()

[Shawn Y. <sya...@ge...>]

Does isLoggedOn properly reflect a "Socket Error: Connection reset by =
peer" error that I'm seeing in my QuickFIX log today?  From the QuickFIX =
source it looks as if isLoggedOn only tells you if logon messages were =
sent and received.

Does isLoggedOn become false after a successful logon followed by the =
reset socket error?  I need to detect the error somehow.


Shawn Yarbrough

Re: [Quickfix-developers] Minor glitch in build.xml for quickfixj

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

The CVS problems have been fixed.  Sourceforge upgraded their servers  
last friday.  The addresses have changed however, now you need to  
use:  :pserver:ano...@qu...:/cvsroot/quickfix

--oren

On May 15, 2006, at 8:47 AM, Staffan Ulfberg wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> "Steve Bate" <sb...@sm...> writes:
>
>> Thanks Staffan. This has already been changed on the CVS HEAD.
>> The MINA-related packages have also been added and Netty has been
>> removed.
>
> So, where's the CVS repository really?  I'm using a checkout from
> :pserver:ano...@cv...:/cvsroot/quickfix, updated
> recently.
>
> Someone wrote something about updates to the repository being flaky.
> I've also read about moving to SVN.  How would I currently obtain the
> latest version before submittning patches?
>
> Staffan
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] A small request

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

Indeed, I've played around with this some.  There is even a ruby =20
directory in the repository: http://quickfix.cvs.sourceforge.net/=20
quickfix/quickfix/src/ruby/

There are essentially two things that need to be done.  First we need =20=

a director:except implementation for ruby, like the current one for =20
python.  Second, we need a Ruby generator for creating messages and =20
groups.  Everything else should be taken care of by swig.

--oren

Second we need a
On May 14, 2006, at 7:18 PM, Graham Miller wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> So I'm going to try to say this in a way that doesn't start a
> Ruby/Java holy war, but...  is there any interest in a Ruby API for
> quickfix?  It seems that it would be relatively straightforward to
> modify the existing Python SWIG specification to generate an interface
> for Ruby.  I may be totally wrong, because I've never built a SWIG
> interface before, but I just thought I'd suggest it, because we were
> going to start playing with RoR for a project soon...
>
> graham
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Logging messages conditionally

[Staffan U. <sta...@mu...>]

> > I'd like to _not_ log certain messages to the messages_log table.
> > Specifically, market data information is not important enough to
> > warrant the required storage space, and I would like not to store sent
> > messages in the log.
> >
> > Is there an easy way to do this?
> 
> You could derive your own Log class from whichever Log you're
> currently using and have it do nothing when it sees the message types
> you want to ignore in the onIncoming/onOutgoing methods.  For more
> interesting messages, call the base class method.
> 
> You'll need to do a string search (e.g. for "\00135=<X>\001") since
> the Logs are passed strings, not Message objects.

The string search requirement is a bit unfortunate, or at least ugly.
A bigger problem is that the JdbcLog class is not public, but maybe
this is just a bug and not by design?  (I see that FileLog is indeed
public).

Staffan

[Quickfix-developers] Compile error in Exceptions.h

[Mike S. <MS...@rj...>]

I'm currently writing a Session Acceptor program in Visual Studio 2005
C++.  I wanted to create a custom message type to pass back to the
initiator.  So, what I did was...

1.  Create a TraderLogon.h file under quickfix_vs8->Message->Message
Header->fix42.
2.  Update MessageCracker.h under the same directory structure.
3.  Updated Values.h under Field Header Files directory.

I then compiled quickfix_vs8 and everything was fine.

I then went to compile my acceptor application and got the following
error.

Error	1	error C2664: 'FormatMessage' : cannot convert parameter
5 from 'char [2048]' to 'LPTSTR'
c:\source\quickfix\quickfix\include\quickfix\Exceptions.h	247=09

I couldn't figure out how to get past this, so I backed out all my
changes and recompiled quickfix_vs8.  I then recompiled my acceptor
application, but I still get the same error.

I know this is pretty obscure, but does anyone know how I might get past
this?

Thanks,

Mike