FAST protocole with EUREX EBS

, ,
1

Imported from previous forum

2

Hello,

I am working on EUREX EBS reception and now i am faced with the decoding of the messages with the fast codec.
I found a template on the EUREX reference site, but it seems to be wrong as I have the error message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception and decoding do you know if it is available (like openfast project in java)

Thanks a lot,

3

[ original email was from Michael Li - sjmk.li@gmail.com ]
Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml template file. After you decode the message, you can manually check if id==120, and reset the dictionary before jump to the next message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is not fully compliant with FAST spec. Chances are that you have to make some changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the decoding
of the messages with the fast codec. I found a template on the EUREX
reference site, but it seems to be wrong as I have the error message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception and
decoding do you know if it is available (like openfast project in java)

Thanks a lot,

4

Hello,
thanks for the answer I will try to do what you say.

Regards,

Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml
template file. After you decode the message, you can manually check if
id==120, and reset the dictionary before jump to the next message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is not
fully compliant with FAST spec. Chances are that you have to make some
changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the
decoding of the messages with the fast codec. I found a template on
the EUREX reference site, but it seems to be wrong as I have the error
message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

5

Hi Maarek,

Dimitry London of Morgan Stanley was planning to contribute an open C++ implementation of a FAST API, but I don’t know the current status.

Dimitry, if you read this, could you provide us with an update?

/Rolf

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

6

Hi Rolf/Maarek,

our C++ implementation is still currently under legal review. I am hoping to resolve all open issues by the end of August.

Dimitry

Hi Maarek,

Dimitry London of Morgan Stanley was planning to contribute an open C++
implementation of a FAST API, but I don’t know the current status.

Dimitry, if you read this, could you provide us with an update?

/Rolf

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

7

[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi Micheal,

Could you please list out the areas where Eurex EBS is incompatible to FAST protocol.
I will pass on the information to the developers and corrections may be rolled out in the next update.

Regards,

Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml
template file. After you decode the message, you can manually check if
id==120, and reset the dictionary before jump to the next message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is not
fully compliant with FAST spec. Chances are that you have to make some
changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the
decoding of the messages with the fast codec. I found a template on
the EUREX reference site, but it seems to be wrong as I have the error
message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

8

[ original email was from Michael Li - sjmk.li@gmail.com ]
Hi Sorry for the confusion. I intended to say that Eurex EBS is not compatible with FAST spec 1.0, and free many FAST decoder is only FAST 1.0 compatible.

Michael

Hi Micheal,

Could you please list out the areas where Eurex EBS is incompatible to
FAST protocol. I will pass on the information to the developers and
corrections may be rolled out in the next update.

Regards,

Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml
template file. After you decode the message, you can manually check if
id==120, and reset the dictionary before jump to the next message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is not
fully compliant with FAST spec. Chances are that you have to make some
changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the
decoding of the messages with the fast codec. I found a template on
the EUREX reference site, but it seems to be wrong as I have the
error message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

9

no worries, that explains it.

As a background for other readers:
Darshan and the team at Deutsche Börse has spent considerable effort to design a high quality 1.1 compliant implementation and as far as I know every aspect of their design follows the 1.1 spec.

They followed the general recommendation from the mdowg to base their implementation on the FAST 1.1 specification. The 1.0 specification leaves a number of issues open to interpretation and is therefore less suitable to design to.

(if you find the 1.1 spec complex; You can provide subset designs that are limited in functionality, while still following the 1.1 spec)

There are a few 1.0-based impls out there, the earliest one being the ARCA FAST feed. It was designed even before the FAST 1.0 specification had been published. The impl was done by Kevin Mueller, Fred Jones and the dev team at ARCA with assistance from Daniel May of Spryware.

Even though the ARCA FAST feed is a lot simpler than some of the later feeds, it shows how careful design work can create good results (even if the FAST 1.0 spec was silent on some aspects). The ARCA feed is still both 1.0 and 1.1 compliant.

For those of you that are considering to design a feed based on the FAST 1.1 specification; Please don’t hesitate to ask for advice, clarifications, and a second opinion on any aspect that you are considering for your design. You can either post to the forum (so that anyone can chip in and other benefit from your question and any answers that follow) or mail one of us directly if you would like to get some feedback off-line.

HTH,
Rolf

Hi Sorry for the confusion. I intended to say that Eurex EBS is not
compatible with FAST spec 1.0, and free many FAST decoder is only FAST
1.0 compatible.

Michael

Hi Micheal,

Could you please list out the areas where Eurex EBS is incompatible to
FAST protocol. I will pass on the information to the developers and
corrections may be rolled out in the next update.

Regards,

Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml
template file. After you decode the message, you can manually check
if id==120, and reset the dictionary before jump to the next
message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is
not fully compliant with FAST spec. Chances are that you have to
make some changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the
decoding of the messages with the fast codec. I found a template
on the EUREX reference site, but it seems to be wrong as I have
the error message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast project
in java)

