Imported from previous forum
Hi,
I’ve been working with a development partner [Onix Solutions - who I am very pleased with]
for the past few months getting a CME FAST Market Data feed developed for internal use.
I am at the stage where I would like to test if flaws exist or if the code is production ready.
What do others do at this point? In other industries I have seen tests where X input gives Y
output and through a series of tests all possible scenarios are tested.
What I have done so far is approach the problem along OSI lines.
I have checked the multicast & TCP transport layers by building a tool that reads in the
TCP Replay logs & UDP multicast Incremental logs and searches for the lowest and highest
[tag 34] sequence numbers, it then checks all sequence numbers between the two are
present. This has been very helpful in debugging transport layer issues and through its use
I am happy the transport is reliable & stable.
What I now need is to test the order book and general trade reporting logic. I have logins for
AutoCert/+ and I do plan to go down this route, though unless I am mistaken I saw that as
something you did at the end to demonstrate compliance, not as a debugging tool per-say.
Just curious what others have done at this point in the project/development life cycle.
Warm regards,
Justin
Hi,
[snip]
Just curious what others have done at this point in the
project/development life cycle.Warm regards,
Justin
Well, for me, when I was at this point of the life cycle, I did two things. I wrote a simple listener that dumps out the aggregate market data, and compared it against the legacy RLC data stream, for differences (as it turns out, there are noticeable data sequence diffs). Two, I recorded some packets and played back using a simulator (so to speak), and look at how the system how respond on various semantic errors (out of sequence, failed recovery, etc).
I don’t know how much this will help. But so far this simple process has done well for the various changes, not just for CME, over the years.