{{Quickfixn}} custom fields (multi-counter-party)
Grant Birchmeier
gbirchmeier at connamara.com
Wed Mar 6 09:04:09 PST 2013
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
More information about the Quickfixn
mailing list