quickfix-developers

RE: [Quickfix-developers] Session Identification Problem

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

Hi Oren
=20
Thanks for the reply, the option of using UserID is very helpful, we =
could do this.:)
=20
But does FIXProtocol allow this? like can we have same sender and =
targetID for two different sessions if the two sessions are different in =
functionality?
or does it say that we need to have a unique combination of senderId and =
targetID.=20
=20
I did go through the FIXProtocol spec, but I could not identify any =
place where it specifically states this.=20
=20
thanks
R Shamanth

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Friday, July 30, 2004 5:19 PM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-developers] Session Identification Problem



That's a strange scenario. The way QuickFIX would handle this now is the =
way you don't want to do it, two separate processes. The problem with =
using something like the port to identify the session is twofold. One, =
as Joerg pointed out, it is a transport level concept and not one which =
the fix protocol itself is familiar with. Another problem is that the =
port is not a part of the message. In other words, in a scenario like =
this, you can no longer rely on the contents of the message to identify =
what session it belongs to. This means we would have to rely on some =
meta-data in addition to the FIX message itself to figure out where it =
needs to be routed. I don't have a problem with this necessarily, but I =
don't think and arbitrary attribute like the session port is the way to =
do it.=20


One thing I may consider is something along the lines of a UserID =
configuration field. Something like this:=20


[SESSION]=20

SenderCompID=3DSENDER=20

TargetCompID=3DTARGET=20

UserID=3DMARKETDATA=20


[SESSION]=20

SenderCompID=3DSENDER=20

TargetCompID=3DTARGET=20

UserID=3DORDER=20


This user id would be optional, and it would at least make the id =
meaningful.=20


On Jul 28, 2004, at 7:18 AM, Shamanth wrote:=20


Hi=20


We have a provider who has the two sessions exposed=20

1) For Marketdata=20

2) For Order=20


The problem is both these sessions use same SenderID, SenderSubID, =
TargetID and also the SocketConnectHost the only difference is in the =
port number (SocketConnetPort).=20


How does quickfix can be setup to handle the above situation. We want to =
run only one instance of quickfix servicing both the sessions.=20


thanks=20

R Shamanth=20


  NOTICE=20


This e-mail message and any attachments, which may contain confidential =
information, are to be viewed solely by the intended recipient of =
Integral Development Corp.  If the reader of this message is not the =
intended recipient, you are hereby notified that any use, dissemination, =
distribution or copying of this communication is strictly prohibited.  =
If you have received this message in error, please immediately notify =
the sender and delete the mail and all attachments.

RE: [Quickfix-developers] Session Identification Problem

[Day, J. B. S. <Je...@ba...>]

This is an interesting scenario....
=20
The Fix (4.4) spec states that...
=20
A Fix 'Connection' : comprises Login, msg exchange, Logout
A Fix 'Session' : comprises 1 or more Fix 'Connections'
=20
These statements would imply that connecting to different port numbers =
with the same logon details is valid !!
=20
The sections relating to mulit-cast/pub-sub may be applicable.
=20
Jem...
=20

-----Original Message-----
From: qui...@li... =
[mailto:qui...@li...]On Behalf Of =
Oren Miller
Sent: Friday, July 30, 2004 4:49 AM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-developers] Session Identification Problem


That's a strange scenario. The way QuickFIX would handle this now is the =
way you don't want to do it, two separate processes. The problem with =
using something like the port to identify the session is twofold. One, =
as Joerg pointed out, it is a transport level concept and not one which =
the fix protocol itself is familiar with. Another problem is that the =
port is not a part of the message. In other words, in a scenario like =
this, you can no longer rely on the contents of the message to identify =
what session it belongs to. This means we would have to rely on some =
meta-data in addition to the FIX message itself to figure out where it =
needs to be routed. I don't have a problem with this necessarily, but I =
don't think and arbitrary attribute like the session port is the way to =
do it.=20

One thing I may consider is something along the lines of a UserID =
configuration field. Something like this:=20