Thanks a lot,

10

Hello,

Thanks you for all these explanations.
As explained I am trying to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is provided and if I understand well, as it is compatible with 1.0 implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not refrenced in 1.0 release of the fast specification.

So my question is : is this a good solution to modify the fastapi 1.0 implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks,
Antony

no worries, that explains it.

As a background for other readers: Darshan and the team at Deutsche
Börse has spent considerable effort to design a high quality 1.1
compliant implementation and as far as I know every aspect of their
design follows the 1.1 spec.

They followed the general recommendation from the mdowg to base their
implementation on the FAST 1.1 specification. The 1.0 specification
leaves a number of issues open to interpretation and is therefore less
suitable to design to.

(if you find the 1.1 spec complex; You can provide subset designs that
are limited in functionality, while still following the 1.1 spec)

There are a few 1.0-based impls out there, the earliest one being the
ARCA FAST feed. It was designed even before the FAST 1.0 specification
had been published. The impl was done by Kevin Mueller, Fred Jones and
the dev team at ARCA with assistance from Daniel May of Spryware.

Even though the ARCA FAST feed is a lot simpler than some of the later
feeds, it shows how careful design work can create good results (even if
the FAST 1.0 spec was silent on some aspects). The ARCA feed is still
both 1.0 and 1.1 compliant.

For those of you that are considering to design a feed based on the FAST
1.1 specification; Please don’t hesitate to ask for advice,
clarifications, and a second opinion on any aspect that you are
considering for your design. You can either post to the forum (so that
anyone can chip in and other benefit from your question and any answers
that follow) or mail one of us directly if you would like to get some
feedback off-line.

HTH, Rolf

Hi Sorry for the confusion. I intended to say that Eurex EBS is not
compatible with FAST spec 1.0, and free many FAST decoder is only FAST

  1. compatible.

Michael

Hi Micheal,

Could you please list out the areas where Eurex EBS is incompatible
to FAST protocol. I will pass on the information to the developers
and corrections may be rolled out in the next update.

Regards,

Hi,

The template Id 120 in Eurex EBS means reset. It is not in the xml
template file. After you decode the message, you can manually
check if id==120, and reset the dictionary before jump to the next
message.

I don’t see there is a free Eurex EBS decoder. In addition, EBS is
not fully compliant with FAST spec. Chances are that you have to
make some changes to your code to make it work with EBS.

Michael

Hello,

I am working on EUREX EBS reception and now i am faced with the
decoding of the messages with the fast codec. I found a template
on the EUREX reference site, but it seems to be wrong as I have
the error message :

“The template with id 120 has not been registered”

when I try to decode. Do you have an idea?

I also search for C++ implementation of the EBS & FAST reception
and decoding do you know if it is available (like openfast
project in java)

Thanks a lot,

11

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as the original FAST 1.0 specification. We haven’t updated the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be implemented in a straight-forward manner. It was never meant to be used in production and there are better ways of implementing the features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in production have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features into the original code base will require substantially more resources than it took to write the fastapi in the first place. Some of the 1.1 features are actually hard to support within the fastapi design.

