Imported from previous forum
I am looking for some feedback on how FIX and multicast of market data work together. I don’t see much usage of FIX in the multicast scenario. There is no need to logon and establish a session, and send a market data request as there is no fix message defined to tell what topic to subscribe. Moreover, since it is multicast, there is no way for each client to has its own subscription criteria. FIX market data related messages seems to me are only applied in the unitcast (tcp/ip) case.
I suggest you take a look at the CME and ISE FIX/FAST feeds.
Both use std FIX market data messages over IP multicast.
/Rolf
I am looking for some feedback on how FIX and multicast of market data
work together. I don’t see much usage of FIX in the multicast scenario.
There is no need to logon and establish a session, and send a market
data request as there is no fix message defined to tell what topic to
subscribe. Moreover, since it is multicast, there is no way for each
client to has its own subscription criteria. FIX market data related
messages seems to me are only applied in the unitcast (tcp/ip) case.
Yes, you are right. It is meaningless.
As an example take CME, it produces data (which you have no control over if you wanted best prices or trades for example) for 6 markets with its depth. Now, that is an equivalent to an entire output for another alternative futures exchange does for over 6000 markets. You guessed it couple of orders of magnitude lost in scalability, and as proven by TM !
As for FAST, it has been tested on meaningless and small sample data. Then it got ‘approved’ and story was sold of bandwidth and latency, wait for it: reduction! Hmm, what a marvelous achievement, but watch now as they’ll push the depth to 10…
Please note you have read the facts above right and can easily verify it for yourself. That is the equivalent volume in traffic you will get, FAST encoded, so FAST has little benefit to communication designs that are as bad; especially TCP tunneled UDP.
Then you get recovery nonsense as designed as it is, plus bundling of data you do not want, plus FAST, plus TCP mixed with FIX and FIXFast… oh dear. FAST stream is so prone to errors, one byte gone bad will make you wait a good while (in time, dev and money)…
FAST apart from introducing huge latency, another fact easily testable in production exchange data shows a requirement for thousands, sometimes 100s of thousands of messages a second. That is another matter; so it is clearly the worst protocol in existence for latency reinvented so far. Again, if you require data on this try it out with all the vendor products, consultant designers etc and see for yourself.
Then bundle the waste of ethernet frame as it is commonly done, bundle the dictionary requirements, bundle the over-engineered compression (that is so oddly further compressible), you get the no meaning in FIXING FAST fever forever… and voila, you get:
A clear disaster!
What’s more, it is a disaster that will keep having new versions! (you will pay for in bandwidth, smart-designs in latency, over-engineering, smart bandwidth/depth/subscription control, committee ‘sense’ and telecom resales on the ‘upgrade’ path).
An adopter, whether forced or not, really ought to be inexperienced and young to this industry not to be able to see the flaws from the outset of the fixprotocol.org. If it is of any reconciliation, all implementation lunacy, and fat too, eventually gets trimmed.
Good luck wasting a lot of resources though…
Regards,
Le Truth
Here we go again. Just in case someone wasted time by reading the post below, it is meaningless indeed. However, it should not stand without objection which I hereby submit.
Yes, you are right. It is meaningless.
As an example take CME, it produces data (which you have no control over
if you wanted best prices or trades for example) for 6 markets with its
depth. Now, that is an equivalent to an entire output for another
alternative futures exchange does for over 6000 markets. You guessed it
couple of orders of magnitude lost in scalability, and as proven by
TM !As for FAST, it has been tested on meaningless and small sample data.
Then it got ‘approved’ and story was sold of bandwidth and latency, wait
for it: reduction! Hmm, what a marvelous achievement, but watch now as
they’ll push the depth to 10…Please note you have read the facts above right and can easily verify it
for yourself. That is the equivalent volume in traffic you will get,
FAST encoded, so FAST has little benefit to communication designs that
are as bad; especially TCP tunneled UDP.Then you get recovery nonsense as designed as it is, plus bundling of
data you do not want, plus FAST, plus TCP mixed with FIX and FIXFast…
oh dear. FAST stream is so prone to errors, one byte gone bad will make
you wait a good while (in time, dev and money)…FAST apart from introducing huge latency, another fact easily testable
in production exchange data shows a requirement for thousands, sometimes
100s of thousands of messages a second. That is another matter; so it is
clearly the worst protocol in existence for latency reinvented so far.
Again, if you require data on this try it out with all the vendor
products, consultant designers etc and see for yourself.Then bundle the waste of ethernet frame as it is commonly done, bundle
the dictionary requirements, bundle the over-engineered compression
(that is so oddly further compressible), you get the no meaning in
FIXING FAST fever forever… and voila, you get:A clear disaster!
What’s more, it is a disaster that will keep having new versions! (you
will pay for in bandwidth, smart-designs in latency, over-engineering,
smart bandwidth/depth/subscription control, committee ‘sense’ and
telecom resales on the ‘upgrade’ path).An adopter, whether forced or not, really ought to be inexperienced and
young to this industry not to be able to see the flaws from the outset
of the fixprotocol.org. If it is of any reconciliation, all
implementation lunacy, and fat too, eventually gets trimmed.Good luck wasting a lot of resources though…
Regards, Le Truth