[SESSION]=20
SenderCompID=3DSENDER=20
TargetCompID=3DTARGET=20
UserID=3DMARKETDATA=20

[SESSION]=20
SenderCompID=3DSENDER=20
TargetCompID=3DTARGET=20
UserID=3DORDER=20

This user id would be optional, and it would at least make the id =
meaningful.=20

On Jul 28, 2004, at 7:18 AM, Shamanth wrote:=20


Hi=20

We have a provider who has the two sessions exposed=20
1) For Marketdata=20
2) For Order=20

The problem is both these sessions use same SenderID, SenderSubID, =
TargetID and also the SocketConnectHost the only difference is in the =
port number (SocketConnetPort).=20

How does quickfix can be setup to handle the above situation. We want to =
run only one instance of quickfix servicing both the sessions.=20

thanks=20
R Shamanth=20

  NOTICE=20

This e-mail message and any attachments, which may contain confidential =
information, are to be viewed solely by the intended recipient of =
Integral Development Corp.  If the reader of this message is not the =
intended recipient, you are hereby notified that any use, dissemination, =
distribution or copying of this communication is strictly prohibited.  =
If you have received this message in error, please immediately notify =
the sender and delete the mail and all attachments.

Re: [Quickfix-developers] Session Identification Problem

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

Yes, but is that simultaneous connections?  For sure you can logon,=20
send messages, and logoff many times during the day, each of which=20
constitutes a connection that are all associated with the same session.=20=

  But these connections exist sequentially, not simultaneously.  The=20
complete section that you are quoting reads like this:

A FIX Connection is comprised of three parts: logon, message  exchange,=20=

and logout.
A FIX Session is comprised of one or more FIX Connections,  meaning=20
that a FIX Session spans multiple logins.

Certainly you can connect the same session to different ports.  FIX=20
doesn't have any concept of ports so that is entirely outside of the=20
scope of the specification.  You can implement the underlying=20
transports anyway you like.  You can choose to implement a FIX=20
connection over multiple simultaneous socket connections and round=20
robin all your messages, for instance.  But these 'physical'=20
connections are not the same as a FIX connection which is more=20
abstract.

But really I don't think that what this counter-party is doing is=20
necessarily violating the spec, but is just poor planning in my=20
opinion.  They essentially have chosen to have two unique sessions that=20=

they are identifying with the same characteristics.  As long as the two=20=

don't know about each other, this is technically ok, just very=20
confusing.  It also makes it difficult for a FIX engine to discern the=20=

difference without making it aware of what are supposed to be=20
encapsulated attributes.  (the concept of a user id is one way to work=20=

around this).  But it is still strange because you can not tell from=20
the message which session it belongs too.  FIX messages are supposed to=20=

contain all necessary routing information.  If a FIX message cannot=20
positively identify where it has come from or where it is intended to=20
go, that is a problem IMHO.

I don't think that the pub-sub section really applies here either. =20
First off, in that scenario logons and logouts are one way (the=20
subscriber sends them without getting a response).  Also, in that case=20=

business messages only travel in one direction.  Finally all of the=20
messages transmitted to all the subscribers are the same with the same=20=

sequence numbers.  Two subscribers will receive the same message for=20
sequence number 123.  This can't be the case as described here since=20
each session is sending completely different message types.  For these=20=

reasons I don't think that they can be considered the same session, but=20=

two different sessions with the same id.

--oren

On Jul 30, 2004, at 1:09 PM, Day, Jem BGI SF wrote:

> This is an interesting scenario....
> =A0
> The Fix (4.4) spec states that...
> =A0
> A Fix 'Connection' : comprises Login, msg exchange, Logout
> A Fix 'Session' : comprises 1 or more Fix 'Connections'
> =A0
> These statements would imply that connecting to different port numbers=20=

> with the same logon details is valid !!
> =A0
> The sections relating to mulit-cast/pub-sub may be applicable.
> =A0
> Jem...
> =A0
> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...]On Behalf Of=20=