For example, some of the decimal operator combinations result in a varying number of pmap slots being used in a specific message. As a result, the static pmap slots of fastapi-1.0 will not work out of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0
    as mentioned above there are a number of shortcomings in fastapi-1.0. You need to handle those and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall design
    you can use the basic mechanisms in fastapi-1.0 but redesign the api to support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec
    pls see comments above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation
    Dimitry London of Morgan Stanley is in the process of releasing a C++ library that they have written.

  5. Consider using the openfast implementation
    It’s Java, so it may not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against.
For 1-3, make sure to use the forum and mdowg to get advice.

Good luck,
Rolf

Hello,

Thanks you for all these explanations. As explained I am trying
to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is
provided and if I understand well, as it is compatible with 1.0
implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not refrenced
in 1.0 release of the fast specification.

So my question is : is this a good solution to modify the fastapi
1.0 implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

12

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop from scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than C or C++ to develop, but I wonder if the performance will be as good as in C or C++.

Do you have information on this performances compared to C or C++ implementations ?

Thanks,
Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as the
original FAST 1.0 specification. We haven’t updated the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in
testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be
implemented in a straight-forward manner. It was never meant to be used
in production and there are better ways of implementing the features
included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in production
have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features into the
original code base will require substantially more resources than it
took to write the fastapi in the first place. Some of the 1.1 features
are actually hard to support within the fastapi design.

For example, some of the decimal operator combinations result in a
varying number of pmap slots being used in a specific message. As
a result, the static pmap slots of fastapi-1.0 will not work out
of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there are a
    number of shortcomings in fastapi-1.0. You need to handle those and
    probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall design you
    can use the basic mechanisms in fastapi-1.0 but redesign the api to
    support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec pls see comments above
    on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry London of
    Morgan Stanley is in the process of releasing a C++ library that they
    have written.

  5. Consider using the openfast implementation It’s Java, so it may not
    be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against. For 1-3,
make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am trying to
implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is
provided and if I understand well, as it is compatible with 1.0
implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not refrenced in
1.0 release of the fast specification.

So my question is : is this a good solution to modify the fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

13

Hi Antony,

even if you would use the fastapi as a start, most of the work is still left for you to finish. From my own experience with FAST, testing alone takes a lot of time because of all the features in the std. We’ve spent man-years on our C++ impl and we continue to spend a lot of time tuning and enhancing it.

I don’t have any performance numbers for the openfast impl, but get in contact with Jim or Jacob at LasalleTech to see what they have in terms of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop from
scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than C or
C++ to develop, but I wonder if the performance will be as good as
in C or C++.

Do you have information on this performances compared to C or C++
implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as the
original FAST 1.0 specification. We haven’t updated the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in
testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be
implemented in a straight-forward manner. It was never meant to be
used in production and there are better ways of implementing the
features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in production
have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features into
the original code base will require substantially more resources than
it took to write the fastapi in the first place. Some of the 1.1
features are actually hard to support within the fastapi design.

For example, some of the decimal operator combinations result in a
varying number of pmap slots being used in a specific message. As a
result, the static pmap slots of fastapi-1.0 will not work out of
the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there are a
    number of shortcomings in fastapi-1.0. You need to handle those and
    probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall design
    you can use the basic mechanisms in fastapi-1.0 but redesign the
    api to support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec pls see comments
    above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry London of
    Morgan Stanley is in the process of releasing a C++ library that
    they have written.

  5. Consider using the openfast implementation It’s Java, so it may not
    be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against. For 1-3,
make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am trying to
implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is
provided and if I understand well, as it is compatible with 1.0
implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not refrenced in

  1. release of the fast specification.

So my question is : is this a good solution to modify the fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

14

Hello,

OK I see that I am faced with a huge work!
What is the product you have developped?
Is it compatible with EUREX EBS?
If yes what are the terms of the licence and do you have a kind of “evaluation version” to understand what it provides exactly.

