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

[James A. Smith]

What are your thoughts on defining the custom fields in the DD, and then
making all the new custom field tags to each message type of interest as
required=N?

-----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:28 PM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} custom fields (multi-counter-party)

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
_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com