[Css-csts] Issues with Buffered Data Delivery state table
Yves.Doat at esa.int
Yves.Doat at esa.int
Thu Sep 24 06:04:53 EDT 2009
Dear John,
On the 14.08.2009 you sent me a list of comments that I had to put on hold.
It's time for me to provide some answers to them. You will find below my
answers (in blue). Considering that some of the comments are digging deep
into the book, please consider that if needed we can take those points that
are unclear and address them in October.
Best regards
Yves
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288 Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________
==========================================================================================================================================
You wrote
I have been looking again at the state table for the BDD procedure in CSTSFW
R-0.19, and I have come across a number of issues:
1. The (pseudo) event ‘any conformant event’ entry in table 4-11
references section 4.5.3.2, which lists the notification types
inherited from the base NOTIFY operation as well as the BDD-specific
extensions. One of these notification-types is ‘end of data’. One could
infer that ‘end of data’ qualifies as ‘any conformant event’, and
therefore its occurrence would be handled as specified in row 7 of the
state. However, ‘end of data’ has its own row (6). Clearly, the intent
is that row 6 applies, but that might not be understood by the naïve
implementer.
2. Similarly, the notification types in 4.5.3.1 list ‘data discarded due
to excess backlog’. Again, one could infer that the discarding of the
data is itself an event that needs to be notified, but if ‘data
discarded due to excess backlog’ is substituted for ‘any conformant
event’ in the active column for row 7, the result is not what is
desired.
These two examples point up a flaw in defining events in terms of the
notifications that are emitted upon the occurrence of those events – it
can result in self-referencing loops in the logic. The problem can be
partially solved by removing the reference to 4.5.3.2 from the ‘any
conformant event’ entry in table 4-11. However, that leaves only paragraph
4.5.2.3.7 to “define” ‘any conformant event’, and 4.5.2.3.7 really only
defines synchronous insertion of notifications. It does not give a clue as
to what a “conformant” event might be. As I recall, what we really meant
“any conformant event” to mean was any event that a derived procedure
might add. I propose that:
a) The event ‘any conformant event’ be renamed ‘derived procedure
event’;
b) A new paragraph 4.5.2.3.9 be inserted between 4.5.2.3.8 and the
current 4.5.2.3.9:
“A derived procedure may define its own procedure-specific events. The
Service Provider such notify the User of every procedure-specific event
via a NOTIFY invocation with a notification-type that is unique to that
event.
NOTE - The specification of the derived procedure explicitly identifies
each procedure-specific event that is to be treated as a derived
procedure event, and identify the notification-type that is to be used
when that event occurs.”
c) The ‘derived procedure event’ entry in table 4-11 reference the
(new) paragraph 4.5.2.3.9, rather than 4.5.2.3.7.
d) Put requirements in the Guidelines that mandate that if new
notification-types are added to a NOTIFY operation, then the Behavior
section for the procedure explicitly identify the events that qualify
as ‘derived procedure event’.
My answer:
I agree with your proposed changes
I agree with the requirement proposed for the Guidelines.
==============================================
3. In the ‘production status change’ row of table 4-11, the Event column
entry concludes with “; ‘any other event’”. There is no ‘any other
event’ mentioned anywhere in the specification. This seems to be an
earlier version of ‘any conformant event’, but even so it should not be
grouped with production status change. The phrase should be deleted.
My answer:
I agree with your proposed changes
==============================================
4. ‘production status change’ and ‘derived procedure event’ (‘any
conformant event’) follow the convention for event names (single
quotation marks), but they are actually event group names, each
representing a set of actual events and notification types. It would be
easier to interpret the state table if there were a separate convention
for such group names. For example, <production status change> and
<derived procedure event>. These terms could then appear in the Event
Description References table with identification of the actual events
that they represent.
My answer:
I find the current syntax comprehensive enough and I am not sure we would
gain much in adding yet another convention, unless we add an additional table
for those grouped events with additional information. For the time being I do
not change the syntax.
==============================================
5. The ‘end of data’ entry in table 4-11 references paragraph 4.5.2.3.9.4.
Bullet (d) of 4.5.2.3.9.4 identifies one condition that qualifies as an
indication of end of data (“a TransferDataInvocation is retrieved with
a generation time that is later than the stop generation time in the
START invocation”). Bullet (c) of 4.5.2.3.9.4 implies that there might
be other such conditions (“a NotifyInvocation ‘end of data’ was
inserted into the transfer buffer”), but none are defined anywhere in
the BDD specification, leaving the implementer wondering if he’s
overlooked something. The ‘end of data’ entry in table 4-11 also
references paragraph 4.5.3.2.1.1.1, where bullet (c) defines ‘end of
data’ as “the Service Provider has no more data to send. This
notification is non-discardable”. This is a vague statement; what
condition(s), other than the one identified in 4.5.2.3.9.4 (d), might
constitute there being no more data to send? That is, how does a
Service Provider know that there’s no more data?
It may be that what constitutes end of data is specific to the derived
procedure. If that’s so, then there should be a requirement on the
derived procedure specification to define what “end of data” means in
the context of that derived procedure.
My answer:
I added the following text to the ‘end of data’ notification in 4.5.2.3.9.4
and 4.5.3.2.1.1.1: "The conditions triggering the ‘end of data’ insertion
shall be defined by the derived procedure".
==============================================
6. In the third paragraph of 4.5.1.2.2.2 (Recorded Buffer), bullet (d)
states: “Upon the occurrence of any of several events that cause a
change to or disruption of the data being provided, the Service
Provider stores a synchronous notification of the event in the buffer.
The notification is a NOTIFY invocation. The notification is stored
into the buffer after the last data acquired before the event and
before the first data acquired following the event. The events
notified and associated information that are stored shall be as defined
in 4.5.3.2.” A strict interpretation of this statement is that all
event notifications specified in 5.5.3.2 are to be stored in the
recorded buffer. This cannot be true, because the recorded buffer is
shared by all service instances (bullet (b)) and some of the
notifications are service instance specific. I.e., when data is
discarded by a real-time mode service instance, the resulting
notification must be sent to only the user of that service instance
(putting it in the recorded buffer would cause it to be sent via all
instances). Likewise, an ‘end of data’ notification triggered by the
retrieval of a TransferDataInvocation with a generation time that is
outside the bounds of the service instance applies only to that service
instance and must not be put in the recorded buffer.
The situation is complicated by the fact that the state table is for
the procedure (and thus a particular service instance), but some of the
actions that are attributed to those procedures are actually performed
by the service production that is common to all services instances of
that type. This leads to confusion (for me, anyway) in trying to
interpret the relationship between when the real events occur and when
they are notified. For example, take the case of a ‘production status
change’ event. By my reading of the state table, row 7 tells me that
the service instance generates the notification at the time that the
event itself actually occurs. However, consider the case of a
complete-mode service instance that’s lagging behind the real-time data
generation rate a bit. I *think* that what is desired is that the
notification be generated in relative timing with respect to the data
being sent, but I don’t think that is actually stated in the
specification.
I don’t have a good solution for the overall problem of the intermixing
of the procedure state table wit the production processing, but I have
a suggestion for clearing some of the confusion about what
notifications get put in the recorded buffer and which ones are sent
only by the service instances and fix the immediate problem with
paragraph of 4.5.1.2.2.2 (Recorded Buffer), bullet (d). In the
definition of the notification-type extension values in section
4.5.3.2.1.1.1, add information that specifies whether the notification
is to be stored in the recorded buffer or not. That is:
- for item (a) (which deals with the standard production status
notifications that affect all service instances tied to that production
process), add the sentence “These notifications shall be stored in the
recorded buffer.”; and
- for item (b) (‘data discarded …’), add the sentences “Notifications
for data discarded due to recorded buffer overflow shall be stored in
the recorded buffer.;
My answer:
If I understand correctly you expressed the fact that there is one recorded
buffer for all service instances (4.5.1.2.2.2.b states "There should be one
recorded buffer for all service instances associated with a particular
service agreement"). However as not all notifications are relevant for all
service instances (e.g "end of data), only a subset are to be stored. This
ambiguity comes from the fact that the recorded buffer is defined at service
level while the table 4.11 is defined at procedure level.
We have to remember that in the future the Framework only support on-line and
off-line data. Therefore in order to fully satisfy the on-line complete
requirement, the buffer shall store all notifications.
In the case of "end of data", the notification is either generated by the
service production, in which case it has to be stored in the recorded buffer;
or, it is generated by the service provision, in which case it is not
stored. As example one can imagine the service user retrieving stored data.
During the retrieval, the recorded buffer data ends before the selected
end-time is reached. In that case the service provision would generate a new
"end-of-data" notification (not read from the buffer).
From my understanding I do not see a conflict.
In case I misunderstood the point or missed something, please let me know and
will discuss the issue.
==============================================
7. What is the difference between the actions ‘sync notify ‘xxx’’ and.
‘insert the notification into the transfer buffer’? The cited
references for each don’t help understand them. ‘insert the
notification into the transfer buffer’ references 4.5.2.3.9.3, which is
about the transfer buffer size. ‘insert the notification into the
transfer buffer’ also references 4.5.2.3.9.4 c), which states “a
NotifyInvocation ‘end of data’ was inserted into the transfer buffer” –
again, a circular reference. ‘sync notify ‘xxx’’ references paragraph
4.5.2.3.7, which talks about synchronous insertion of notifications in
the real-time delivery mod
My answer:
'sync notify 'xxx'' is a legal action used in the stated table. The
cross-reference is correct.
'insert the notification into the transfer buffer’ is not an used action in
the table. This is probably a left over from a previous version. I will
remove it.
More information about the Css-csts
mailing list