[Sois-tcoa] Time Distribution -- Take 2 Service Spec

Keith Scott kscott at mitre.org
Mon Mar 7 11:13:28 EST 2005


Here's a revised TDS service spec that removes the extra goo in the
time.request primitive.

I was trying to think of how an application might make use of a time source
identifier that told it which time source provided a particular answer.
Such a thing might be useful if I thought that a particular time source was
just whacko and I wanted to ignore it.  To make that work, however, would
require a 'time source identifier' in the time.request primitive (so I could
then ask for a 'non-whacko' source).  There's also the question of how to
resolve multiple time sources into a single answer, and how an application
would find out what the list of available time sources is.  The operative
part of this is:

I'm leaning towards a formulation where resolving differences among
different time sources should be the job of the time distribution service,
which would simply return its best estimate of the current time along with a
'goodness' indicator.  This would NOT show up in the service spec, except as
a note (see 'additional comments' under time.indication below).

Thoughts on this approach?  I'm particularly interested if anybody can come
up with a use for knowing the specific time source vs. just the 'accuracy
specification'.

		--keith


====  Draft TD service specification B  ====

Definitions:

Request Token: A handle passed from users of the time distribution service
when requesting the current time.  The token is returned in the time
response.  By supplying different tokens with different requests, a user can
associate responses with corresponding requests.

Accuracy Specification: An indication of the accuracy of a particular time
value (need to specify semantics here (units, at least) -- I suspect the
right verbiage exists if I can just find it.)  Will need to be able to
specify "no answer" (infinite variability) in case things fail.

Time Source Identifier: An indication of which TD time service 'master' the
user would like to use.  (In practice, a default value should yield 'any').

TIME.REQUEST

The Time.request primitive shall be used by a user of the time distribution
service to request the current time.

Semantics: Time.request shall provide parameters as follows:
	Time.request ( request token )

When Generated: GetTime.request is generated by users of the time
distribution service when they want to request the current time.

Effect on receipt: Receipt of a Time.request shall cause the TD service to
determine the current time, and return it to the application.  If an answer
cannot be provided by a system-specified timeout, the TD service may return
an answer with extremely extremly low, or even meaningless, accuracy
specification ("I don't know what time it is")



TIME.INDICATION

The Time.indication primitive shall be used to deliver the current time with
specified accuracy.

Semantics: Time.indication shall provide parameters as follows:
	Time.indication(	request token,
				accuracy specification,
				time)

When Generated: Time.indication shall be generated in response to a
Time.request request.

Effect on receipt: The effect on receipt of a Time.indication by a TD user
is undefined.

Additional comments: The semantics of the accuracy specification need to be
such that the TDS can return 'I don't know'.

If there are multiple time sources configured as inputs to the TDS, it is
the job of the TDS to resolve their inputs into a single time that is
returned to the application.  The mechanism for resolving multiple time
inputs is left to the TDS.

============================ 






More information about the Sois-tcoa mailing list