Need pcap file for MDP 3.0

[webus...@gmail.com]

Is there any place I can a pcap file for the entire day, or an hour or smaller for the new CME MDP3.0 feed. I would like to write a parser for it and would love to have packet captured data 

[Chris Aseltine]

Why would you need to write a parser if you don't have access to the data?

[webus...@gmail.com]

I will have access to the data. But writing a parser will take a few months and I would not have to pay for hosting and CME license fees if I can avoid it. 

[Chris Aseltine]

I don't think you're going to find anyone willing to openly violate the MDLA.  And by the way, if it's going to take you a few months to write the parser, you're in the wrong line of work.

[webus...@gmail.com]

The pcap files does not have to be lice trading data. It could also be from their test instances? So anyone who wants to write a MDP 3.0 decoder has to license the full real time feed? Is there no way to do it on the cheap?

Maybe you can help me understand how much time it should take for someone in the "correct line of work" to write a good parser with code generation from the fix templates.

[Chris Aseltine]

Your supposed need to write a decoder is incongruous with your lack of access to the data or the New Release environment.

And uh, I dunno, a week?

[webus...@gmail.com]

If it's only a week effort, any chance I can convince you to write the parser for me? How do I contact you?

[Lanre Sarumi]

Webuser1200, I presume that's your real name. I see you've already met straight talking Chris :-)

You can always get the test data from CME cert environment. If you or someone in your firm trades on globex you should be able to get access to cert at no charge. If not you can still contact the CME and they may give you access. If not your last option is to use a reference implementation of SBE to build your feed handler. It won't be the fastest but will parse the data just fine. 

As for length of time to complete a "production grade" feed handler, 4 to 6 weeks is about right. No one does it  any sooner starting from scratch. They may be able to write code to parse the data even vend it but it's most likely not production grade. At least not one that handles the edge cases. 

--
You received this message because you are subscribed to the Google Groups "quickfast_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quickfast_use...@googlegroups.com.
To post to this group, send email to quickfa...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quickfast_users/ab025692-6383-421b-8958-fb0bb12b41de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[webus...@gmail.com]

Thanks Larne for pitching in. Nice to know that there is no cost to get access to the CME cert environment. That  seems like the way to move forward ...

 

I don't need to be the fastest for now. So the reference implementation of SBE should be fine. Is this the only one:

https://github.com/real-logic/simple-binary-encoding

I will read through the documentation. But at a very high level:

1. I would run the reference SBE on the CME template files and it will generate classes to handle all the different message template ids

2. I would write the code that connects to the multicast stream a and b and passes the received packets over to SBE. I would also handle the case where a packet or more might be dropped. 

3. Take the messages parsed by SBE and normalize them and push them to my application

Do you know how much slower the SBE reference implementation might be compared to a custom written highly performant parser?

[la...@ijebu.com]

The real logic/informatica is the only one i know of. Then again i have not spent a lot of time looking for others. It's also the one the CME mentions in marketing docs so you should be in good shape.

If this is your first attempt at writing this i say just go ahead and use that implementation. Once you get it working right then focus on optimization. Treat the parser like an adapter and you can easily switch out later.

I have seen too many people that get their knickers in a knot obsessing over the fastest parser only to screw up the advantage in the code they write over it. You can easily make nonsense of the time saved by using the best parser in the world if you then screw up managing the book. lockfree, spinlocks, mutex, zero copy... you choice could impact performance.

Take quickfast for example, I know a guy that spent weeks optimizing his copy and then he decides TCP is the best way to vend the data.

Some will take quickfast and covert to actual FIX messages prior to normalizing to their structure. Outside of software some will use the built in ethernet others will use solarflare. some will run X windows etc. you get my point.

To view this discussion on the web visit https://groups.google.com/d/msgid/quickfast_users/5acef158-7fa1-42d2-b152-91407b7367d1%40googlegroups.com.

[Malcolm Spence]

He has a point.

 

“Tick to trade” is a series of steps, each one has to bear in mind the succession of activities and what is best to do in each step.

 

Just FYI OCI wrote the QuickFAST code, Liquibook and OpenDDS the RT data distribution service. We build out low latency, deterministic frameworks for weapons systems, telco switching or financial systems. We wrote Bloomberg’s Bpipe for example.

 

We give away the software but sell our expertise for those who really need it.

 

Feel free to contact us if you need help building out your systems.

 

regards Malcolm

 

Malcolm D. Spence
Director of Business Development
Object Computing, Inc. St. Louis MO USA

"Use our reach to exceed your grasp."
(Phone 1- 314-579-0066 ext. 206 or FAX -0065)
www.theaceorb.com www.ociweb.com

www.opendds.org www.quickfast.org

To view this discussion on the web visit https://groups.google.com/d/msgid/quickfast_users/20140914204737.b0ecb0578f02630ba36c6b01fb2e82fe.9fcad2e687.wbe%40email18.secureserver.net.

[Dale Wilson]

One of the stated rules for this mailing list is

    Discussions should be civil and on-topic

There have been a few messages recently that I consider borderline. 
Please be respectful of each other in the messages you send on this list.

Dale