Thanks,

Hi Antony,

even if you would use the fastapi as a start, most of the work is still
left for you to finish. From my own experience with FAST, testing alone
takes a lot of time because of all the features in the std. We’ve spent
man-years on our C++ impl and we continue to spend a lot of time tuning
and enhancing it.

I don’t have any performance numbers for the openfast impl, but get in
contact with Jim or Jacob at LasalleTech to see what they have in terms
of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop from
scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than C or
C++ to develop, but I wonder if the performance will be as good as in
C or C++.

Do you have information on this performances compared to C or C++
implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as the
original FAST 1.0 specification. We haven’t updated the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in
testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be
implemented in a straight-forward manner. It was never meant to be
used in production and there are better ways of implementing the
features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in
production have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features into
the original code base will require substantially more resources
than it took to write the fastapi in the first place. Some of the
1.1 features are actually hard to support within the fastapi design.

For example, some of the decimal operator combinations result in a
varying number of pmap slots being used in a specific message. As a
result, the static pmap slots of fastapi-1.0 will not work out of
the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there are a
    number of shortcomings in fastapi-1.0. You need to handle those
    and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall design
    you can use the basic mechanisms in fastapi-1.0 but redesign the
    api to support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec pls see comments
    above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry London of
    Morgan Stanley is in the process of releasing a C++ library that
    they have written.

  5. Consider using the openfast implementation It’s Java, so it may
    not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against. For 1-3,
make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am trying to
implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is
provided and if I understand well, as it is compatible with 1.0
implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not
refrenced in

  1. release of the fast specification.

So my question is : is this a good solution to modify the fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

15

[ original email was from Zoltan Vekony - zoltan.vekony@web.de ]
Hi,

here some ideas for your development:

  • You have mainly to deal two areas:
    a) decoding fast messages in form of datagrams
    b) build an infrastructure to receive multicast datagrams effectively

For the FAST decoding:

  • implement an efficient decoding engine (may be “hard coded”) without any dynamic for the best performance
  • Think also on the next versions (Eurex EBS 11 is coming soon)

I have written a “generator”, which takes the XML description, and produces effective C++ code for decoding the datagrams. You have to invest about 5 PDs for your development.

Bye
Zoltan

Hello,

OK I see that I am faced with a huge work! What is the product you have
developped? Is it compatible with EUREX EBS? If yes what are the terms
of the licence and do you have a kind of “evaluation version” to
understand what it provides exactly.

Thanks,

Hi Antony,

even if you would use the fastapi as a start, most of the work is
still left for you to finish. From my own experience with FAST,
testing alone takes a lot of time because of all the features in the
std. We’ve spent man-years on our C++ impl and we continue to spend a
lot of time tuning and enhancing it.

I don’t have any performance numbers for the openfast impl, but get in
contact with Jim or Jacob at LasalleTech to see what they have in
terms of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop from
scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than C or
C++ to develop, but I wonder if the performance will be as good as
in C or C++.

Do you have information on this performances compared to C or C++
implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as the
original FAST 1.0 specification. We haven’t updated the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in
testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be
implemented in a straight-forward manner. It was never meant to be
used in production and there are better ways of implementing the
features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in
production have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features
into the original code base will require substantially more
resources than it took to write the fastapi in the first place.
Some of the
1.1 features are actually hard to support within the fastapi
design.

For example, some of the decimal operator combinations result in a
varying number of pmap slots being used in a specific message. As
a result, the static pmap slots of fastapi-1.0 will not work out
of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there are
    a number of shortcomings in fastapi-1.0. You need to handle
    those and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall
    design you can use the basic mechanisms in fastapi-1.0 but
    redesign the api to support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec pls see comments
    above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry London
    of Morgan Stanley is in the process of releasing a C++ library
    that they have written.

  5. Consider using the openfast implementation It’s Java, so it may
    not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against. For
1-3, make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am trying
to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that is
provided and if I understand well, as it is compatible with 1.0
implementation I will have to modify it deeply. I am right?

