[Quickfix-users] 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