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.
>