Actually I noticed that EUREX is using many fields not refrenced
in

  1. release of the fast specification.

So my question is : is this a good solution to modify the
fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

16

Hello Zoltan,

You are right that’s what I wanted to do in a first step.
For the moment I make some adaptation to the fastapi in order to be able to decode EBS messages and I hard code the TAGS.
Does your “generator” transform the XML template into hard coded tags or does it also generates the code to decode ?

Do you share your “generator” code or is it a commercial one?

Thanks,
Antony

Hi,

here some ideas for your development:

  • You have mainly to deal two areas:
    a) decoding fast messages in form of datagrams
    b) build an infrastructure to receive multicast datagrams effectively

For the FAST decoding:

  • implement an efficient decoding engine (may be “hard coded”) without
    any dynamic for the best performance
  • Think also on the next versions (Eurex EBS 11 is coming soon)

I have written a “generator”, which takes the XML description, and
produces effective C++ code for decoding the datagrams. You have to
invest about 5 PDs for your development.

Bye Zoltan

Hello,

OK I see that I am faced with a huge work! What is the product you
have developped? Is it compatible with EUREX EBS? If yes what are the
terms of the licence and do you have a kind of “evaluation version” to
understand what it provides exactly.

Thanks,

Hi Antony,

even if you would use the fastapi as a start, most of the work is
still left for you to finish. From my own experience with FAST,
testing alone takes a lot of time because of all the features in the
std. We’ve spent man-years on our C++ impl and we continue to spend
a lot of time tuning and enhancing it.

I don’t have any performance numbers for the openfast impl, but get
in contact with Jim or Jacob at LasalleTech to see what they have in
terms of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop
from scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than C
or C++ to develop, but I wonder if the performance will be as good
as in C or C++.

Do you have information on this performances compared to C or C++
implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as
the original FAST 1.0 specification. We haven’t updated the api
since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks in
testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could be
implemented in a straight-forward manner. It was never meant to
be used in production and there are better ways of implementing
the features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in
production have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features
into the original code base will require substantially more
resources than it took to write the fastapi in the first place.
Some of the
1.1 features are actually hard to support within the fastapi
design.

For example, some of the decimal operator combinations result in
a varying number of pmap slots being used in a specific message.
As a result, the static pmap slots of fastapi-1.0 will not work
out of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there
    are a number of shortcomings in fastapi-1.0. You need to
    handle those and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall
    design you can use the basic mechanisms in fastapi-1.0 but
    redesign the api to support all of 1.1 in a more natural way.

  3. Roll your own - code directly to the 1.1 spec pls see
    comments above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry London
    of Morgan Stanley is in the process of releasing a C++
    library that they have written.

  5. Consider using the openfast implementation It’s Java, so it
    may not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against. For
1-3, make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am
trying to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that
is provided and if I understand well, as it is compatible with
1.0 implementation I will have to modify it deeply. I am
right?

Actually I noticed that EUREX is using many fields not
refrenced in

  1. release of the fast specification.

So my question is : is this a good solution to modify the
fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

17

[ original email was from Zoltan Vekony - zoltan.vekony@web.de ]
The generator generates the complete code. The application calls only processMessage(uint8_t buffer, uint32_t length) and all the work is made automatically. The generator is written in java and is not commercial. I have made some extensions in the xml template for better performace (for example the max. number of elements in sequences). The generator itself is very (!) EBS specific, there is no support for more dictionaries, and also not all the FAST operators are implemented (only what I need for EBS).

Bye
Zoltan

Hello Zoltan,

You are right that’s what I wanted to do in a first step. For the
moment I make some adaptation to the fastapi in order to be able to
decode EBS messages and I hard code the TAGS. Does your “generator”
transform the XML template into hard coded tags or does it also
generates the code to decode ?

Do you share your “generator” code or is it a commercial one?

Thanks, Antony

Hi,

here some ideas for your development:

  • You have mainly to deal two areas:
    a) decoding fast messages in form of datagrams
    b) build an infrastructure to receive multicast datagrams
    effectively