> Oren Miller
> Sent: Friday, July 30, 2004 4:49 AM
> To: Shamanth
> Cc: qui...@li...;=20
> qui...@li...
> Subject: Re: [Quickfix-developers] Session Identification Problem
>
> That's a strange scenario. The way QuickFIX would handle this now is=20=

> the way you don't want to do it, two separate processes. The problem=20=

> with using something like the port to identify the session is twofold.=20=

> One, as Joerg pointed out, it is a transport level concept and not one=20=

> which the fix protocol itself is familiar with. Another problem is=20
> that the port is not a part of the message. In other words, in a=20
> scenario like this, you can no longer rely on the contents of the=20
> message to identify what session it belongs to. This means we would=20
> have to rely on some meta-data in addition to the FIX message itself=20=

> to figure out where it needs to be routed. I don't have a problem with=20=

> this necessarily, but I don't think and arbitrary attribute like the=20=

> session port is the way to do it.
>
>
>  One thing I may consider is something along the lines of a UserID=20
> configuration field. Something like this:
>
>
>  [SESSION]
>  SenderCompID=3DSENDER
>  TargetCompID=3DTARGET
>  UserID=3DMARKETDATA
>
>
>  [SESSION]
>  SenderCompID=3DSENDER
>  TargetCompID=3DTARGET
>  UserID=3DORDER
>
>
>  This user id would be optional, and it would at least make the id=20
> meaningful.
>
>
>  On Jul 28, 2004, at 7:18 AM, Shamanth wrote:
>
>
>  Hi
>
>
> We have a provider who has the two sessions exposed
> 1) For Marketdata
> 2) For Order
>
>
> The problem is both these sessions use same SenderID, SenderSubID,=20
> TargetID and also the SocketConnectHost the only difference is in the=20=

> port number (SocketConnetPort).
>
>
> How does quickfix can be setup to handle the above situation. We want=20=

> to run only one instance of quickfix servicing both the sessions.
>
>
> thanks
> R Shamanth
>
>
> =A0 NOTICE
>
>
> This e-mail message and any attachments, which may contain=20
> confidential information, are to be viewed solely by the intended=20
> recipient of Integral Development Corp.=A0 If the reader of this =
message=20
> is not the intended recipient, you are hereby notified that any use,=20=

> dissemination, distribution or copying of this communication is=20
> strictly prohibited.=A0 If you have received this message in error,=20
> please immediately notify the sender and delete the mail and all=20
> attachments.
>

RE: [Quickfix-developers] Session Identification Problem

[Day, J. B. S. <Je...@ba...>]

Oren,
=20
   You are (of course) correct.
=20
   A session spans multiple connections 'serially', not concurrently.
=20
   I would concur with one of the previous items on this thread that the =
'correct' way to achieve the functionality required would be to have =
distinct sessions for market-data and trading (and if they chose to use =
different host/port combinations then so be it).
=20
  The more I ruminated about my comments over the weekend, the more I =
came to realize that I had to be wrong - it does happen occasionally =
:-).
=20
Jem...
=20

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Saturday, July 31, 2004 9:37 AM
To: Day, Jem BGI SF
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-developers] Session Identification Problem


Yes, but is that simultaneous connections? For sure you can logon, send =
messages, and logoff many times during the day, each of which =
constitutes a connection that are all associated with the same session. =
But these connections exist sequentially, not simultaneously. The =
complete section that you are quoting reads like this:=20

A FIX Connection is comprised of three parts: logon, message exchange, =
and logout.=20
A FIX Session is comprised of one or more FIX Connections, meaning that =
a FIX Session spans multiple logins.=20

Certainly you can connect the same session to different ports. FIX =
doesn't have any concept of ports so that is entirely outside of the =
scope of the specification. You can implement the underlying transports =
anyway you like. You can choose to implement a FIX connection over =
multiple simultaneous socket connections and round robin all your =
messages, for instance. But these 'physical' connections are not the =
same as a FIX connection which is more abstract.=20

