Eurex EBS : default key names

, ,
1

Imported from previous forum

2

[ original email was from Nathan Kidd - nkidd@nmkconsulting.co.uk ]
Hi,

I’m currently working on a port of our C++ decoder from CME FAST to Eurex EBS. There appears to be something different happening with the default key names for the Eurex global dictionary.

Multiple EBS templates contain the same field, for example “prodId”. However, different templates are applying different operators to this key - sometimes its DEFAULT, sometimes NOOP, sometimes COPY, etc, all for the same prodId string field.

Our dictionaries aren’t currently implemented to allow a change of operator for a key after it is initially contructed.

Before I start making tweaks, I was hopeing someone could verify which of the following is the correct solution:

  1. Allow different operators to be applied to the same key and previous value as retrieved from the dictionary.

  2. Append the operator to my keyname, (so key becomes “prodId_copy” for example), and thereby each key maintains the current implementation where one key can only have one operator applied to it.

  3. Something different :slight_smile:

Many thanks in advance for any advice!

Cheers,
Nathan

3

[ original email was from Harold Cox - marketonclose@yahoo.com ]
The compression is by field irrespective of operator, so the previous values should be keyed only by field name. It just happens to work for the CME templates as they all use the same operator per field at least on my quick inspection.

Hi,

I’m currently working on a port of our C++ decoder from CME FAST to
Eurex EBS. There appears to be something different happening with the
default key names for the Eurex global dictionary.

Multiple EBS templates contain the same field, for example “prodId”.
However, different templates are applying different operators to this
key - sometimes its DEFAULT, sometimes NOOP, sometimes COPY, etc, all
for the same prodId string field.

Our dictionaries aren’t currently implemented to allow a change of
operator for a key after it is initially contructed.

Before I start making tweaks, I was hopeing someone could verify which
of the following is the correct solution:

  1. Allow different operators to be applied to the same key and previous
    value as retrieved from the dictionary.

  2. Append the operator to my keyname, (so key becomes “prodId_copy” for
    example), and thereby each key maintains the current implementation
    where one key can only have one operator applied to it.

  3. Something different :slight_smile:

Many thanks in advance for any advice!

Cheers, Nathan

4

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

There is no defined constraint on the operators defined for a “field” in FAST1.1.
FAST is all about compression and squeezing that extra bit of business information in a network message.

Eurex EnBS took a pragmatic approach for applying operators to fields. Take for instance your example for “prodId”. The Product Reference Message the prodId follows the copy operator and for the Single Leg Reference it follows copy operator. The reason being there is only one message for product in “product reference” and many single leg instruments per product in “single leg reference” message. This ensures that the complexity of processing due to FAST operators is balanced by the actual compression of the data.

To reiterate FAST protocol leaves it to the application designer to use the power of FAST as per the application requirements and does not put any constraints on the field operator associations.

Hope I am clear.

I would support option 1 from your suggestions below.

Regards,

Hi,

I’m currently working on a port of our C++ decoder from CME FAST to
Eurex EBS. There appears to be something different happening with the
default key names for the Eurex global dictionary.

Multiple EBS templates contain the same field, for example “prodId”.
However, different templates are applying different operators to this
key - sometimes its DEFAULT, sometimes NOOP, sometimes COPY, etc, all
for the same prodId string field.

Our dictionaries aren’t currently implemented to allow a change of
operator for a key after it is initially contructed.

Before I start making tweaks, I was hopeing someone could verify which
of the following is the correct solution:

  1. Allow different operators to be applied to the same key and previous
    value as retrieved from the dictionary.

  2. Append the operator to my keyname, (so key becomes “prodId_copy” for
    example), and thereby each key maintains the current implementation
    where one key can only have one operator applied to it.

  3. Something different :slight_smile:

Many thanks in advance for any advice!

Cheers, Nathan

5

[ original email was from Nathan Kidd - nkidd@nmkconsulting.co.uk ]

Many thanks for the confirmation, all looks good now!

Hi Nathan,

There is no defined constraint on the operators defined for a “field” in
FAST1.1. FAST is all about compression and squeezing that extra bit of
business information in a network message.

Eurex EnBS took a pragmatic approach for applying operators to fields.
Take for instance your example for “prodId”. The Product Reference
Message the prodId follows the copy operator and for the Single Leg
Reference it follows copy operator. The reason being there is only one
message for product in “product reference” and many single leg
instruments per product in “single leg reference” message. This ensures
that the complexity of processing due to FAST operators is balanced by
the actual compression of the data.

To reiterate FAST protocol leaves it to the application designer to use
the power of FAST as per the application requirements and does not put
any constraints on the field operator associations.

Hope I am clear.

I would support option 1 from your suggestions below.

Regards,

Hi,

I’m currently working on a port of our C++ decoder from CME FAST to
Eurex EBS. There appears to be something different happening with the
default key names for the Eurex global dictionary.

Multiple EBS templates contain the same field, for example “prodId”.
However, different templates are applying different operators to this
key - sometimes its DEFAULT, sometimes NOOP, sometimes COPY, etc, all
for the same prodId string field.

Our dictionaries aren’t currently implemented to allow a change of
operator for a key after it is initially contructed.

Before I start making tweaks, I was hopeing someone could verify which
of the following is the correct solution:

  1. Allow different operators to be applied to the same key and
    previous value as retrieved from the dictionary.

  2. Append the operator to my keyname, (so key becomes “prodId_copy”
    for example), and thereby each key maintains the current
    implementation where one key can only have one operator applied to it.

  3. Something different :slight_smile:

Many thanks in advance for any advice!

Cheers, Nathan