<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=unicode">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText55230 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>You're welcome! I have
to say that I don't quite understand why you'd want to use FIX for logging or
IPC. The protocol layer of FIX has some pretty complicated retransmission
logic and although it's not as bad as XML, it's not a very compact format.
Recovering from a sequence number mismatch between the two sides of a FIX
connection can be a real headache.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>However, to answer your other questions, it
is possible to deal with arbitrary FIX messages, but not if they have repeating
groups. It would be very painful to try to encode all your data
without using repeating groups, so I don't think that helps you.
The syntax of FIX is really fairly simplistic. It's either a
simple tag => value or it's a repeating group. Repeating groups
can be nested, although the code I pasted below won't quite handle
this case. Repeating groups always have a starting tag that represents the
count of elements in the group. Confusingly, the FIX documentation always
uses the prefix "No" for number in the mnemonic (e.g.,
NoCounterParties, which means "number of counter parties", not that there are no
counter parties). Anyway, following the starting tag, there's the contents
of the repeating group, one instance after another, as tag => value pairs (or
nested repeating groups). Without telling the parser which tags start
repeating groups, and what the contents of the repeating group will be, there
can be parsing ambiguities. Note, also, the verbosity here; every tag gets
duplicated for every instance of a repeating group.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I know the FIX protocol organization has
been working on something called FAST (FIX Adapted for Streaming) that would
resolve some of these issues, but I think it's still in the proof-of-concept
phase. Anyway, under that model, you would certainly need to describe
your message structure in detail to both sides of the
connection.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Hope that helps...</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Ben</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Montgomery Conner
[mailto:montgomery.conner@gmail.com]<BR><B>Sent:</B> Sat 12/2/2006 11:21
PM<BR><B>To:</B> Holzman, Benjamin<BR><B>Cc:</B>
banking-pm@pm.org<BR><B>Subject:</B> Re: [Banking-pm] FIX: Financial Information
eXchange<BR></FONT><BR></DIV>
<DIV>Thank you for you very complete response! <BR><BR>A few
questions...<BR><BR>There's been a lot of talk at my job about using FIX to
standardize the application infrastructure (logging, some kinds of IPC, etc. ),
in which case many of these tags would likely be in the range of FIX tags that
are reserved for vendor communications and are thus
undocumented/undefined. For a case such as this, in your experience, is
there any simple (yet robust) way respond to tags that have not been encountered
before? That is, do you think that such a parser might need a more
complete grammar specification than a simple hash, or is FIX itself simple
enough that certain default responses could be engineered for ranges of tags
regardless of whether they already resided in a local specification hash?
<BR><BR><BR><BR>Thanks again, your insight has been very
helpful,<BR>Montgomery<BR><BR><BR>
<DIV><SPAN class=gmail_quote>On 12/2/06, <B class=gmail_sendername>Holzman,
Benjamin</B> <<A href="mailto:BHolzman@iseoptions.com">
BHolzman@iseoptions.com</A>> wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">>
I would have assumed that FIX is so large that any generic <BR>>
implementation of it is likely to be incomplete.<BR><BR>Yes and no, I
think. My experience with FIX has been that
the<BR>application-level messages tend to be domain-specific, but
the<BR>protocol-level is quite stable. I have built FIX interfaces
to allow <BR>order entry and market data for our parimutuel matching
engine. I did<BR>it using the quickfix open source FIX engine
(actually C++ libraries) to<BR>handle the protocol and wrote a minimal C++
bridge that shuttles FIX <BR>application messages back and forth to a perl
process over a socket.<BR><BR>I then parse the FIX messages in perl with a
custom FixMessage base<BR>class, run all of my application logic there,
creating FixMessage<BR>objects as responses and then turn them back into a
string to send back <BR>to the C++ bridge. I store the FIX messages
as a hash mapping the fix<BR>tag number to the value. I then have
accessor methods named after the<BR>mnemonic for each tag number. I
actually just have a hash (%tagMapping) <BR>in my base class with the mapping
and use an AUTOLOAD to create the<BR>accessors on demand. Parsing
the FIX message is as simple as this
code:<BR><BR><BR> sub fromString
{<BR> my $string =
shift;<BR><BR> my($class,
%tags); <BR> foreach my $field
(split /\001/, $string)
{<BR> my($tag,
$value) = split /=/, $field,
2;<BR> if ($tag ==
$tagMapping{'MsgType'})
{<BR> $class
=
$msgType_2_class{$value};<BR> next;
<BR> }<BR><BR> next
if defined
$isHeaderTag{$tag};<BR><BR> $tags{$tag}
=
$value;<BR> }<BR><BR> return
$class->new(\%tags);<BR> }<BR><BR>I have sub-classes
of FixMessage for each MsgType that I handle; the <BR>%msgType_2_class hash
has the mapping.<BR><BR>Actually, there's an additional complication to handle
repeating groups;<BR>the value of a repeating group is an array ref with one
element for each<BR>instance of the group; because tag order in repeating
groups matters, <BR>each instance is represented with an array consisting of
tag<BR>number/value pairs. Something like this: [ [ 42 =>
'value', 165 =><BR>'another value' ], [ 42 => 'value2', 165 => 'yet
another' ], ... ]. So <BR>my actual fromString function has more
logic to handle this.<BR><BR>Anyway, converting an object back to a string
isn't too hard; the only<BR>tricky parts are including the body length in the
header and computing<BR>the checksum for the trailer. My code looks
like this: <BR><BR> sub toString
{<BR> my $this =
shift;<BR><BR> my $header =
"8=FIX.4.4\0019=";<BR> my $body
= join("\001", "35=$class_2_msgType{ref
$this}",<BR>
map _toString($_, $this->{$_}), keys %$this) .
<BR>"\001";<BR><BR> my $msg =
$header . length($body) .
"\001$body";<BR><BR> my $cksum
= 0;<BR> $cksum += ord($_) for
split //, $msg;<BR><BR> $cksum
= sprintf "%03d", $cksum %256;
<BR><BR> return $msg .
"10=$cksum\001";<BR> }<BR><BR> sub
_toString {<BR> my($key,
$value) = @_;<BR> if (ref
$value eq 'ARRAY')
{<BR> return unless
@$value;<BR><BR> return
join "\001",
<BR> "$key="
.
@$value,<BR> map
{ my $val =
$_;<BR> my
@data;<BR> for
(my $i = 0; $i < $#$val; $i+=2) {
<BR> push
@data,
"$tagMapping{$val->[$i]}="<BR>.<BR> $val->[$i
+
1];<BR> }<BR> @data;
<BR> }
@$value;<BR> } elsif ($value ne
'') {<BR> return
"$key=$value";<BR> } else
{<BR> return;<BR> }<BR> }<BR><BR>That's
pretty much my whole FIX message base class. The constructor
<BR>allows objects to be constructed from a string or from tag mnemonic
=><BR>value pairs.<BR><BR>I don't know if this helps you, but at least you
see how simple it is to<BR>handle parsing and generation of FIX messages.
<BR><BR>Benjamin Holzman<BR></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>