When to issue a FastAlert?

, ,
1

Imported from previous forum

2

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
It is recommended that FastAlert is used before terminating a session to indicate the cause of termination.

I wonder how strong this recommenation is. Is it feasible to inherit the behaviour from FIX for the scenario when a FastHello1 (and perhaps FixLogon as well) is received with unauthenticated sessioncredentials described in Fix 4.4 Spec vol 2 page 29 and not sending a FastAlert before terminating.

Thanks,
Henrik

3

You can shut down the TCP session without a FastAlert, but that
makes it hard for the other end to ascertain the cause of the
termination.

Using FastAlert will provide better error handling and debugging
capabilities.

Just out of curiosity, is there a specific reason that you’d
want to skip sending a FastAlert?

Thx,
Rolf

It is recommended that FastAlert is used before terminating a
session to indicate the cause of termination.

I wonder how strong this recommenation is. Is it feasible to
inherit the behaviour from FIX for the scenario when a FastHello1
(and perhaps FixLogon as well) is received with unauthenticated
session credentials described in Fix 4.4 Spec vol 2 page 29 and
not sending a FastAlert before terminating.

Thanks, Henrik

4

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
The only reason is to follow the FIX Spec as closely as possible and that FAST is aglined to that as long as there is no ‘FAST-specific’ reason not to follow FIX.

By that, I believe that the perception of FAST by clients will be improved.

/Henrik

You can shut down the TCP session without a FastAlert, but that makes it
hard for the other end to ascertain the cause of the termination.

Using FastAlert will provide better error handling and debugging
capabilities.

Just out of curiosity, is there a specific reason that you’d want to
skip sending a FastAlert?

Thx, Rolf

It is recommended that FastAlert is used before terminating a session
to indicate the cause of termination.

I wonder how strong this recommenation is. Is it feasible to inherit
the behaviour from FIX for the scenario when a FastHello1 (and perhaps
FixLogon as well) is received with unauthenticated session credentials
described in Fix 4.4 Spec vol 2 page 29 and not sending a FastAlert
before terminating.

Thanks, Henrik

5

Oh, I see what you’re getting at.

FAST should be viewed as a separate (lower) layer.

The FastAlert is loosely modelled after alerts in SSL.

The intent is not to use the FastAlert mechanism to convey
application layer (such as FIX) indications.

The FIX layer of your application should ideally not be aware
of the FAST layer.

There are (and will be) other application layer protocols
running on top of FAST.

In my view, the absence of a FIXAlert is somewhat of a
deficiency, but that’s a different story.

/Rolf

The only reason is to follow the FIX Spec as closely as possible
and that FAST is aglined to that as long as there is no
‘FAST-specific’ reason not to follow FIX.

By that, I believe that the perception of FAST by clients will be
improved.

/Henrik