But really I don't think that what this counter-party is doing is =
necessarily violating the spec, but is just poor planning in my opinion. =
They essentially have chosen to have two unique sessions that they are =
identifying with the same characteristics. As long as the two don't know =
about each other, this is technically ok, just very confusing. It also =
makes it difficult for a FIX engine to discern the difference without =
making it aware of what are supposed to be encapsulated attributes. (the =
concept of a user id is one way to work around this). But it is still =
strange because you can not tell from the message which session it =
belongs too. FIX messages are supposed to contain all necessary routing =
information. If a FIX message cannot positively identify where it has =
come from or where it is intended to go, that is a problem IMHO.=20

I don't think that the pub-sub section really applies here either. First =
off, in that scenario logons and logouts are one way (the subscriber =
sends them without getting a response). Also, in that case business =
messages only travel in one direction. Finally all of the messages =
transmitted to all the subscribers are the same with the same sequence =
numbers. Two subscribers will receive the same message for sequence =
number 123. This can't be the case as described here since each session =
is sending completely different message types. For these reasons I don't =
think that they can be considered the same session, but two different =
sessions with the same id.=20

--oren=20

On Jul 30, 2004, at 1:09 PM, Day, Jem BGI SF wrote:=20


This is an interesting scenario....=20
The Fix (4.4) spec states that...=20
A Fix 'Connection' : comprises Login, msg exchange, Logout=20
A Fix 'Session' : comprises 1 or more Fix 'Connections'=20
These statements would imply that connecting to different port numbers =
with the same logon details is valid !!=20
The sections relating to mulit-cast/pub-sub may be applicable.=20
Jem...=20
-----Original Message-----=20
From: qui...@li... =
[mailto:qui...@li...]On Behalf Of =
Oren Miller=20
Sent: Friday, July 30, 2004 4:49 AM=20
To: Shamanth=20
Cc: qui...@li...; =
qui...@li...=20
Subject: Re: [Quickfix-developers] Session Identification Problem=20

That's a strange scenario. The way QuickFIX would handle this now is the =
way you don't want to do it, two separate processes. The problem with =
using something like the port to identify the session is twofold. One, =
as Joerg pointed out, it is a transport level concept and not one which =
the fix protocol itself is familiar with. Another problem is that the =
port is not a part of the message. In other words, in a scenario like =
this, you can no longer rely on the contents of the message to identify =
what session it belongs to. This means we would have to rely on some =
meta-data in addition to the FIX message itself to figure out where it =
needs to be routed. I don't have a problem with this necessarily, but I =
don't think and arbitrary attribute like the session port is the way to =
do it.=20


One thing I may consider is something along the lines of a UserID =
configuration field. Something like this:=20


[SESSION]=20
SenderCompID=3DSENDER=20
TargetCompID=3DTARGET=20
UserID=3DMARKETDATA=20


[SESSION]=20
SenderCompID=3DSENDER=20
TargetCompID=3DTARGET=20
UserID=3DORDER=20


This user id would be optional, and it would at least make the id =
meaningful.=20


On Jul 28, 2004, at 7:18 AM, Shamanth wrote:=20


Hi=20


We have a provider who has the two sessions exposed=20
1) For Marketdata=20
2) For Order=20


The problem is both these sessions use same SenderID, SenderSubID, =
TargetID and also the SocketConnectHost the only difference is in the =
port number (SocketConnetPort).=20


How does quickfix can be setup to handle the above situation. We want to =
run only one instance of quickfix servicing both the sessions.=20


thanks=20
R Shamanth=20


  NOTICE=20


This e-mail message and any attachments, which may contain confidential =
information, are to be viewed solely by the intended recipient of =
Integral Development Corp.  If the reader of this message is not the =
intended recipient, you are hereby notified that any use, dissemination, =
distribution or copying of this communication is strictly prohibited.  =
If you have received this message in error, please immediately notify =
the sender and delete the mail and all attachments.=20