For the FAST decoding:

  • implement an efficient decoding engine (may be “hard coded”) without
    any dynamic for the best performance
  • Think also on the next versions (Eurex EBS 11 is coming soon)

I have written a “generator”, which takes the XML description, and
produces effective C++ code for decoding the datagrams. You have to
invest about 5 PDs for your development.

Bye Zoltan

Hello,

OK I see that I am faced with a huge work! What is the product you
have developped? Is it compatible with EUREX EBS? If yes what are
the terms of the licence and do you have a kind of “evaluation
version” to understand what it provides exactly.

Thanks,

Hi Antony,

even if you would use the fastapi as a start, most of the work is
still left for you to finish. From my own experience with FAST,
testing alone takes a lot of time because of all the features in
the std. We’ve spent man-years on our C++ impl and we continue to
spend a lot of time tuning and enhancing it.

I don’t have any performance numbers for the openfast impl, but
get in contact with Jim or Jacob at LasalleTech to see what they
have in terms of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop
from scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java than
C or C++ to develop, but I wonder if the performance will be as
good as in C or C++.

Do you have information on this performances compared to C or
C++ implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time as
the original FAST 1.0 specification. We haven’t updated the
api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0 lacks
in testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0 could
be implemented in a straight-forward manner. It was never
meant to be used in production and there are better ways of
implementing the features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in
production have spent considerable time on tuning and testing.

I estimate that the efforts to include all of the 1.1 features
into the original code base will require substantially more
resources than it took to write the fastapi in the first
place. Some of the
1.1 features are actually hard to support within the fastapi
design.

For example, some of the decimal operator combinations result
in a varying number of pmap slots being used in a specific
message. As a result, the static pmap slots of fastapi-1.0
will not work out of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above there
    are a number of shortcomings in fastapi-1.0. You need to
    handle those and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall
    design you can use the basic mechanisms in fastapi-1.0 but
    redesign the api to support all of 1.1 in a more natural
    way.

  3. Roll your own - code directly to the 1.1 spec pls see
    comments above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry
    London of Morgan Stanley is in the process of releasing a
    C++ library that they have written.

  5. Consider using the openfast implementation It’s Java, so it
    may not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against.
For 1-3, make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am
trying to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C that
is provided and if I understand well, as it is compatible
with

  1. implementation I will have to modify it deeply. I am
    right?

Actually I noticed that EUREX is using many fields not
refrenced in

  1. release of the fast specification.

So my question is : is this a good solution to modify the
fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

18

Hello Zoltan,

So would you share this development to help me in my comprehension of the FAST implementation?

Thanks,
Antony

The generator generates the complete code. The application calls only
processMessage(uint8_t buffer, uint32_t length) and all the work is
made automatically. The generator is written in java and is not
commercial. I have made some extensions in the xml template for better
performace (for example the max. number of elements in sequences). The
generator itself is very (!) EBS specific, there is no support for more
dictionaries, and also not all the FAST operators are implemented (only
what I need for EBS).

Bye Zoltan

Hello Zoltan,

You are right that’s what I wanted to do in a first step. For the
moment I make some adaptation to the fastapi in order to be able to
decode EBS messages and I hard code the TAGS. Does your “generator”
transform the XML template into hard coded tags or does it also
generates the code to decode ?

Do you share your “generator” code or is it a commercial one?

Thanks, Antony

Hi,

here some ideas for your development:

  • You have mainly to deal two areas:
    a) decoding fast messages in form of datagrams
    b) build an infrastructure to receive multicast datagrams
    effectively

For the FAST decoding:

  • implement an efficient decoding engine (may be “hard coded”)
    without any dynamic for the best performance
  • Think also on the next versions (Eurex EBS 11 is coming soon)

I have written a “generator”, which takes the XML description, and
produces effective C++ code for decoding the datagrams. You have to
invest about 5 PDs for your development.

Bye Zoltan

Hello,

