Imported from previous forum
Hi, I have a general question on how to handle numeric fields when sending FIX over FAST. FIX specifies that a numeric field (such as BodyLength) is represented as an ASCII string. FAST encoder will send this field as binary (32-bit integer), and the decoder will decode it back into the ASCII string. Yet, in all likelihood, the receiver needs to interpret such field as a numeric field anyway, thus yielding another string->binary conversion. Thus, there are 2 extra data conversions per message which will have negative performance implications.
For performance critical applications, does it not make sense to break the FIX specification of using ASCII representation for numeric fields and specify them as binary (uInt32) instead? I understand that this breaks true interoperability of FIX over FAST, but as long as both the sender and receiver are aware that they need to interpret numeric fields as binary, would there be any issues?
Thanks,
Dimitry
Hi Dimitry,
this is a very relevant question.
I believe that we will see more and more implementations that translate directly from an internal representation (used by the FIX engine implementation) to FAST and from FAST to an internal representation without ever passing through the classic FIX ASCII-oriented tag=value representation.
The sender and the reciever don’t even have to agree on the internal representations as their common representation is FAST.
As for your specific example, BodyLength, it doesn’t have to be transferred but can be calculated by the receiver.
You may want to transfer the BodyLength as an integrity check, but that is another issue, It’s not strictly needed to decode the FAST message back to FIX.
Best,
Rolf
Hi, I have a general question on how to handle numeric fields when
sending FIX over FAST. FIX specifies that a numeric field (such as
BodyLength) is represented as an ASCII string. FAST encoder will
send this field as binary (32-bit integer), and the decoder will
decode it back into the ASCII string. Yet, in all likelihood, the
receiver needs to interpret such field as a numeric field anyway,
thus yielding another string->binary conversion. Thus, there are 2
extra data conversions per message which will have negative
performance implications.For performance critical applications, does it not make sense to
break the FIX specification of using ASCII representation for
numeric fields and specify them as binary (uInt32) instead? I
understand that this breaks true interoperability of FIX over
FAST, but as long as both the sender and receiver are aware that
they need to interpret numeric fields as binary, would there be
any issues?Thanks, Dimitry
Thanks, Rolf.
Perhaps, MDEntryPx is the better example than BodyLength as it always needs to be transferred over network. The price will very likely be used for calculations and it makes sense to treat it as a binary numeric field everywhere rather than perform unnecessary conversion to the FIX ASCII format.
Cheers,
Dimitry
Hi Dimitry,
this is a very relevant question.
I believe that we will see more and more implementations that translate
directly from an internal representation (used by the FIX engine
implementation) to FAST and from FAST to an internal representation
without ever passing through the classic FIX ASCII-oriented tag=value
representation.The sender and the reciever don’t even have to agree on the internal
representations as their common representation is FAST.As for your specific example, BodyLength, it doesn’t have to be
transferred but can be calculated by the receiver.You may want to transfer the BodyLength as an integrity check, but that
is another issue, It’s not strictly needed to decode the FAST message
back to FIX.Best, Rolf
Hi, I have a general question on how to handle numeric fields when
sending FIX over FAST. FIX specifies that a numeric field (such as
BodyLength) is represented as an ASCII string. FAST encoder will send
this field as binary (32-bit integer), and the decoder will decode it
back into the ASCII string. Yet, in all likelihood, the receiver needs
to interpret such field as a numeric field anyway, thus yielding
another string->binary conversion. Thus, there are 2 extra data
conversions per message which will have negative performance
implications.For performance critical applications, does it not make sense to break
the FIX specification of using ASCII representation for numeric fields
and specify them as binary (uInt32) instead? I understand that this
breaks true interoperability of FIX over FAST, but as long as both the
sender and receiver are aware that they need to interpret numeric
fields as binary, would there be any issues?Thanks, Dimitry
Agreed, I know of at least one implementation that doesn’t go
via FIX ASCII format but rather convert directly to internal
format.
What is your intended use case?
/Rolf
Thanks, Rolf.
Perhaps, MDEntryPx is the better example than BodyLength as it
always needs to be transferred over network. The price will very
likely be used for calculations and it makes sense to treat it
as a binary numeric field everywhere rather than perform
unnecessary conversion to the FIX ASCII format.Cheers, Dimitry
Hi Dimitry,
this is a very relevant question.
I believe that we will see more and more implementations that
translate directly from an internal representation (used by the FIX
engine implementation) to FAST and from FAST to an internal
representation without ever passing through the classic FIX ASCII-
oriented tag=value representation.The sender and the reciever don’t even have to agree on the internal
representations as their common representation is FAST.As for your specific example, BodyLength, it doesn’t have to be
transferred but can be calculated by the receiver.You may want to transfer the BodyLength as an integrity check, but
that is another issue, It’s not strictly needed to decode the FAST
message back to FIX.Best, Rolf
Hi, I have a general question on how to handle numeric fields when
sending FIX over FAST. FIX specifies that a numeric field (such as
BodyLength) is represented as an ASCII string. FAST encoder will
send this field as binary (32-bit integer), and the decoder will
decode it back into the ASCII string. Yet, in all likelihood, the
receiver needs to interpret such field as a numeric field anyway,
thus yielding another string->binary conversion. Thus, there are 2
extra data conversions per message which will have negative
performance implications.For performance critical applications, does it not make sense to
break the FIX specification of using ASCII representation for
numeric fields and specify them as binary (uInt32) instead? I
understand that this breaks true interoperability of FIX over FAST,
but as long as both the sender and receiver are aware that they need
to interpret numeric fields as binary, would there be any issues?Thanks, Dimitry
The use case is to provide the numeric data in the most efficient manner which is why I strongly feel that the conversion to and from ASCII is unnecessary and should be avoided. It sounds that we are the same page, thanks a lot for your detailed answers.
Dimitry
Agreed, I know of at least one implementation that doesn’t go via FIX
ASCII format but rather convert directly to internal format.What is your intended use case?
/Rolf
Thanks, Rolf.
Perhaps, MDEntryPx is the better example than BodyLength as it always
needs to be transferred over network. The price will very likely be
used for calculations and it makes sense to treat it as a binary
numeric field everywhere rather than perform unnecessary conversion to
the FIX ASCII format.Cheers, Dimitry
Hi Dimitry,
this is a very relevant question.
I believe that we will see more and more implementations that
translate directly from an internal representation (used by the FIX
engine implementation) to FAST and from FAST to an internal
representation without ever passing through the classic FIX ASCII-
oriented tag=value representation.The sender and the reciever don’t even have to agree on the internal
representations as their common representation is FAST.As for your specific example, BodyLength, it doesn’t have to be
transferred but can be calculated by the receiver.You may want to transfer the BodyLength as an integrity check, but
that is another issue, It’s not strictly needed to decode the FAST
message back to FIX.Best, Rolf
Hi, I have a general question on how to handle numeric fields when
sending FIX over FAST. FIX specifies that a numeric field (such as
BodyLength) is represented as an ASCII string. FAST encoder will
send this field as binary (32-bit integer), and the decoder will
decode it back into the ASCII string. Yet, in all likelihood, the
receiver needs to interpret such field as a numeric field anyway,
thus yielding another string->binary conversion. Thus, there are 2
extra data conversions per message which will have negative
performance implications.For performance critical applications, does it not make sense to
break the FIX specification of using ASCII representation for
numeric fields and specify them as binary (uInt32) instead? I
understand that this breaks true interoperability of FIX over
FAST, but as long as both the sender and receiver are aware that
they need to interpret numeric fields as binary, would there be
any issues?Thanks, Dimitry