FIX Trading Community

 

 Remember me

Register  |   Lost password?

Inter-Party Latency WG

Discussions > Inter-Party Latency WG > IPL Message Specifications

IPL Message Specifications

Complete message thread from old site

FIX Trading Community
1262 days ago,(2010/11/09)

[ original email was from Mark Reece - mark.reece@hsbcib.com ]
I have just posted a first draft of the Message Specifications document, as actioned at the NY meeting last month. This is focused on the Version 1 scope defined at the meeting.

Please have a read and post any comments/thoughts/extensions etc. Or email me at mark.reece@hsbcib.com

At the end of the document are a couple questions/issues. I would be very interested in feedback on those.

Regards, Mark

Rolf Andersson
1244 days ago,(2010/11/28)

All,

I've played around with an impl of the spec:ed messages and they work fine for basic use. Obviously, the Connection Estab msg isn't strictly needed but I think it is a good idea to include it from the start to get a better process for meta data exchange.

I was planning to provide a simulated test stream and make it available for access via the Internet. This will probably not happen until after the New Year when we have moved to a new data center.

If anyone has a receiver impl in the works and you'd like to do some interoperability testing, let me know. I'm certainly interested in testing our receiver.

Moving over to the two open issues presented in the doc, as well as one not mentioned:

1. We should definitely plan for repeating groups as this will logically be a very common case. One alternative would be to use field encoding (similar or same as in FAST)

2. I used a fixed point timestamp format;
32 bits integer and 32 bits of fraction

3. The AppMsgID will need more than 32 bits in some situations.
Not sure how flexible we need to do this. We could use different message types or version for different AppMsgID formats.
This also ties in with repeating groups;
Do we want to mix different AppMsgID formats in the same msg?

4. The MsgType and MsgVersion will be invariant for a lot of messages in a specific stream. We may later want to combine them in some way to conserve space.

My $.02
/Rolf

> I have just posted a first draft of the Message Specifications
> document, as actioned at the NY meeting last month. This is
> focused on the Version 1 scope defined at the meeting.
>
> Please have a read and post any comments/thoughts/extensions etc.
> Or email me at mark.reece@hsbcib.com
>
> At the end of the document are a couple questions/issues.
> I would be very interested in feedback on those.
>
> Regards, Mark

Rolf Andersson
1244 days ago,(2010/11/28)

reading my own post I realized that I skipped commenting on the timestamp format question:

> 2. I used a fixed point timestamp format;
> 32 bits integer and 32 bits of fraction

I suggest that we support (at least) three formats:
1. UNIX timeval - 32-bit secs since epoch + 32-bit usec offset
2. 64-bit nsec since epoch
3. fixed point 32-bit secs since epoch + 32-bit fraction of sec

with the format used specified in the ServiceProvider IPL document.

/Rolf

Nikhil Bagga
1226 days ago,(2010/12/15)

With regards to - single vs. multiple measurements within a single message:
* if the process that generates this message is the same as the process that is handling the orderflow then I would suggest multiple measurements as that would give the developers a little more flexibility and allow then to choose order flow as a higher priority over latency measurement
* if the measurements and the transmission of the same is being handled by an 'out-of-band' process then I would suggest sticking with the simple implementation

> reading my own post I realized that I skipped commenting on the timestamp format question:
>
> > 2. I used a fixed point timestamp format;
> > 32 bits integer and 32 bits of fraction
>
> I suggest that we support (at least) three formats:
> 1. UNIX timeval - 32-bit secs since epoch + 32-bit usec offset
> 2. 64-bit nsec since epoch
> 3. fixed point 32-bit secs since epoch + 32-bit fraction of sec
>
> with the format used specified in the ServiceProvider IPL document.
>
> /Rolf

Rolf Andersson
1226 days ago,(2010/12/16)

I believe the 'out-of-band' variant will be more common, but we will still want to have multiple measurements in a message to minimize resource utilization.

/Rolf

> With regards to - single vs. multiple measurements within a single message:
> * if the process that generates this message is the same as the process that is handling the orderflow then I would suggest multiple measurements as that would give the developers a little more flexibility and allow then to choose order flow as a higher priority over latency measurement
> * if the measurements and the transmission of the same is being handled by an 'out-of-band' process then I would suggest sticking with the simple implementation