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

Wed Mar 6 11:03:04 PST 2013

Is it possible that two of those counterparties could define
conflicting tag values?  (e.g. one says tag 8888 is XXX and another
says it's YYY)

Is also seems possible that two counterparties could define a
repeating group with conflicting field orderings.

Frankly, this scenario you're describing sounds pretty nuts.  It's
very unorthodox, and given your description, might not be entirely FIX
compliant.

On Wed, Mar 6, 2013 at 12:46 PM, James A. Smith <jsmith at anstca.com> wrote:
> 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
> _______________________________________________
> 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