Imported from previous forum
In classic FIX protocol, it is required to send to the clients only the affected position of a particular bid/ask rather than all the affected entries. For example, for a new best bid which would require shifting all the other book entries down, only the new best bid with the position 1 would be sent. I understand that this is done mostly to save bandwidth. However, with the FAST, are these savings still important? The processing on the receiving side to perform such shifting may be quite complicated (and the same may be true on the sender’s side).
Thanks,
Dimitry
[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
> In classic FIX protocol, it is required to send to the clients only the
affected position of a particular bid/ask rather than all the affected
entries. For example, for a new best bid which would require shifting
all the other book entries down, only the new best bid with the position
1 would be sent. I understand that this is done mostly to save
bandwidth. However, with the FAST, are these savings still important?
The processing on the receiving side to perform such shifting may be
quite complicated (and the same may be true on the sender’s side).Thanks, Dimitry
Hi Dimitry,
FAST is a template based data compression technique that can be applied to any data content and not necessarily FIX. The FIX MarketDataIncrementalRefresh message sends only changes to the earlier sent information but the MarketDataSnapshotFullRefresh is used to send all the entries. If the application uses the snapshot approach then you can make substantial savings in the data bandwidth by designing templates that can optimally use the repetition in the data content. Although the FIX incremental message already reduces much of the data repetition by sending only changes, FAST further compresses the data when the repetition between more than one incremental updates are removed by the use of FAST operators.
Now days when applications send un-netted updates to the order book the resulting “change” volume itself is very large. FAST is a good solution that brings down the total bandwidth utilization of the system.
Thanks, but I mean specificcally Market Data Incremental Refresh and order book management. For example, assuming that a new best bid comes, and the book consists of 9 bids. The new bid will cause shifting the rest of the 9 MDEntries down. If all the changes are sent down - i.e. all 10 MDEntries, then it is every inefficient in the classic FIX, but, using FAST already yields bandwidth savings (i.e. only fields are sent, not the tags). My question is whether using FAST justifies sending all 10 MDEntries.
Dimitry
In classic FIX protocol, it is required to send to the clients only
the affected position of a particular bid/ask rather than all the
affected entries. For example, for a new best bid which would require
shifting all the other book entries down, only the new best bid with
the position 1 would be sent. I understand that this is done mostly to
save bandwidth. However, with the FAST, are these savings still
important? The processing on the receiving side to perform such
shifting may be quite complicated (and the same may be true on the
sender’s side).Thanks, Dimitry
Hi Dimitry,
FAST is a template based data compression technique that can be applied
to any data content and not necessarily FIX. The FIX
MarketDataIncrementalRefresh message sends only changes to the earlier
sent information but the MarketDataSnapshotFullRefresh is used to send
all the entries. If the application uses the snapshot approach then you
can make substantial savings in the data bandwidth by designing
templates that can optimally use the repetition in the data content.
Although the FIX incremental message already reduces much of the data
repetition by sending only changes, FAST further compresses the data
when the repetition between more than one incremental updates are
removed by the use of FAST operators. Now days when applications send
un-netted updates to the order book the resulting “change” volume itself
is very large. FAST is a good solution that brings down the total
bandwidth utilization of the system.
[ original email was from Bernt Sandén - bernt.sanden@omxgroup.com ]
Hi Dimitry,
You are referring to the implicit push/pop operations that apply for FIX Market Data Incremental. Those operations are a part of the application layer logic and must be followed if you whish to comply with the FIX standard. Sending all 10 MD Entries in your case would violate the FIX standard.
Regards, Bernt
Thanks, but I mean specificcally Market Data Incremental Refresh and
order book management. For example, assuming that a new best bid comes,
and the book consists of 9 bids. The new bid will cause shifting the
rest of the 9 MDEntries down. If all the changes are sent down - i.e.
all 10 MDEntries, then it is every inefficient in the classic FIX, but,
using FAST already yields bandwidth savings (i.e. only fields are sent,
not the tags). My question is whether using FAST justifies sending all
10 MDEntries.Dimitry
In classic FIX protocol, it is required to send to the clients only
the affected position of a particular bid/ask rather than all the
affected entries. For example, for a new best bid which would
require shifting all the other book entries down, only the new best
bid with the position 1 would be sent. I understand that this is
done mostly to save bandwidth. However, with the FAST, are these
savings still important? The processing on the receiving side to
perform such shifting may be quite complicated (and the same may be
true on the sender’s side).Thanks, Dimitry
Hi Dimitry,
FAST is a template based data compression technique that can be
applied to any data content and not necessarily FIX. The FIX
MarketDataIncrementalRefresh message sends only changes to the earlier
sent information but the MarketDataSnapshotFullRefresh is used to send
all the entries. If the application uses the snapshot approach then
you can make substantial savings in the data bandwidth by designing
templates that can optimally use the repetition in the data content.
Although the FIX incremental message already reduces much of the data
repetition by sending only changes, FAST further compresses the data
when the repetition between more than one incremental updates are
removed by the use of FAST operators. Now days when applications send
un-netted updates to the order book the resulting “change” volume
itself is very large. FAST is a good solution that brings down the
total bandwidth utilization of the system.
Thanks, Bernt.
Dimitry
Hi Dimitry,
You are referring to the implicit push/pop operations that apply for
FIX Market Data Incremental. Those operations are a part of the
application layer logic and must be followed if you whish to comply
with the FIX standard. Sending all 10 MD Entries in your case would
violate the FIX standard.Regards, Bernt
Thanks, but I mean specificcally Market Data Incremental Refresh and
order book management. For example, assuming that a new best bid
comes, and the book consists of 9 bids. The new bid will cause
shifting the rest of the 9 MDEntries down. If all the changes are sent
down - i.e. all 10 MDEntries, then it is every inefficient in the
classic FIX, but, using FAST already yields bandwidth savings (i.e.
only fields are sent, not the tags). My question is whether using FAST
justifies sending all 10 MDEntries.Dimitry
In classic FIX protocol, it is required to send to the clients
only the affected position of a particular bid/ask rather than all
the affected entries. For example, for a new best bid which would
require shifting all the other book entries down, only the new
best bid with the position 1 would be sent. I understand that this
is done mostly to save bandwidth. However, with the FAST, are
these savings still important? The processing on the receiving
side to perform such shifting may be quite complicated (and the
same may be true on the sender’s side).Thanks, Dimitry
Hi Dimitry,
FAST is a template based data compression technique that can be
applied to any data content and not necessarily FIX. The FIX
MarketDataIncrementalRefresh message sends only changes to the
earlier sent information but the MarketDataSnapshotFullRefresh is
used to send all the entries. If the application uses the snapshot
approach then you can make substantial savings in the data bandwidth
by designing templates that can optimally use the repetition in the
data content. Although the FIX incremental message already reduces
much of the data repetition by sending only changes, FAST further
compresses the data when the repetition between more than one
incremental updates are removed by the use of FAST operators. Now
days when applications send un-netted updates to the order book the
resulting “change” volume itself is very large. FAST is a good
solution that brings down the total bandwidth utilization of the
system.