OK I see that I am faced with a huge work! What is the product you
have developped? Is it compatible with EUREX EBS? If yes what are
the terms of the licence and do you have a kind of “evaluation
version” to understand what it provides exactly.

Thanks,

Hi Antony,

even if you would use the fastapi as a start, most of the work
is still left for you to finish. From my own experience with
FAST, testing alone takes a lot of time because of all the
features in the std. We’ve spent man-years on our C++ impl and
we continue to spend a lot of time tuning and enhancing it.

I don’t have any performance numbers for the openfast impl, but
get in contact with Jim or Jacob at LasalleTech to see what they
have in terms of test results.

/Rolf

Hello Rolf,

Thanks for such a quick answer.

As I am alone to develop, I think that the option to redevelop
from scratch is going to be very hard and long.

Concerning the java implementation, in fact I preafer java
than C or C++ to develop, but I wonder if the performance will
be as good as in C or C++.

Do you have information on this performances compared to C or
C++ implementations ?

Thanks, Antony

Hi Antony,

fastapi-1.0 was released in late 2005 around the same time
as the original FAST 1.0 specification. We haven’t updated
the api since.

There are no plans to provide a fastapi-1.1 version.

To be used for a FAST 1.1 feed the original fastapi-1.0
lacks in testing, performance and functionality.

fastapi-1.0 was implemented to demonstrate how FAST 1.0
could be implemented in a straight-forward manner. It was
never meant to be used in production and there are better
ways of implementing the features included in fastapi-1.0

My guess (and hope) is that the people using fastapi-1.0 in
production have spent considerable time on tuning and
testing.

I estimate that the efforts to include all of the 1.1
features into the original code base will require
substantially more resources than it took to write the
fastapi in the first place. Some of the
1.1 features are actually hard to support within the fastapi
design.

For example, some of the decimal operator combinations
result in a varying number of pmap slots being used in a
specific message. As a result, the static pmap slots of fastapi-
1.0 will not work out of the box.

AFAICS, you have several alternatives:

  1. Roll your own - extend fastapi-1.0 as mentioned above
    there are a number of shortcomings in fastapi-1.0. You
    need to handle those and probably modify the api

  2. Roll your own - use fastapi snippets, but not the overall
    design you can use the basic mechanisms in fastapi-1.0
    but redesign the api to support all of 1.1 in a more
    natural way.

  3. Roll your own - code directly to the 1.1 spec pls see
    comments above on the original fastapi-1.0 goals

  4. Wait for the Morgan Stanley C++ implementation Dimitry
    London of Morgan Stanley is in the process of releasing a
    C++ library that they have written.

  5. Consider using the openfast implementation It’s Java, so
    it may not be an option for you?

  6. Choose a commercial alternative

For 1-4,6 above, make sure to use openfast to test against.
For 1-3, make sure to use the forum and mdowg to get advice.

Good luck, Rolf

Hello,

Thanks you for all these explanations. As explained I am
trying to implement a FAST codec for EUREX EBS.

I have begun to analyse the fastapi implementation in C
that is provided and if I understand well, as it is
compatible with

  1. implementation I will have to modify it deeply. I am
    right?

Actually I noticed that EUREX is using many fields not
refrenced in

  1. release of the fast specification.

So my question is : is this a good solution to modify the
fastapi

  1. implementation, or is it better to start from scratch?

Do you have planed to provide such an implementation?

Thanks, Antony

19

[ original email was from Zoltan Vekony - zoltan.vekony@web.de ]
Yes, I will make some modifications for better readability at the weekend. Next week, I will send the code to you.

Zoltan

Hello Zoltan,

So would you share this development to help me in my comprehension of
the FAST implementation?

Thanks, Antony

20

thank you very much.
Could it be possible to have the current version even if not very “clean” because I will be on holidays next week and I would like to work on it this week end.

Thanks again for your help.

Yes, I will make some modifications for better readability at the
weekend. Next week, I will send the code to you.

Zoltan

Hello Zoltan,

So would you share this development to help me in my comprehension of
the FAST implementation?

Thanks, Antony