{{Quickfixn}} custom fields (multi-counter-party)

[Grant Birchmeier]

That sounds really weird.

So this counterparty is basically a relay?  For this to act like a
valid FIX connection, it would need to rewrite the header of every
message that it's relaying.  Even then, though, the DD problems I
mentioned would still be in play.  If your relayer can't adhere to a
consistent DD, then it's not really a valid FIX interface.

-Grant


On Wed, Mar 6, 2013 at 11:22 AM, James A. Smith <jsmith at anstca.com> wrote:
> Let me clarify the case:  There is 1 session to 1 counterparty, however
> that counterparty will be sending me messages from many counterparties.
> This is the complexity, to parse all counterparty's messages sent to me
> by my counterparty.  Does that makes sense?
>
> -----Original Message-----
> From: quickfixn-bounces at lists.quickfixn.com
> [mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Grant
> Birchmeier
> Sent: Wednesday, March 06, 2013 12:04 PM
> To: Mailing list for QuickFIX/n
> Subject: Re: {{Quickfixn}} custom fields (multi-counter-party)
>
> I'm seeing red flags like crazy here, and probably some misused
> terminology.
>
> First, a clarification: A session is an instance of a one-to-one
> connection.  If an acceptor is handling 5 initiators, then that's 5
> sessions.  Sessions are identified by, among other things, the FIX
> version and the party IDs.
>
> I assume you're writing an initiator, e.g. a client.  You want to use
> one application to connect to multiple venues, and you want to use a
> common DataDictionary for all of them.  Is that right?
>
> From experience, I think that is not a workable plan.
>
> 1) It's possible that two venues can have completely incompatible DDs.
>  I've seen a venue rearrange FIX fields inside repeating groups for no
> good reason, and that would screw your DD up for everyone else.  It's
> not likely, but venues can do really insane things.
>
> 2) Two venues might use the same custom field tag for different custom
> fields.  Say venue-1 defines 8888 as a string, but venue-2 defines it as
> an int?
>
> 3) Maintainability.  Say a venue makes a DD change.  You need to make
> that corresponding change in your DD... but now you need to validate you
> change against ALL your venues, not just the one that changed.
>
> 4) Are you even thinking about conflicting config file settings yet?
> That's a whole other post.
>
> At best, I think you can write an app that takes two parameters: a
> config file path and a DD path.  You'll maintain a different config and
> a different DD for each venue.  Your app may probably have a lot of
> conditional behaviors due to venue differences, though.
>
> I think a much better plan is to just start by writing to one venue.
> When that works, try to add a second.  You'll quickly see can be reused
> and what can't, and I think you'll come up with a much better plan of
> action when you work on venues 3, 4, and beyond.
>
> I appreciate wanting to do a big elegant design at the beginning, but it
> sounds like you might not have enough practical QuickFIX experience to
> see the pitfalls.  You really need to get your hands dirty for a bit and
> do some refactoring later.
>
> -Grant
>
>
> On Wed, Mar 6, 2013 at 10:36 AM, James A. Smith <jsmith at anstca.com>
> wrote:
>> I have many counter parties that will have their own custom fields.  I
>
>> want to be able to use 1 session to handle all counter party messages
>> with their respective custom fields.
>>
>>
>>
>> I should first define all custom fields in the DD, and then add all
>> possible custom fields to each message type as required=N for each
>> MessageType I am listening for?
>>
>>
>>
>> thanks,
>>
>> James Smith
>>
>>
>>
>>
>> _______________________________________________
>> Quickfixn mailing list
>> Quickfixn at lists.quickfixn.com
>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>
>
>
>
> --
> Grant Birchmeier
> Connamara Systems, LLC
> Made-To-Measure Trading Solutions.
> Exactly what you need. No more. No less.
> http://connamara.com
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com



-- 
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com