Imported from previous forum
From the spec: A presence map is overlong if it has more than seven bits and ends in seven or more bits that are all zero.
Also from the spec: Logically a presence map has an infinite suffix of zeroes. This makes it possible to truncate a presence map that ends in a sequence where the bits are all zero.
So assuming I have 12 fields, and the last 7 fields are not in the message (lets assume they are all copy), I would have a PMAP:
111110000000
So… I don’t understand how to detect if a PMAP if overlong, and if a
message correctly has more than 7 fields and it happens the last 7 fields of the message are not in the message (they are implied by the PMAP) I would incorrectly flag the PMAP as overlong!
Reportable Error R8 takes care of the PMAP having the exact representation (lenght wise) of the Template. So it can’t be that…
I don’t know when Reportable Error R7 (PMAP is Overlong) happens. Can anyone shed some light on this issue please?
Fernando,
I think you confuse the pmap contents in the encoder and decoder programs versus what is actually transferred on the wire.
Using your example: 111110000000
This is what you have in one form or the other in your program.
I’m using s|ddddddd notation below, where ‘s’ is the stop bit and ‘d’ are the seven data bits.
On the wire, 0|1111100 1|0000000 would be an overlong representation.
(more than one group of 7 bits, the last group having all zeroes)
(IIRC R7 may be reported by the decoder when it receives an overlong pmap wire representation)
The correct wire representation is 1|1111100 (0xFC)
On decoding this wire representation, the decoder should extend (possibly logically) the pmap to contain enough zero bits for the message to be decoded (in this case 5 zero bits).
I’ll defer to David to discuss any further intriguing details of reportable errors.
Hope this helps,
Rolf
From the spec: A presence map is overlong if it has more than
seven bits and ends in seven or more bits that are all zero.Also from the spec: Logically a presence map has an infinite
suffix of zeroes. This makes it possible to truncate a presence
map that ends in a sequence where the bits are all zero.So assuming I have 12 fields, and the last 7 fields are not in the
message (lets assume they are all copy), I would have a PMAP:
111110000000So… I don’t understand how to detect if a PMAP if overlong, and if a
message correctly has more than 7 fields and it happens the last 7
fields of the message are not in the message (they are implied by the
PMAP) I would incorrectly flag the PMAP as overlong!Reportable Error R8 takes care of the PMAP having the exact
representation (lenght wise) of the Template. So it can’t be that…I don’t know when Reportable Error R7 (PMAP is Overlong) happens. Can
anyone shed some light on this issue please?
Of course, the truncate means that the message “should” be truncated… I got fixated on the “infinite” part and overlong, and completely missed about that.
I think the issue is that the spec hints at the possibility of the message being truncated, but it doesn’t say that you have to truncate it:
“This makes it possible to truncate…”
I would rather have it reading:
“This makes it necessary to truncate…”
Thanks!
Fernando
Fernando,
I think you confuse the pmap contents in the encoder and decoder
programs versus what is actually transferred on the wire.Using your example: 111110000000 This is what you have in one form or
the other in your program.I’m using s|ddddddd notation below, where ‘s’ is the stop bit and ‘d’
are the seven data bits.On the wire, 0|1111100 1|0000000 would be an overlong representation.
(more than one group of 7 bits, the last group having all zeroes) (IIRC
R7 may be reported by the decoder when it receives an overlong pmap wire
representation)The correct wire representation is 1|1111100 (0xFC)
On decoding this wire representation, the decoder should extend
(possibly logically) the pmap to contain enough zero bits for the
message to be decoded (in this case 5 zero bits).I’ll defer to David to discuss any further intriguing details of
reportable errors.Hope this helps, Rolf
From the spec: A presence map is overlong if it has more than seven
bits and ends in seven or more bits that are all zero.Also from the spec: Logically a presence map has an infinite suffix of
zeroes. This makes it possible to truncate a presence map that ends in
a sequence where the bits are all zero.So assuming I have 12 fields, and the last 7 fields are not in the
message (lets assume they are all copy), I would have a PMAP:
111110000000So… I don’t understand how to detect if a PMAP if overlong, and if a
message correctly has more than 7 fields and it happens the last 7
fields of the message are not in the message (they are implied by the
PMAP) I would incorrectly flag the PMAP as overlong!Reportable Error R8 takes care of the PMAP having the exact
representation (lenght wise) of the Template. So it can’t be that…I don’t know when Reportable Error R7 (PMAP is Overlong) happens. Can
anyone shed some light on this issue please?
[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi Fernando,
Following the correct PMAP for your case:
1111110 only one byte with STOP bit.
Suppose you have the 8th bit set then you will have :
11111100 11000000
A PMAP overlong will be generated for the 1st case with 5 bits set if one sends:
01111100 10000000 => (R7)
- Darshan
From the spec: A presence map is overlong if it has more than seven bits
and ends in seven or more bits that are all zero.Also from the spec: Logically a presence map has an infinite suffix of
zeroes. This makes it possible to truncate a presence map that ends in a
sequence where the bits are all zero.So assuming I have 12 fields, and the last 7 fields are not in the
message (lets assume they are all copy), I would have a PMAP:
111110000000So… I don’t understand how to detect if a PMAP if overlong, and if a
message correctly has more than 7 fields and it happens the last 7
fields of the message are not in the message (they are implied by the
PMAP) I would incorrectly flag the PMAP as overlong!Reportable Error R8 takes care of the PMAP having the exact
representation (lenght wise) of the Template. So it can’t be that…I don’t know when Reportable Error R7 (PMAP is Overlong) happens. Can
anyone shed some light on this issue please?
Hi all,
Regarding Presence Map Overlong Property, according to spec
“Logically a presence map has an infinite suffix of zeroes. This makes it possible to truncate a presence map that ends in a sequence where the bits are all zero.”
and
“A presence map is overlong if it has more than seven bits and ends in seven or more bits that are all zero.”
As a receiver of FIX-FAST messages, whether overlong presence map might break the decoding?
e.g.
The correct wire representation is 1|1111100 and
overlong representation is 0|1111100 1|0000000.
Receiver is getting the overlong presence map. I think it should not break the decoding. Am I right?
Thanks & regards
Shashank
Hi Fernando,
Following the correct PMAP for your case: 1111110 only one byte
with STOP bit.Suppose you have the 8th bit set then you will have : 11111100 11000000
A PMAP overlong will be generated for the 1st case with 5 bits set if
one sends:01111100 10000000 => (R7)
- Darshan
From the spec: A presence map is overlong if it has more than seven
bits and ends in seven or more bits that are all zero.Also from the spec: Logically a presence map has an infinite suffix of
zeroes. This makes it possible to truncate a presence map that ends in
a sequence where the bits are all zero.So assuming I have 12 fields, and the last 7 fields are not in the
message (lets assume they are all copy), I would have a PMAP:
111110000000So… I don’t understand how to detect if a PMAP if overlong, and if a
message correctly has more than 7 fields and it happens the last 7
fields of the message are not in the message (they are implied by the
PMAP) I would incorrectly flag the PMAP as overlong!Reportable Error R8 takes care of the PMAP having the exact
representation (lenght wise) of the Template. So it can’t be that…I don’t know when Reportable Error R7 (PMAP is Overlong) happens. Can
anyone shed some light on this issue please?
e.g. The correct wire representation is 1|1111100 and overlong
representation is 0|1111100 1|0000000. Receiver is getting the
overlong presence map. I think it should not break the decoding.
Am I right?
You are correct. The an overlong PMAP does not prevent the decoder from producing the correct answer. For this reason, it is a “Reportable Error” not a “Dynamic Error”.
From the standard:
An error that is detected when encoding or decoding a FAST stream is referred to as either a dynamic or reportable error. Encoders and decoders must signal dynamic errors and are encouraged to signal reportable errors but may refrain from doing so.
Dale Wilson
Principal Software Engineer
Object Computing, Inc.
Hi Dale,
Thank you for clarification.