Imported from previous forum
[ original email was from Steven Grossman - steven.grossman@transacttools.net ]
Why is the SCP Reset message defined by way of an attribute of a template definition instead of remaining a standalone message as it was in SCP 1.0? Template reset seems to be an attribute of a FAST session rather than an attribute of an individual template. It feels unnatural to define it together with one’s template definitions.
Furthermore, defining a template as ‘resetting’ implies knowledge of its use within a particular transport. The choice of a ‘resetting’ template over a ‘non-resetting’ one would likely be determined based on how (stream or packet) and when (head of packet or middle of packet) the message would be sent. Should a FAST encoder be responsible for having this knowledge?
Steven
Why is the SCP Reset message defined by way of an attribute of a
template definition instead of remaining a standalone message as it was
in SCP 1.0? Template reset seems to be an attribute of a FAST session
rather than an attribute of an individual template. It feels unnatural
to define it together with one’s template definitions.
No, it’s a property of the individual template. Just as all other properties that effects the state of the dictionaries.
The resetting of dictionaries has really nothing to do with a session from a processing point of view, and pointing out a particular message application type and template identifier as having a hard-coded behaviour makes it sort of a strange animal. The reset property should really have been defined in the core FAST Specification.
Furthermore, defining a template as ‘resetting’ implies knowledge of its
use within a particular transport. The choice of a ‘resetting’ template
over a ‘non-resetting’ one would likely be determined based on how
(stream or packet) and when (head of packet or middle of packet) the
message would be sent. Should a FAST encoder be responsible for having
this knowledge?
It is not required to, and if it does not want to have this knowledge, it can use the Reset (and Hello, see my other post).
/David
[ original email was from Steven Grossman - steven.grossman@transacttools.net ]
> > Why is the SCP Reset message defined by way of an attribute of a
template definition instead of remaining a standalone message as it
was in SCP 1.0? Template reset seems to be an attribute of a FAST
session rather than an attribute of an individual template. It feels
unnatural to define it together with one’s template definitions.No, it’s a property of the individual template. Just as all other
properties that effects the state of the dictionaries.
The difference is that the template itself has no direct need for the reset behavior. It is the session that is layered upon the set of templates that requires it.
The resetting of dictionaries has really nothing to do with a session
from a processing point of view,
I don’t understand this point. Isn’t it the session that determines the need to reset?
and pointing out a particular message
application type and template identifier as having a hard-coded
behaviour makes it sort of a strange animal.
Why do you find this strange? Isn’t that the nature of messaging - send a message to elicit a response? In this case, the response is a dictionary reset.
Furthermore, defining a template as ‘resetting’ implies knowledge of
its use within a particular transport. The choice of a ‘resetting’
template over a ‘non-resetting’ one would likely be determined based
on how (stream or packet) and when (head of packet or middle of
packet) the message would be sent. Should a FAST encoder be
responsible for having this knowledge?It is not required to, and if it does not want to have this knowledge,
it can use the Reset (and Hello, see my other post).
I’m questioning the ability to intertwine layers rather than the choice an implementor makes of whether or not to do so.
The difference is that the template itself has no direct need for the
reset behavior. It is the session that is layered upon the set of
templates that requires it.
[…]
The resetting of dictionaries has really nothing to do with a session
from a processing point of view,I don’t understand this point. Isn’t it the session that determines the
need to reset?
The session is just one possible “user” of the reset property. It is not a one to one relation. Furthermore, the effect of resetting dictionaries is defined in the core spec and so should the mechanism for signaling it have been.
and pointing out a particular message application type and template
identifier as having a hard-coded behaviour makes it sort of a
strange animal.Why do you find this strange? Isn’t that the nature of messaging - send
a message to elicit a response? In this case, the response is a
dictionary reset.
It is unnatural because dictionary state, including resetting, is an intrinsic part of the encoding but is not part of a particular application message layer.
I’m questioning the ability to intertwine layers rather than the choice
an implementor makes of whether or not to do so.
An implmentation may always intertwine layers. The causes may differ. In some cases it is just a bad implementation. In others it is a conscious optimization.
/David
[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi
I looked at the section 5.2.2.2 The Reset Property of the FAST SCP Draft 1.1.04 again.
I understand that the FAST Rest message from SCP 1.00 is not being removed.
The proposal is to add a new property to the FAST templates in SCP 1.1.
The decoder is expected to clear the dictionaries for all templates which have the reset property set to true. This should be done irrespective of whether explicit FAST reset message is sent.
The explicit template reset using the FAST Reset message should still work.
Darshan
The difference is that the template itself has no direct need for the
reset behavior. It is the session that is layered upon the set of
templates that requires it.[…]
The resetting of dictionaries has really nothing to do with a
session from a processing point of view,I don’t understand this point. Isn’t it the session that determines
the need to reset?The session is just one possible “user” of the reset property. It is not
a one to one relation. Furthermore, the effect of resetting dictionaries
is defined in the core spec and so should the mechanism for signaling it
have been.and pointing out a particular message application type and template
identifier as having a hard-coded behaviour makes it sort of a
strange animal.Why do you find this strange? Isn’t that the nature of messaging -
send a message to elicit a response? In this case, the response is a
dictionary reset.It is unnatural because dictionary state, including resetting, is an
intrinsic part of the encoding but is not part of a particular
application message layer.I’m questioning the ability to intertwine layers rather than the
choice an implementor makes of whether or not to do so.An implmentation may always intertwine layers. The causes may differ. In
some cases it is just a bad implementation. In others it is a conscious
optimization./David
Yes, that’s correct.
What the reset property actually does in the case of the 1.1 Reset message is that it relieves its message type from any special semantics. The fact that it is resetting (just as 1.1 Hello is per the latest draft) is just a consequence of that the predefined template sets the reset property.
This only affects how it is defined. On the wire, a 1.1 Reset will be identical to a 1.0 Reset: c0 f8.
/David
Hi
I looked at the section 5.2.2.2 The Reset Property of the FAST SCP Draft
1.1.04 again.I understand that the FAST Rest message from SCP 1.00 is not being
removed. The proposal is to add a new property to the FAST templates in
SCP 1.1. The decoder is expected to clear the dictionaries for all
templates which have the reset property set to true. This should be done
irrespective of whether explicit FAST reset message is sent.The explicit template reset using the FAST Reset message should
still work.Darshan