quickfix-developers — QuickFIX developers forum

[Quickfix-developers] SocketConnection session registration BUG

[Sean K. <Sea...@Pi...>]

I have added proprietary logging to the quickfix library to help debug
an issue we have been having with a client not being able to log in.
We could see the logon message coming across via tethereal, but were
unable to determine the reason why the socket was being dropped. =20

The following logs expose where the logic error in quickfix occurs:

09:00:20.452 {QF::SocketMonitor::block} Socket [393] has data
09:00:20.452 {QF::ServerWrapper::onEvent} data found on socket [393]
09:00:20.452 {QF::SocketAcceptor::onData} getting SocketConnection [393]
09:00:20.452 {QF::SocketAcceptor::onData} found SocketConnection [393]
09:00:20.452 {QF::SocketConnection::read} reading message
09:00:20.452 {QF::Parser::readFromStream} socket_fionread returned [72] =
bytes
09:00:20.452 {QF::Parser::readFromStream} recv [72] bytes on socket =
[393]
09:00:20.452 {QF::Parser::readFixMessage} found BeginString tag 8
09:00:20.452 {QF::Parser::readFixMessage} found CheckSum tag 10
09:00:20.452 {QF::Parser::readFixMessage} found final SOH char
09:00:20.452 {QF::Parser::readFixMessage} message =
[8=3DFIX.4.0^A9=3D50^A35=3D0^A49=3DSEND^A56=3DRECV
^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
09:00:20.452 {QF::SocketConnection::read} looking for session based on =
[8=3DFIX.4.0^A9=3D50^A35=3D0
^A49=3DSEND^A56=3DRECV^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
09:00:20.452 {QF::Session::lookupSession} Looking for session: =
[FIX.4.0:RECV->SEND]
09:00:20.452 {QF::Session::lookupSession} FOUND IT!
09:00:20.452 {QF::SocketConnection::read} registering session =
[FIX.4.0:RECV->SEND]
09:00:20.453 {QF::Session::lookupSession} Looking for session: =
[FIX.4.0:RECV->SEND]
09:00:20.453 {QF::Session::lookupSession} FOUND IT!
09:00:20.453 {QF::Session::registerSession} found session =
[FIX.4.0:RECV->SEND]
09:00:20.453 {QF::Session::registerSession} registering session
----
09:00:20.453 {QF::SocketConnection::read} getting SocketAcceptor session =
[8=3DFIX.4.0^A9=3D50^A35
=3D0^A49=3DSEND^A56=3DRECV^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
09:00:20.453 {QF::Acceptor::getSession} msgType [0] not valid
09:00:20.453 {QF::SocketConnection::read} Dropping socket connection
09:00:20.453 {QF::SocketConnection::read} reading message
09:00:20.453 {QF::Parser::readFromStream} socket_fionread failed
09:00:20.453 {QF::SocketMonitor::block} queue has sockets to drop
09:00:20.453 {QF::SocketAcceptor::onDisconnect} Disconnecting socket: =
[393]
09:00:20.453 {QF::SocketConnection::~SocketConnection} destroying =
SocketConnection

The problem occurs between the "----" separated log lines.  The library
registers the session, but then attempts to validate that the recvd =
message
is a logon.  If it is not, the function return NULL as the m_pSession
variable.  The next section of the SocketConnection read checks for a =
valid
m_pSession.  If the session is NULL, the socket is dropped.  When the
SocketConnection is destroyed, it's m_pSession is still NULL, and the =
object
is never unregistered.  Subsequent attempts to connect to this session =
log
the following:

09:04:26.744 {QF::SocketMonitor::block} Socket [393] has data
09:04:26.744 {QF::ServerWrapper::onEvent} data found on socket [393]
09:04:26.744 {QF::SocketAcceptor::onData} getting SocketConnection [393]
09:04:26.744 {QF::SocketAcceptor::onData} found SocketConnection [393]
09:04:26.744 {QF::SocketConnection::read} reading message
09:04:26.744 {QF::Parser::readFromStream} socket_fionread returned [84] =
bytes
09:04:26.744 {QF::Parser::readFromStream} recv [84] bytes on socket =
[393]
09:04:26.745 {QF::Parser::readFixMessage} found BeginString tag 8
09:04:26.745 {QF::Parser::readFixMessage} found CheckSum tag 10
09:04:26.745 {QF::Parser::readFixMessage} found final SOH char
09:04:26.745 {QF::Parser::readFixMessage} message =
[8=3DFIX.4.0^A9=3D62^A35=3DA^A49=3DSEND^A56=3DRECV
^A34=3D3^A52=3D20050627-13:04:26^A98=3D0^A108=3D20^A10=3D112^A]
09:04:26.745 {QF::SocketConnection::read} looking for session based on =
[8=3DFIX.4.0^A9=3D62^A35=3DA
^A49=3DSEND^A56=3DRECV^A34=3D3^A52=3D20050627-13:04:26^A98=3D0^A108=3D20^=
A10=3D112^A]
09:04:26.745 {QF::Session::lookupSession} Looking for session: =
[FIX.4.0:RECV->SEND]
09:04:26.745 {QF::Session::lookupSession} FOUND IT!
09:04:26.745 {QF::SocketConnection::read} registering session =
[FIX.4.0:RECV->SEND]
09:04:26.745 {QF::Session::lookupSession} Looking for session: =
[FIX.4.0:RECV->SEND]
09:04:26.745 {QF::Session::lookupSession} FOUND IT!
09:04:26.745 {QF::Session::registerSession} found session =
[FIX.4.0:RECV->SEND]
----
09:04:26.745 {QF::SocketConnection::read} Dropping socket connection
09:04:26.745 {QF::SocketConnection::read} reading message
09:04:26.745 {QF::Parser::readFromStream} socket_fionread failed
09:04:26.745 {QF::SocketMonitor::block} queue has sockets to drop
09:04:26.745 {QF::SocketAcceptor::onDisconnect} Disconnecting socket: =
[393]
09:04:26.745 {QF::SocketConnection::~SocketConnection} destroying =
SocketConnection

In between the "----" separated log lines, the session is detected as =
already
registered and the m_pSession member is again set to NULL and the socket =
is
dropped.

I believe that there is a very simple fix that will correct this issue.  =
The
order of the following code in SocketConnection::read (the LOGDEBUG =
lines are
for the logging I added):

  if ( m_pSession ) {
    LOGDEBUG(funcname,"registering session =
[%s]",m_pSession->getSessionID().toString().c_str());
    m_pSession =3D Session::registerSession( m_pSession->getSessionID() =
);
  }

  if ( m_pSession ) {
    LOGDEBUG(funcname,"getting SocketAcceptor session =
[%s]",msg.c_str());
    m_pSession =3D a.getSession( msg, *this );
  }

needs to be reversed to be:

  if ( m_pSession ) {
    LOGDEBUG(funcname,"getting SocketAcceptor session =
[%s]",msg.c_str());
    m_pSession =3D a.getSession( msg, *this );
  }

  if ( m_pSession ) {
    LOGDEBUG(funcname,"registering session =
[%s]",m_pSession->getSessionID().toString().c_str());
    m_pSession =3D Session::registerSession( m_pSession->getSessionID() =
);
  }

If this is the case, any invalid initial messages will invalidate the
m_pSession member prior to attempting to register the session.  Only =
valid
connections will be registered, and the disconnect logic works fine so
long as the registration is done properly.  A week of development was =
lost
due to the lack of engine-level logging in the quickfix library, and I
know that this is an issue that has been raised several times in the =
past.

Please provide feedback.

--Sean

[Quickfix-developers] QuickFIXEngine user experience

[Barry M. <bar...@ya...>]

I'm currently considering using the QuickFIXEngine
(www.quickfixengine.org) and I'm looking for information
from users who have had actual experience with it.
The particular areas of interest are

 - platform used on,
       i.e., Windows, Linux, Solaris, FreeeBSD, MacOS, mainframe
 - reliability
 - performance

Any information you can provide will be much appreciated.

Thanks,
Barry

Barry Marks
Logicware, Inc.
Northbrook, IL
bar...@ya...

[Quickfix-developers] communication mappings

[Sean K. <Sea...@Pi...>]

I am trudging through the communication code of the library...is
there a direct mapping created for CompID and src Ip?

We just upgraded to 1.9.4 recently and have not experienced these
problems before.  We are currently experiencing two different,
possibly related issues:

1. A 4.0 client disconnects and cannot reconnect to the session.
I cannot connect to the session from a different source either
until the engine is restarted.  This seems like the socket isn't
actually closed somehow, but I do see the connection disappear
via netstat.

2. A client is configured with two sessions.  They establish a
connection to the first session and can disconnect and reconnect
to that session.  They cannot, however, connect to the second
session at all.  Both connections are attempted from the same
src ip.

Any ideas?

--Sean

[Quickfix-developers] Establishing a connection

[Daniel O'B. <do...@st...>]

Hi,

=20

I am trying to establish a fix connection, but don't know when the fix
engine actually attempts to make the connection.  Is this meant to
happen on construction of a SocketInitiator, or when start() is called
on the SocketInitiator, or at some other time?

=20

Having constructed and started a SocketInitiator are you meant to
construct a Logon message to then send?

=20

Any help much appreciated, thanks,

=20

Dan

=20

Re: [Quickfix-developers] How to add support for custom messages and custom signature to QuickFix?

[Reiner N. <rei...@ma...>]

Hi,

> If you want to generate all the classes, you will need to run the
> generation scripts in the 'spec' directory.

Is there a file to register the used specs?
Or do I need to run the generation scripts manually instead of just rebuild 
the whole stuff?


> I don't believe there is a mehod for retrieving just the body fields.  In
> C++ this would be possible if you cast the Message to a FieldMap, but this
> isn't an option in java.  A getBody method would probably be a good
> compliment to getHeader and getTrailer.  What you can do however is iterate
> through all the fields and call toString on them one by one.  If you append
> each of the fields to a StringBuffer you should be able to reconstruct the
> body of the message.

Is there a method to check wether a field is a header, trailor or body field?

> Where you add the field is a function of what you know, when you know it,
> and how generally applicable it is.  In general, if you have a field that
> you want to make sure gets appended to every outgoing message, you should
> put it in the toApp method.  If you have a field that is specific to one
> type of message, it would make more sense to append it at the same place
> you construct that message.
Thanks. This sounds good.

Many thanks for the hints
Reiner Nix

> --oren
>
> ----- Original Message -----
> From: "Reiner Nix" <rei...@ma...>
> To: <qui...@li...>
> Sent: Wednesday, June 22, 2005 7:58 AM
> Subject: [Quickfix-developers] How to add support for custom messages and
> custom signature to QuickFix?
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi,
> >
> > I need to extend QuickFix to support custom messages. As a first step a
> > new an
> > additional data dictionary was created. Now QuickFix must be build again
> > to
> > generate the code according the additional data dictionary.
> > What is the correct way to build QuickFix to support this data
> > dictionary?
> >
> >
> > I also need to add a custom defined tag containing a digital signature to
> > a
> > FIX message. To do this, I need to retrieve the body in FIX notation of a
> > message where almost all fields are populated. After calculating the
> > signature the message must be extended with the custom field containing
> > the
> > signature and then the message can be sent.
> >
> > My questions:
> > How can I retrieve the message body in FIX notation? I do not need the
> > header
> > nor the trailer but only the body for the calculation.
> >
> > What is the best way to add the custom field?
> > Using Java, I guess the methods Application.toApp or before calling
> > Session.sendToTarget can be used. Is there a recommendation whether to
> > use toApp or before calling sendToTarget.
> >
> > Cheers
> > Reiner
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers

-- 
Reiner B. Nix		       IT-Architect
rei...@ma...	       http://www.macd.com
Tel.: +49 (0)241 44597-23      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] ExecType

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

Brian Erst wrote:
> OrdStatus (39) and ExecType (150) have generally used the same code
> values, but for somewhat different reasons. OrdStatus gave you the
> current status of the order, while ExecType told you how this
> particular ExecutionReport affected the order.
> 
> Starting with FIX 4.4, they made Trade Correct (G) and Trade Cancel (H)
> new ExecType codes (they were previously indicated by ExecTransType
> codes):

IMHO, the FIX 4.4 has simplified things a lot:

	ExecType=(Partially)Filled, ExecTransType=NEW     --> ExecType=Trade
	ExecType=(Partially)Filled, ExecTransType=CORRECT --> ExecType=TradeCorrect
	ExecType=(Partially)Filled, ExecTransType=NEW     --> ExecType=TradeCancel

The separation of order status and execution type is clear now.

> It never really made much sense to have Partial Fill (1) and
> Filled (2) codes for ExecType - these are really order statuses - so
> they created a new ExecType Trade (F) to have a nice, orthogonal set of
> ExecTypes. Trade, Trade Correct and Trade Cancel are now all single
> codes that are defined in order.
> 
> I believe Partial Fill and Filled are now used only as OrdStatus values
> as of FIX 4.4.

Yes, in the ExecType both are marked as "Replaced." Actually, FIX 4.4 compliant parties 
should not use them any longer.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] How to add support for custom messages and custom signature to QuickFix?

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

Thanks, Oren!

> If you want to generate all the classes, you will need to run the 
> generation scripts in the 'spec' directory.

IMHO, it would be a good idea if we could separate the QF engine and the FIX classes 
completely, ie have a engine package and a package (library, dll, jar) for each FIX 
4.0-4.4. The generation scripts could be part of the engine package and generate the FIX 
message package out of the data dictionary. In the end, you would have (for C++):

	libquickfix.so + libquickfix_fix42.so etc.

Correspondingly for the other APIs.

This make the handling of custom messages or fields much easier: The user just takes the 
basic QF engine, sets up its own data dictionary and generates/builds the message package.

What do you think?

> I don't believe there is a mehod for retrieving just the body fields.  
> In C++ this would be possible if you cast the Message to a FieldMap, but 
> this isn't an option in java.  A getBody method would probably be a good 
> compliment to getHeader and getTrailer.  What you can do however is 
> iterate through all the fields and call toString on them one by one.  If 
> you append each of the fields to a StringBuffer you should be able to 
> reconstruct the body of the message.

Yes, browsing the source code I saw this could be an option, but did not check in detail.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] How to check for dropped socket

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

Assuming the counterparty is functioning correctly, yes.  When you send =
a logon, the counterparty would detect a message gap and initiate a =
resend request.  That would cause your engine to resend that message, =
giving you the opportunity to kill it in the toApp callback.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 5:13 AM
  Subject: Re: [Quickfix-developers] How to check for dropped socket

  One more question that I just want your clarification. If I send a =
message when the session is down, does QF guarantee that it will =
automatically push the message out next time QF re-logons? 

Re: [Quickfix-developers] How to check for dropped socket

[Alvin W. <AW...@FF...>]

Oren,

thanks for your explanations. That makes more sense. 

One more question that I just want your clarification. If I send a message 
when the session is down, does QF guarantee that it will automatically 
push the message out next time QF re-logons? 

Thanks again
Alvin






"Oren Miller" <or...@qu...>
06/23/2005 04:04 PM

 
        To:     "Alvin Wang" <AW...@FF...>
        cc:     "Francis Gingras" <fr...@at...>, 
<qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] How to check for dropped socket


Well, if you only want to attempt to send when logged on, then you will 
probably just want to verify that the session is logged on before sending. 
 Very often sending on a logged off session is standard operating 
procedure and not really an exceptional case.  For instance if I'm 
implementing a server that is intended to send drop copies of executions, 
I'm not going to care whether the counterparty is logged on or not.  I 
just need to get them a copy of this execution and just need to know that 
QF will get it out there whenever it can.  If QuickFIX would consider this 
an exceptional case it would seem pretty odd.
 
FIX isn't transactional so I can never really expect to know that my 
message has been delivered.  Sure, we can sometimes know the negative case 
and prove that a message has not been delivered, but I can never know the 
positive case.  If the socket call is succesful, can I assume that the 
message was sent succesfully?  Not really.  The socket call was 
succesfull, but I have no validation that the message actually made it 
into the opposing FIX engine and trading sub-systems.  (An ExecutionReport 
can sort of tell me this.  But that is an acknowledgement that isn't 
defined at the session level and specific to just one type of message).
 
So what option do you have instead?  Well, you basically have to decide 
what your tolerance for latency is.  This is where the toApp callback 
comes into play.  Everything that QF tries to send passes through this 
callback first.  One of the fields you can check is the value of the 
SendingTime.
 
When the message passes through the first time, your current system time 
and your SendingTime should be the same or really damn close.  Good 
enough, let it through.  Now let's say that 300 milliseconds later it 
turns out the message never made it and you get a resend request.  What do 
you do?  Do you let it through or do you throw a DoNotSend exception 
because it's too late?  "Ahhhh." you say.  "The market hasn't changed and 
not so much time has passed, let's let it through!".  Again.  2 seconds 
later, you get the request again.  At this point you figure the order is 
not worthwhile sending anymore, you throw a DoNotSend exception, and you 
let the application know that you are killing the order.
 
So since FIX isn't transactional, you really need to think more about what 
your tolerance is for latency/shifting markets.  Make sense?
 
--oren
 
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: Francis Gingras ; qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:56 AM
Subject: Re: [Quickfix-developers] How to check for dropped socket


I mean not logged on, but enabled. 




"Oren Miller" <or...@qu...> 
06/23/2005 03:40 PM 
        
        To:        "Alvin Wang" <AW...@FF...> 
        cc:        "Francis Gingras" <fr...@at...>, <qui...@li...>, <qui...@li...> 
        bcc:         
        Subject:        Re: [Quickfix-developers] How to check for dropped 
socket



By "off" do you mean logged out or disabled? 
  
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: Francis Gingras ; qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:50 AM 
Subject: Re: [Quickfix-developers] How to check for dropped socket 


Oren, 

Do you mean that if the session is off, the message will only be stored 
locally and the seq number will be increased? Next time the session is 
created, the counterparty will figure out the seq # does not match and 
therefore will ask for resend. 

If that is the case, that  makes sense. However, I feel not comfortable 
assuming the message has been pushed out without any warning or exception. 
Should program be notified if it tries to send a message when the session 
is off? 

Thanks 
Alvin' 





"Oren Miller" <or...@qu...> 
06/23/2005 03:19 PM 
        
       To:        "Francis Gingras" <fr...@at...>, "Alvin Wang" <AW...@FF...> 
       cc:        <qui...@li...>, 
<qui...@li...> 
       bcc:         
       Subject:        Re: [Quickfix-developers] How to check for dropped 
socket




And you never will know.  FIX is an asynchronous protocol.  There is no 
way for it to indicate the succesful receipt of a message.  That is why 
the sequence numbers are necessary.  Your SendToTarget is returning true 
because QuickFIX was able to store your message and take responsibility 
for sending it.  It may not be able to send it right away, but it will do 
so when required by a ResendRequest. 
 
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Francis Gingras 
Cc: qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:20 AM 
Subject: Re: [Quickfix-developers] How to check for dropped socket 


A related question: 

It seems that I can use the static method Session.sendToTarget(Message, SessionID) successfully even when the corresponding session is not logged on. (I am 
not sure if the counterparty really receives the message in this case) 

thanks 
Alvin 



Francis Gingras <fr...@at...> 
Sent by: qui...@li... 
06/23/2005 02:58 PM 
        
      To:        qui...@li... 
      cc:         
      bcc:         
      Subject:        [Quickfix-developers] How to check for dropped 
socket





QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I am using the initiator and I'd like to know how I can check if the 
socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

RE: [Quickfix-developers] logon problem

[Sean K. <Sea...@Pi...>]

There was a hard failure on the client side (no logout message was sent,
so the connection was just dropped).  I've been investigating further =
and
it seems like the socket was not shut down properly.  I was able to
recreate this behavior by logging on to a session (establishing the=20
socket connection) and then attempting to log in to the same session =
with
another client app.  The second app gets dropped immediately.

--Sean

-----Original Message-----
From: Alvin Wang [mailto:AW...@FF...]
Sent: Friday, June 24, 2005 4:17 AM
To: Sean Kirkpatrick
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-developers] logon problem



Sean,=20

Are you saying that you got a Logout from counterparty but QF did not =
log it anywhere? I think I saw it also.=20

Alvin=20



"Sean Kirkpatrick" <Sea...@Pi...>=20
Sent by: qui...@li...=20
06/23/2005 02:47 PM=20
       =20
        To:        <qui...@li...>=20
        cc:        =20
        bcc:        =20
        Subject:        [Quickfix-developers] logon problem



QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: =
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hello All,

I've encountered a bizarre logon problem (1.9.4).  A session was logged
in and functioning normally (heartbeats, new orders, exec rpts, etc). =20
The connection was then brought down without logging off.  I increased
the seq number to test the sequence reset functionality, but now the =
server
doesn't even see the logon request.  I was able to verify that the =
message
is coming across using a packet sniffer, but quickfix is not logging
anything to any of the session logs (incoming, outgoing, event).  On the
initiator, all I see is:

20050623-18:36:19 : Connecting to host on port #
20050623-18:36:19 : Connection succeeded
20050623-18:36:19 : Initiated logon request
20050623-18:36:19 : Dropped Connection

I've checked to ensure that the Comp IDs are correct as well as the FIX
version.  I am able to log in and use other sessions normally from the =
same
test app.  Is there anything that might cause an individual session to
become mangled?

Thanks,
Sean


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

Re: [Quickfix-developers] How to check for dropped socket

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

On 6/24/05, Alvin Wang <AW...@ff...> wrote:
> If that is the case, that  makes sense. However, I feel not comfortable
> assuming the message has been pushed out without any warning or exception=
.
> Should program be notified if it tries to send a message when the session=
 is
> off?=20

Alvin: please limit the amount of quoted material in your messages.=20
There's no need to include several messages verbatim in your postings.
 Include just the relevant portion(s).

I for one rely on this behavior and would be very upset if
Session::sendToTarget started throwing on unconnected sessions.


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

Re: [Quickfix-developers] How to check for dropped socket

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

  Well, if you only want to attempt to send when logged on, then you =
will probably just want to verify that the session is logged on before =
sending.  Very often sending on a logged off session is standard =
operating procedure and not really an exceptional case.  For instance if =
I'm implementing a server that is intended to send drop copies of =
executions, I'm not going to care whether the counterparty is logged on =
or not.  I just need to get them a copy of this execution and just need =
to know that QF will get it out there whenever it can.  If QuickFIX =
would consider this an exceptional case it would seem pretty odd.

  FIX isn't transactional so I can never really expect to know that my =
message has been delivered.  Sure, we can sometimes know the negative =
case and prove that a message has not been delivered, but I can never =
know the positive case.  If the socket call is succesful, can I assume =
that the message was sent succesfully?  Not really.  The socket call was =
succesfull, but I have no validation that the message actually made it =
into the opposing FIX engine and trading sub-systems.  (An =
ExecutionReport can sort of tell me this.  But that is an =
acknowledgement that isn't defined at the session level and specific to =
just one type of message).

  So what option do you have instead?  Well, you basically have to =
decide what your tolerance for latency is.  This is where the toApp =
callback comes into play.  Everything that QF tries to send passes =
through this callback first.  One of the fields you can check is the =
value of the SendingTime.

  When the message passes through the first time, your current system =
time and your SendingTime should be the same or really damn close.  Good =
enough, let it through.  Now let's say that 300 milliseconds later it =
turns out the message never made it and you get a resend request.  What =
do you do?  Do you let it through or do you throw a DoNotSend exception =
because it's too late?  "Ahhhh." you say.  "The market hasn't changed =
and not so much time has passed, let's let it through!".  Again.  2 =
seconds later, you get the request again.  At this point you figure the =
order is not worthwhile sending anymore, you throw a DoNotSend =
exception, and you let the application know that you are killing the =
order.

  So since FIX isn't transactional, you really need to think more about =
what your tolerance is for latency/shifting markets.  Make sense?

  --oren

  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:56 AM
  Subject: Re: [Quickfix-developers] How to check for dropped socket



  I mean not logged on, but enabled.=20



       "Oren Miller" <or...@qu...>=20
        06/23/2005 03:40 PM=20

              =20
                To:        "Alvin Wang" <AW...@FF...>=20
                cc:        "Francis Gingras" <fr...@at...>, =
<qui...@li...>, =
<qui...@li...>=20
                bcc:        =20
                Subject:        Re: [Quickfix-developers] How to check =
for dropped socket=20



  By "off" do you mean logged out or disabled?=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:50 AM=20
  Subject: Re: [Quickfix-developers] How to check for dropped socket=20


  Oren,=20

  Do you mean that if the session is off, the message will only be =
stored locally and the seq number will be increased? Next time the =
session is created, the counterparty will figure out the seq # does not =
match and therefore will ask for resend.=20

  If that is the case, that  makes sense. However, I feel not =
comfortable assuming the message has been pushed out without any warning =
or exception. Should program be notified if it tries to send a message =
when the session is off?=20

  Thanks=20
  Alvin'=20




       "Oren Miller" <or...@qu...>=20
        06/23/2005 03:19 PM=20
              =20
               To:        "Francis Gingras" <fr...@at...>, =
"Alvin Wang" <AW...@FF...>=20
               cc:        <qui...@li...>, =
<qui...@li...>=20
               bcc:        =20
               Subject:        Re: [Quickfix-developers] How to check =
for dropped socket=20




  And you never will know.  FIX is an asynchronous protocol.  There is =
no way for it to indicate the succesful receipt of a message.  That is =
why the sequence numbers are necessary.  Your SendToTarget is returning =
true because QuickFIX was able to store your message and take =
responsibility for sending it.  It may not be able to send it right =
away, but it will do so when required by a ResendRequest.=20
  =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Francis Gingras=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:20 AM=20
  Subject: Re: [Quickfix-developers] How to check for dropped socket=20


  A related question:=20

  It seems that I can use the static method =
Session.sendToTarget(Message, SessionID) successfully even when the =
corresponding session is not logged on. (I am not sure if the =
counterparty really receives the message in this case)=20

  thanks=20
  Alvin=20


       Francis Gingras <fr...@at...>=20
        Sent by: qui...@li...=20
        06/23/2005 02:58 PM=20
              =20
              To:        qui...@li...=20
              cc:        =20
              bcc:        =20
              Subject:        [Quickfix-developers] How to check for =
dropped socket=20





  QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
  QuickFIX FAQ: =
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
  QuickFIX Support: http://www.quickfixengine.org/services.html

  I am using the initiator and I'd like to know how I can check if the =
socket
  was dropped. (i.e. if the connection was shut down by the acceptor =
side)

  I figure I can use these properties but I'm not 100% sure what they =
mean:

  session.isEnabled()
  If the session exists, how can it not be enabled?

  session.isLoggedOn()
  socket.isLoggedOn()
  Are they always the same and do they mean the same thing?

  Thanks,

  Francis Gingras



  -------------------------------------------------------
  SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
  from IBM. Find simple to follow Roadmaps, straightforward articles,
  informative Webcasts and more! Get everything you need to get up to
  speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
  _______________________________________________
  Quickfix-developers mailing list
  Qui...@li...
  https://lists.sourceforge.net/lists/listinfo/quickfix-developers


  ********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

Re: [Quickfix-developers] How to check for dropped socket

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

Session::isLoggedOn will return true if that particular session is logged 
on.  ThreadedSocketInitiator will return true if any of the sessions it is 
managing is logged on.  So if your ThreadedSocketInitiator is managing 5 
sessions, if any one is logged on it will return true, and will return false 
only if none of them is logged on.  It is basically a for loop that calls 
Session::isLoggedOn for on all of the Session objects.

--oren

----- Original Message ----- 
From: "Francis Gingras" <fr...@at...>
To: <qui...@li...>; "'Oren Miller'" 
<or...@qu...>
Sent: Thursday, June 23, 2005 2:39 PM
Subject: RE: [Quickfix-developers] How to check for dropped socket


> Oren,
>
> I work in C# and socket is of type QuickFix.ThreadedSocketInitiator. I use
> socket.start() to initiate a session.
>
> So are Session::isLoggedOn and socket.isLoggedOn one and the same?
>
> Thanks,
>
> Francis
>
> -----Original Message-----
> From: Oren Miller
> Sent: Thursday, June 23, 2005 15:28
> To: Francis Gingras; qui...@li...
> Subject: Re: [Quickfix-developers] How to check for dropped socket
>
> A session always exists, but it can be disabled if you do not wish for it 
> to
> logon and process messages.  Keep in mind these are FIX sessions, not 
> socket
> sessions.  They exist outside of the scope of a socket connection.
>
> Session::isLoggedOn indicates whether the sessions has sucesfully 
> exchanged
> logon messages with the counterparty.  I'm not sure what you are refering 
> to
> with "socket.isLoggedOn()".
>
> --oren
>
> 

Re: [Quickfix-developers] How to check for dropped socket

[Alvin W. <AW...@FF...>]

I mean not logged on, but enabled.





"Oren Miller" <or...@qu...>
06/23/2005 03:40 PM

 
        To:     "Alvin Wang" <AW...@FF...>
        cc:     "Francis Gingras" <fr...@at...>, 
<qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] How to check for dropped socket


By "off" do you mean logged out or disabled?
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: Francis Gingras ; qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:50 AM
Subject: Re: [Quickfix-developers] How to check for dropped socket


Oren, 

Do you mean that if the session is off, the message will only be stored 
locally and the seq number will be increased? Next time the session is 
created, the counterparty will figure out the seq # does not match and 
therefore will ask for resend. 

If that is the case, that  makes sense. However, I feel not comfortable 
assuming the message has been pushed out without any warning or exception. 
Should program be notified if it tries to send a message when the session 
is off? 

Thanks 
Alvin' 






"Oren Miller" <or...@qu...> 
06/23/2005 03:19 PM 
        
        To:        "Francis Gingras" <fr...@at...>, "Alvin Wang" <AW...@FF...> 
        cc:        <qui...@li...>, 
<qui...@li...> 
        bcc:         
        Subject:        Re: [Quickfix-developers] How to check for dropped 
socket



And you never will know.  FIX is an asynchronous protocol.  There is no 
way for it to indicate the succesful receipt of a message.  That is why 
the sequence numbers are necessary.  Your SendToTarget is returning true 
because QuickFIX was able to store your message and take responsibility 
for sending it.  It may not be able to send it right away, but it will do 
so when required by a ResendRequest. 
  
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Francis Gingras 
Cc: qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:20 AM 
Subject: Re: [Quickfix-developers] How to check for dropped socket 


A related question: 

It seems that I can use the static method Session.sendToTarget(Message, SessionID) successfully even when the corresponding session is not logged on. (I am 
not sure if the counterparty really receives the message in this case) 

thanks 
Alvin 




Francis Gingras <fr...@at...> 
Sent by: qui...@li... 
06/23/2005 02:58 PM 
        
       To:        qui...@li... 
       cc:         
       bcc:         
       Subject:        [Quickfix-developers] How to check for dropped 
socket




QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I am using the initiator and I'd like to know how I can check if the 
socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

RE: [Quickfix-developers] How to check for dropped socket

[Francis G. <fr...@at...>]

Oren,

I work in C# and socket is of type QuickFix.ThreadedSocketInitiator. I use
socket.start() to initiate a session.

So are Session::isLoggedOn and socket.isLoggedOn one and the same?

Thanks,

Francis

-----Original Message-----
From: Oren Miller
Sent: Thursday, June 23, 2005 15:28
To: Francis Gingras; qui...@li...
Subject: Re: [Quickfix-developers] How to check for dropped socket

A session always exists, but it can be disabled if you do not wish for it to
logon and process messages.  Keep in mind these are FIX sessions, not socket
sessions.  They exist outside of the scope of a socket connection.

Session::isLoggedOn indicates whether the sessions has sucesfully exchanged
logon messages with the counterparty.  I'm not sure what you are refering to
with "socket.isLoggedOn()".

--oren

Re: [Quickfix-developers] How to check for dropped socket

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

By "off" do you mean logged out or disabled?

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:50 AM
  Subject: Re: [Quickfix-developers] How to check for dropped socket



  Oren,=20

  Do you mean that if the session is off, the message will only be =
stored locally and the seq number will be increased? Next time the =
session is created, the counterparty will figure out the seq # does not =
match and therefore will ask for resend.=20

  If that is the case, that  makes sense. However, I feel not =
comfortable assuming the message has been pushed out without any warning =
or exception. Should program be notified if it tries to send a message =
when the session is off?=20

  Thanks=20
  Alvin'=20





       "Oren Miller" <or...@qu...>=20
        06/23/2005 03:19 PM=20

              =20
                To:        "Francis Gingras" <fr...@at...>, =
"Alvin Wang" <AW...@FF...>=20
                cc:        <qui...@li...>, =
<qui...@li...>=20
                bcc:        =20
                Subject:        Re: [Quickfix-developers] How to check =
for dropped socket=20



  And you never will know.  FIX is an asynchronous protocol.  There is =
no way for it to indicate the succesful receipt of a message.  That is =
why the sequence numbers are necessary.  Your SendToTarget is returning =
true because QuickFIX was able to store your message and take =
responsibility for sending it.  It may not be able to send it right =
away, but it will do so when required by a ResendRequest.=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Francis Gingras=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:20 AM=20
  Subject: Re: [Quickfix-developers] How to check for dropped socket=20


  A related question:=20

  It seems that I can use the static method =
Session.sendToTarget(Message, SessionID) successfully even when the =
corresponding session is not logged on. (I am not sure if the =
counterparty really receives the message in this case)=20

  thanks=20
  Alvin=20



       Francis Gingras <fr...@at...>=20
        Sent by: qui...@li...=20
        06/23/2005 02:58 PM=20
              =20
               To:        qui...@li...=20
               cc:        =20
               bcc:        =20
               Subject:        [Quickfix-developers] How to check for =
dropped socket=20




  QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
  QuickFIX FAQ: =
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
  QuickFIX Support: http://www.quickfixengine.org/services.html

  I am using the initiator and I'd like to know how I can check if the =
socket
  was dropped. (i.e. if the connection was shut down by the acceptor =
side)

  I figure I can use these properties but I'm not 100% sure what they =
mean:

  session.isEnabled()
  If the session exists, how can it not be enabled?

  session.isLoggedOn()
  socket.isLoggedOn()
  Are they always the same and do they mean the same thing?

  Thanks,

  Francis Gingras



  -------------------------------------------------------
  SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
  from IBM. Find simple to follow Roadmaps, straightforward articles,
  informative Webcasts and more! Get everything you need to get up to
  speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
  _______________________________________________
  Quickfix-developers mailing list
  Qui...@li...
  https://lists.sourceforge.net/lists/listinfo/quickfix-developers


  ********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

Re: [Quickfix-developers] How to check for dropped socket

[Alvin W. <AW...@FF...>]

Oren,

Do you mean that if the session is off, the message will only be stored 
locally and the seq number will be increased? Next time the session is 
created, the counterparty will figure out the seq # does not match and 
therefore will ask for resend.

If that is the case, that  makes sense. However, I feel not comfortable 
assuming the message has been pushed out without any warning or exception. 
Should program be notified if it tries to send a message when the session 
is off?

Thanks
Alvin'







"Oren Miller" <or...@qu...>
06/23/2005 03:19 PM

 
        To:     "Francis Gingras" <fr...@at...>, "Alvin Wang" <AW...@FF...>
        cc:     <qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] How to check for dropped socket


And you never will know.  FIX is an asynchronous protocol.  There is no 
way for it to indicate the succesful receipt of a message.  That is why 
the sequence numbers are necessary.  Your SendToTarget is returning true 
because QuickFIX was able to store your message and take responsibility 
for sending it.  It may not be able to send it right away, but it will do 
so when required by a ResendRequest.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Francis Gingras 
Cc: qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:20 AM
Subject: Re: [Quickfix-developers] How to check for dropped socket


A related question: 

It seems that I can use the static method Session.sendToTarget(Message, SessionID) successfully even when the corresponding session is not logged on. (I am 
not sure if the counterparty really receives the message in this case) 

thanks 
Alvin 





Francis Gingras <fr...@at...> 
Sent by: qui...@li... 
06/23/2005 02:58 PM 
        
        To:        qui...@li... 
        cc:         
        bcc:         
        Subject:        [Quickfix-developers] How to check for dropped 
socket



QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I am using the initiator and I'd like to know how I can check if the 
socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

Re: [Quickfix-developers] How to check for dropped socket

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

A session always exists, but it can be disabled if you do not wish for it to 
logon and process messages.  Keep in mind these are FIX sessions, not socket 
sessions.  They exist outside of the scope of a socket connection.

Session::isLoggedOn indicates whether the sessions has sucesfully exchanged 
logon messages with the counterparty.  I'm not sure what you are refering to 
with "socket.isLoggedOn()".

--oren

----- Original Message ----- 
From: "Francis Gingras" <fr...@at...>
To: <qui...@li...>
Sent: Thursday, June 23, 2005 1:58 PM
Subject: [Quickfix-developers] How to check for dropped socket


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I am using the initiator and I'd like to know how I can check if the 
> socket
> was dropped. (i.e. if the connection was shut down by the acceptor side)
>
> I figure I can use these properties but I'm not 100% sure what they mean:
>
> session.isEnabled()
> If the session exists, how can it not be enabled?
>
> session.isLoggedOn()
> socket.isLoggedOn()
> Are they always the same and do they mean the same thing?
>
> Thanks,
>
> Francis Gingras
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

Re: [Quickfix-developers] How to check for dropped socket

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

And you never will know.  FIX is an asynchronous protocol.  There is no =
way for it to indicate the succesful receipt of a message.  That is why =
the sequence numbers are necessary.  Your SendToTarget is returning true =
because QuickFIX was able to store your message and take responsibility =
for sending it.  It may not be able to send it right away, but it will =
do so when required by a ResendRequest.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Francis Gingras=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:20 AM
  Subject: Re: [Quickfix-developers] How to check for dropped socket



  A related question:=20

  It seems that I can use the static method =
Session.sendToTarget(Message, SessionID) successfully even when the =
corresponding session is not logged on. (I am not sure if the =
counterparty really receives the message in this case)=20

  thanks=20
  Alvin=20




       Francis Gingras <fr...@at...>=20
        Sent by: qui...@li...=20
        06/23/2005 02:58 PM=20

              =20
                To:        qui...@li...=20
                cc:        =20
                bcc:        =20
                Subject:        [Quickfix-developers] How to check for =
dropped socket=20



  QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
  QuickFIX FAQ: =
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
  QuickFIX Support: http://www.quickfixengine.org/services.html

  I am using the initiator and I'd like to know how I can check if the =
socket
  was dropped. (i.e. if the connection was shut down by the acceptor =
side)

  I figure I can use these properties but I'm not 100% sure what they =
mean:

  session.isEnabled()
  If the session exists, how can it not be enabled?

  session.isLoggedOn()
  socket.isLoggedOn()
  Are they always the same and do they mean the same thing?

  Thanks,

  Francis Gingras



  -------------------------------------------------------
  SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
  from IBM. Find simple to follow Roadmaps, straightforward articles,
  informative Webcasts and more! Get everything you need to get up to
  speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
  _______________________________________________
  Quickfix-developers mailing list
  Qui...@li...
  https://lists.sourceforge.net/lists/listinfo/quickfix-developers


  ********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
********************************************************************** 

Re: [Quickfix-developers] How to check for dropped socket

[Alvin W. <AW...@FF...>]

A related question:

It seems that I can use the static method Session.sendToTarget(Message, SessionID) successfully even when the corresponding session is not logged on. (I am 
not sure if the counterparty really receives the message in this case)

thanks
Alvin






Francis Gingras <fr...@at...>
Sent by: qui...@li...
06/23/2005 02:58 PM

 
        To:     qui...@li...
        cc: 
        bcc: 
        Subject:        [Quickfix-developers] How to check for dropped socket


QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I am using the initiator and I'd like to know how I can check if the 
socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

Re: [Quickfix-developers] logon problem

[Alvin W. <AW...@FF...>]

Sean,

Are you saying that you got a Logout from counterparty but QF did not log=
=20
it anywhere? I think I saw it also.

Alvin





"Sean Kirkpatrick" <Sea...@Pi...>
Sent by: qui...@li...
06/23/2005 02:47 PM

=20
        To:     <qui...@li...>
        cc:=20
        bcc:=20
        Subject:        [Quickfix-developers] logon problem


QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hello All,

I've encountered a bizarre logon problem (1.9.4).  A session was logged
in and functioning normally (heartbeats, new orders, exec rpts, etc).=20
The connection was then brought down without logging off.  I increased
the seq number to test the sequence reset functionality, but now the=20
server
doesn't even see the logon request.  I was able to verify that the message
is coming across using a packet sniffer, but quickfix is not logging
anything to any of the session logs (incoming, outgoing, event).  On the
initiator, all I see is:

20050623-18:36:19 : Connecting to host on port #
20050623-18:36:19 : Connection succeeded
20050623-18:36:19 : Initiated logon request
20050623-18:36:19 : Dropped Connection

I've checked to ensure that the Comp IDs are correct as well as the FIX
version.  I am able to log in and use other sessions normally from the=20
same
test app.  Is there anything that might cause an individual session to
become mangled?

Thanks,
Sean


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



                                                                           =
                                                                           =
                                                                           =
                                                                   ********=
**************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential. =
=20
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

[Quickfix-developers] How to check for dropped socket

[Francis G. <fr...@at...>]

I am using the initiator and I'd like to know how I can check if the socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras

[Quickfix-developers] logon problem

[Sean K. <Sea...@Pi...>]

Hello All,

I've encountered a bizarre logon problem (1.9.4).  A session was logged
in and functioning normally (heartbeats, new orders, exec rpts, etc). =20
The connection was then brought down without logging off.  I increased
the seq number to test the sequence reset functionality, but now the =
server
doesn't even see the logon request.  I was able to verify that the =
message
is coming across using a packet sniffer, but quickfix is not logging
anything to any of the session logs (incoming, outgoing, event).  On the
initiator, all I see is:

20050623-18:36:19 : Connecting to host on port #
20050623-18:36:19 : Connection succeeded
20050623-18:36:19 : Initiated logon request
20050623-18:36:19 : Dropped Connection

I've checked to ensure that the Comp IDs are correct as well as the FIX
version.  I am able to log in and use other sessions normally from the =
same
test app.  Is there anything that might cause an individual session to
become mangled?

Thanks,
Sean

Re: [Quickfix-developers] ExecType

[Alvin W. <AW...@FF...>]

Brian, thanks so much for your explanations. that makes a lot of sense.

Unfortunately, many counterparties upgraded their FIX engines from FIX 42 
and therefore continue using Partial Fill and Filled as ExecType.

Thanks
Alvin






Brian Erst <azz...@ya...>
06/23/2005 10:45 AM
Please respond to azzipsderf-quickfix

 
        To:     Alvin Wang <AW...@FF...>, qui...@li..., 
qui...@li...
        cc: 
        bcc: 
        Subject:        Re: [Quickfix-developers] ExecType


Alvin -

This probably isn't the correct forum for general FIX questions, but I
can answer this one.

OrdStatus (39) and ExecType (150) have generally used the same code
values, but for somewhat different reasons. OrdStatus gave you the
current status of the order, while ExecType told you how this
particular ExecutionReport affected the order.

Starting with FIX 4.4, they made Trade Correct (G) and Trade Cancel (H)
new ExecType codes (they were previously indicated by ExecTransType
codes). It never really made much sense to have Partial Fill (1) and
Filled (2) codes for ExecType - these are really order statuses - so
they created a new ExecType Trade (F) to have a nice, orthogonal set of
ExecTypes. Trade, Trade Correct and Trade Cancel are now all single
codes that are defined in order.

I believe Partial Fill and Filled are now used only as OrdStatus values
as of FIX 4.4.

- Brian Erst
Thynk Software, Inc.

--- Alvin Wang <AW...@FF...> wrote:

> Hi I have a pure FIX (44) question. Can anyone explain to me the 
> difference between ExecType 2(Fill) and ExecType F(Trade, fill or
> partial 
> fill)?
> 
> Thanks
> Alvin




                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

[Quickfix-developers] COM issue and .Net documentation question

[Daniel O'B. <do...@st...>]

Hi,

=20

I am just creating my first QuickFix client in C# and have run into the
following problem.

=20

When I create my SocketInitiator an exception is thrown with the
following message:

=20

"Configuration failed: Could not initialize COM".

=20

I don't know why this is the case, especially since I can run the C++
tradeclient example and that SocketInitiator is constructed no problem.

=20

Also, the documentation shows that the SocketInitiator has two
constructors: a 3 arg version and a 4 arg version.

=20

However, the .NET DLL version of the SocketInitiator class has a 4 arg
version and a 5 arg version.  Why the difference and it there any
documentation for the .NET dll?

=20

Any help much appreciated,

=20

Dan

=20