Imported from previous forum
I would like to propose a “lite” subset of the FAST protocol.
The complete proposal can be found at :
http://www.fastliteproposal.com
I am unfamiliar with the procedure for submitting proposals to FPL, and
so I have created a discussion thread and also emailed the proposal to
the working group.
This proposal is an attempt to reach-out to those organisations who
have not adopted, or perhaps only partially adopted the FAST protocol,
possibly due to its perceived complexity ?
I very much hope that it “hits the mark”. But, if it does not,
then I think at the very least it will provide some ideas for the next
iteration of FAST.
The proposal has not yet been reviewed and so I welcome all feedback.
Hi Patrick,
thank you for sharing your ideas.
It seems to me that your proposal is not a subset, but rather an alternative protocol that uses design elements from FAST.
For example, the wire protocol as well as basic design elements (like the pmap) are different in your proposal.
Would you care to summarize the what you aim to subset in terms of features in FAST that would be absent in a lite version. Then we can discuss how a subset FAST could look like.
There has been discussion previously about subsetting and I believe the sentiment at the time was that subsets would create a potential problem with product compatibility in real life.
For the time being, we try to keep the existing protocol as simple as possible. Hence the current discussion about the 1.2 proposal.
Best,
Rolf
I would like to propose a “lite” subset of the FAST protocol. The
complete proposal can be found at :http://www.fastliteproposal.com
I am unfamiliar with the procedure for submitting proposals to FPL,
and so I have created a discussion thread and also emailed the
proposal to the working group.This proposal is an attempt to reach-out to those organisations who
have not adopted, or perhaps only partially adopted the FAST
protocol, possibly due to its perceived complexity ?I very much hope that it “hits the mark”. But, if it does not, then
I think at the very least it will provide some ideas for the next
iteration of FAST.The proposal has not yet been reviewed and so I welcome all feedback.
Hi Rolf,
I will gladly explain the differences between FAST and my proposal and identify those parts that I have attempted to subset. I agree that it is not a pure subset, the Nmap for example is an addition.
I will add a comparison section to the front of the proposal document.
Scott Atwell was kind enough to explain the proposal submission procedure to me, and there are several stages prior to public
review. Whilst I am still intersted in feedback, anyone outside of
the working group should clearly delay any review until the
request is formally made.
Thanks again for taking the time to read the proposal.
Patrick
Hi Patrick,
thank you for sharing your ideas.
It seems to me that your proposal is not a subset, but rather an
alternative protocol that uses design elements from FAST.For example, the wire protocol as well as basic design elements (like
the pmap) are different in your proposal.Would you care to summarize the what you aim to subset in terms of
features in FAST that would be absent in a lite version. Then we can
discuss how a subset FAST could look like.There has been discussion previously about subsetting and I believe the
sentiment at the time was that subsets would create a potential problem
with product compatibility in real life.For the time being, we try to keep the existing protocol as simple as
possible. Hence the current discussion about the 1.2 proposal.Best, Rolf
I would like to propose a “lite” subset of the FAST protocol. The
complete proposal can be found at :http://www.fastliteproposal.com
I am unfamiliar with the procedure for submitting proposals to FPL,
and so I have created a discussion thread and also emailed the
proposal to the working group.This proposal is an attempt to reach-out to those organisations who
have not adopted, or perhaps only partially adopted the FAST protocol,
possibly due to its perceived complexity ?I very much hope that it “hits the mark”. But, if it does not, then I
think at the very least it will provide some ideas for the next
iteration of FAST.The proposal has not yet been reviewed and so I welcome all feedback.
Hi Patrick,
I’m looking forward to the summary of differences section.
For the continued discussion, I would like to suggest that we let “FAST subset” imply that “a FAST subset stream can be encoded/decoded by a standard FAST encoder/decoder”
Best,
Rolf
Hi Rolf,
I will gladly explain the differences between FAST and my proposal and
identify those parts that I have attempted to subset. I agree that it is
not a pure subset, the Nmap for example is an addition. I will add a
comparison section to the front of the proposal document.Scott Atwell was kind enough to explain the proposal submission
procedure to me, and there are several stages prior to public review.
Whilst I am still intersted in feedback, anyone outside of the
working group should clearly delay any review until the request is
formally made.Thanks again for taking the time to read the proposal.
Patrick
Hi Rolf,
I was thinking the same thing over breakfast this morning and so I have
to agree with you.
In addition I agree with your suggestion that the name should
change from FastLite to FLITE. I think that end users would expect FAST
Lite to be wire protocol compliant with FAST. I will therefore change
the title of the proposal.
Patrick
Hi Patrick,
I’m looking forward to the summary of differences section.
For the continued discussion, I would like to suggest that we let “FAST
subset” imply that “a FAST subset stream can be encoded/decoded by a
standard FAST encoder/decoder”Best, Rolf
Hi Rolf,
I will gladly explain the differences between FAST and my proposal and
identify those parts that I have attempted to subset. I agree that it
is not a pure subset, the Nmap for example is an addition. I will add
a comparison section to the front of the proposal document.Scott Atwell was kind enough to explain the proposal submission
procedure to me, and there are several stages prior to public review.
Whilst I am still intersted in feedback, anyone outside of the
working group should clearly delay any review until the request is
formally made.Thanks again for taking the time to read the proposal.
Patrick
Draft 0.0.2 is now available from…
http://www.fastliteproposal.com
Patrick
Hi Rolf,
I was thinking the same thing over breakfast this morning and so I have
to agree with you.In addition I agree with your suggestion that the name should change
from FastLite to FLITE. I think that end users would expect FAST Lite to
be wire protocol compliant with FAST. I will therefore change the title
of the proposal.Patrick
Hi Patrick,
I’m looking forward to the summary of differences section.
For the continued discussion, I would like to suggest that we let
“FAST subset” imply that “a FAST subset stream can be encoded/decoded
by a standard FAST encoder/decoder”Best, Rolf
Hi Rolf,
I will gladly explain the differences between FAST and my proposal
and identify those parts that I have attempted to subset. I agree
that it is not a pure subset, the Nmap for example is an addition. I
will add a comparison section to the front of the proposal document.Scott Atwell was kind enough to explain the proposal submission
procedure to me, and there are several stages prior to public
review. Whilst I am still intersted in feedback, anyone outside of
the working group should clearly delay any review until the request
is formally made.Thanks again for taking the time to read the proposal.
Patrick
Patrick,
after a quick analysis of the four current FAST production feeds (CME, Eurex, ISE, ARCA) as well as the FAST-like OPRA feed, my conclusion is that the Omap+Nmap construct is less efficient than the FAST Pmap construct.
I’ve also tried to figure out if it’s possible to simplify the implementation of Omap+Nmap versus Pmap, but I have so far not been able to show any improvement from a complexity or performance point of view.
We spent a lot of time analyzing the use patterns of optional fields before suggesting the NULL value approach and I come to the same conclusion after this round of analysis.
I may have missed some opportunities here (wouldn’t be the first nor the last time:), so it’s time for the rest of you to chip in.
Best,
Rolf
Draft 0.0.2 is now available from…
http://www.fastliteproposal.com
Patrick
Hi Rolf,
I was thinking the same thing over breakfast this morning and so I
have to agree with you.In addition I agree with your suggestion that the name should change
from FastLite to FLITE. I think that end users would expect FAST Lite
to be wire protocol compliant with FAST. I will therefore change the
title of the proposal.Patrick
Hi Patrick,
I’m looking forward to the summary of differences section.
For the continued discussion, I would like to suggest that we let
“FAST subset” imply that “a FAST subset stream can be
encoded/decoded by a standard FAST encoder/decoder”Best, Rolf
Hi Rolf,
I will gladly explain the differences between FAST and my proposal
and identify those parts that I have attempted to subset. I agree
that it is not a pure subset, the Nmap for example is an addition.
I will add a comparison section to the front of the proposal
document.Scott Atwell was kind enough to explain the proposal submission
procedure to me, and there are several stages prior to public
review. Whilst I am still intersted in feedback, anyone outside of
the working group should clearly delay any review until the
request is formally made.Thanks again for taking the time to read the proposal.
Patrick