Imported from previous forum
In general, I would prefer to see more message types, and less fields in each message type. For example, I would prefer to have equities messages, separate from options.
My second suggestion is that the date and time fields should be collapsed to a single datetime field.
My third suggestion is that the fields BookEntryType, BookEntryDirection, BookEntryStatus and IsBestBidOffer be collapsed into a single BookFlags field. The purpose is to save bandwidth. With the current specification it might take as many as 7 characters to convey a single bit of information. In the flags, OPEN would default. Not IsBestBidOffer would also be the default.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> In general, I would prefer to see more message types, and less fields in each message type. For example, I would prefer to have equities messages, separate from options.
This approach seems like the antithesis of what the rest of the FIX protocol is doing. Having a separate "Equities Book" "Options Book" "Futures Book" "Forex Book" and "Fixed Income Book" message with different fields would be overly complicated and seems to me to be quite a disadvantage.
Most of the fields to identify an instrument are optional if you are just trading equities. The Complex Instruments draft allows a way of creating a “shorthand” for long symbol descriptions like options. And instrument description size really isn’t that important, since an advantage of incremental book messages is that such things are identified by a (hopefully) short BookEntryID, and one can use RefBookEntryID to avoid repeating descriptions.
Separating these messages at the application layer is possible as well. For instance, in the case of sending unsolicited incremental Book messages by IP multicast, it would make sense to have different IP multicast groups for equity and option quotes.
> My second suggestion is that the date and time fields should be collapsed to a single datetime field.
This is a rather controversial issue. The major approaches I’ve seen recommended are:
-
Use one datetime field. Disadvantage is that it is long.
-
Use a date field and a create a time-only field. The date field if not present would be assumed to be the current day, so you’ve cut down on bandwidth.
-
Use a date field (which if not present is assumed to be the current day) and an integer for seconds past midnight. Disadvantage is complexity, and one needs to define whether the epoch is midnight GMT/UTC or midnight of the time zone of the person sending the book message.
There’s also the issue of sending sub-second times.
My belief is that #2 is the best approach because it can be concise, and it is the easiest to expand to include a decimal point and milliseconds, since no such time type exists in FIX.
> My third suggestion is that the fields BookEntryType, BookEntryDirection, BookEntryStatus and IsBestBidOffer be collapsed into a single BookFlags field. The purpose is to save bandwidth. With the current specification it might take as many as 7 characters to convey a single bit of information. In the flags, OPEN would default. Not IsBestBidOffer would also be the default.
I believe BookEntryType needs to stay separated, as it is a required enumeration crucial to further processing. Validation of FIX messages by engines is often based on the presence of required fields; such engines would be able to catch a missing BookEntryType, but a lack of a Bid, Ask, or Trade enumeration in a BookEntryFlags field containing other flags would not be caught.
BookEntryType may also contain one or more Closing / Settlement price indications, as I believe Paul Lindley at LIFFE suggested adding them.
I see no problem with combining BookEntryDirection, BookEntryStatus, and IsBestBidOffer into a flags field. The question becomes how to represent multiple objects; one way in FIX is to use repeating fields, but this eliminates any space savings. Would a space-delimited field be acceptable?
I believe #1 is the best solution for dealing with the time. Prior to 4.0 we had separate date and time fields with date being assumed or derived in some cases. This became difficult especially for 24 hour trading which most of us are or will soon be dealing with. Technically you can’t have a point in time without a date reference. To assume what that date reference is becomes quite risky. I can appreciate the byte savings, but in general think we should avoid breaking this apart. The request/requirement for subseconds has been brought forward and would/could affect many other messages and likely the overall format of our time data type.
> > In general, I would prefer to see more message types, and less fields in each message type. For example, I would prefer to have equities messages, separate from options.
>
> This approach seems like the antithesis of what the rest of the FIX protocol is doing. Having a separate “Equities Book” “Options Book” “Futures Book” “Forex Book” and “Fixed Income Book” message with different fields would be overly complicated and seems to me to be quite a disadvantage.
>
> Most of the fields to identify an instrument are optional if you are just trading equities. The Complex Instruments draft allows a way of creating a “shorthand” for long symbol descriptions like options. And instrument description size really isn’t that important, since an advantage of incremental book messages is that such things are identified by a (hopefully) short BookEntryID, and one can use RefBookEntryID to avoid repeating descriptions.
>
> Separating these messages at the application layer is possible as well. For instance, in the case of sending unsolicited incremental Book messages by IP multicast, it would make sense to have different IP multicast groups for equity and option quotes.
>
> > My second suggestion is that the date and time fields should be collapsed to a single datetime field.
>
> This is a rather controversial issue. The major approaches I’ve seen recommended are:
>
> 1. Use one datetime field. Disadvantage is that it is long.
>
> 2. Use a date field and a create a time-only field. The date field if not present would be assumed to be the current day, so you’ve cut down on bandwidth.
>
> 3. Use a date field (which if not present is assumed to be the current day) and an integer for seconds past midnight. Disadvantage is complexity, and one needs to define whether the epoch is midnight GMT/UTC or midnight of the time zone of the person sending the book message.
>
> There’s also the issue of sending sub-second times.
>
> My belief is that #2 is the best approach because it can be concise, and it is the easiest to expand to include a decimal point and milliseconds, since no such time type exists in FIX.
>
> > My third suggestion is that the fields BookEntryType, BookEntryDirection, BookEntryStatus and IsBestBidOffer be collapsed into a single BookFlags field. The purpose is to save bandwidth. With the current specification it might take as many as 7 characters to convey a single bit of information. In the flags, OPEN would default. Not IsBestBidOffer would also be the default.
>
> I believe BookEntryType needs to stay separated, as it is a required enumeration crucial to further processing. Validation of FIX messages by engines is often based on the presence of required fields; such engines would be able to catch a missing BookEntryType, but a lack of a Bid, Ask, or Trade enumeration in a BookEntryFlags field containing other flags would not be caught.
>
> BookEntryType may also contain one or more Closing / Settlement price indications, as I believe Paul Lindley at LIFFE suggested adding them.
>
> I see no problem with combining BookEntryDirection, BookEntryStatus, and IsBestBidOffer into a flags field. The question becomes how to represent multiple objects; one way in FIX is to use repeating fields, but this eliminates any space savings. Would a space-delimited field be acceptable?
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I believe #1 is the best solution for dealing with the time. Prior to 4.0 we had separate date and time fields with date being assumed or derived in some cases. This became difficult especially for 24 hour trading which most of us are or will soon be dealing with. Technically you can’t have a point in time without a date reference. To assume what that date reference is becomes quite risky. I can appreciate the byte savings, but in general think we should avoid breaking this apart. The request/requirement for subseconds has been brought forward and would/could affect many other messages and likely the overall format of our time data type.
The problem with this approach is that it forces anyone who wishes to send a time with a book entry to send 9 extra bytes each time a book entry changes. This can become a significant overhead; for instance changing a price on a book entry, using just a time, would look like:
016=123456[SOH]017=1[SOH]008=54.125[SOH]011=09:35:12[SOH]
I chopped the leading 5 off the tags as these would be assigned 3-digit IDs for production use, and am assuming a 6-digit BookEntryID. That’s 41 bytes for the price change update. Adding 9 more bytes is a 22% increase in size.
I agree that order traffic must require both a date and time. But orders are larger, so the added overhead is not nearly as significant, the volume of orders per session is generally significantly lower than the market data generated by an exchange or ECN, and the costs of mistakes with orders generally is higher than for market data.
Keeping the fields separate allows the cautious person to send the date, at only 5 additional bytes more overhead per book entry associated with the adding the field. If I were implementing a 24-hour system and wanted to be cautious, I would start sending dates with the Book Entries 5 minutes prior to midnight UTC and stop sending dates 5 minutes after midnight UTC.
> > My third suggestion is that the fields BookEntryType, BookEntryDirection, BookEntryStatus and IsBestBidOffer be collapsed into a single BookFlags field. The purpose is to save bandwidth. With the current specification it might take as many as 7 characters to convey a single bit of information. In the flags, OPEN would default. Not IsBestBidOffer would also be the default.
>
> I believe BookEntryType needs to stay separated, as it is a required enumeration crucial to further processing. Validation of FIX messages by engines is often based on the presence of required fields; such engines would be able to catch a missing BookEntryType, but a lack of a Bid, Ask, or Trade enumeration in a BookEntryFlags field containing other flags would not be caught.
>
> BookEntryType may also contain one or more Closing / Settlement price indications, as I believe Paul Lindley at LIFFE suggested adding them.
>
> I see no problem with combining BookEntryDirection, BookEntryStatus, and IsBestBidOffer into a flags field. The question becomes how to represent multiple objects; one way in FIX is to use repeating fields, but this eliminates any space savings. Would a space-delimited field be acceptable?
>
>
I would suggest concatenating 1 character values for each piece of information.
0,1,2,3 for BookEntryDirection,
O (oh), C for BookEntryStatus,
YN for IsBestBidOffer
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I would suggest concatenating 1 character values for each piece of information.
> 0,1,2,3 for BookEntryDirection,
> O (oh), C for BookEntryStatus,
> YN for IsBestBidOffer
This approach only allows for up to 36 flags (letters + digits) and doesn’t allow for user-defined flags. I suggest space delimited for this reason, with U* being user-defined.
I doubt people will combine that many flags together. Even if both direction and best bid/offer is specified, a space delimited field wastes only 1 byte.
Ryan