Network Time Software Functional Specification


    Distribution: COMPANY CONFIDENTIAL

    Project:      NC Model 1
    Issue:        0.02
    Author(s):    Jonathan Harris
    Date:         27-Aug-96
    Last Issue:   0.01
      

Contents.


History

	0.01 JRH 01-Apr-96 First created.
	0.02 JRH 27-Aug-96 Gets timeserver's IP address from registry.
	                   Connection attempts are initiated on
	                   receipt of Dialler and Registry services.
	                   Removed NetTime_SetTime SWI.
      

Outstanding issues

Parts of this specification which are emphasised like this are either undecided issues or are liable to change.


Overview

The Network Computer will not contain a real-time clock. It is considered desirable (for cookie-expiry among other reasons) that the NC should know the time-of-day to a reasonable accuracy. It is presumed that for security reasons any time-stamping required for file stamps, transaction logging or billing will take place at the server end and will use the server's conception of the time-of-day, so the NC's time-of-day value will be only used locally.

This documents specifies the software development required to provide network time synchronisation for the Network Computer.


Technical background

Internet time protocols

Time Protocol

This simple protocol returns the server's current time relative to 00:00 1st January 1900 UTC. Its use dates back to the beginnings of the ARPA Internet and so it is widely implemented. The protocol's resolution is 1 second.

Network Time Protocol (NTP)

This protocol also returns the server's current time relative to 00:00 1st January 1900 UTC. It is accurate to between 1 and 50ms depending on the characteristics of the server and network paths and is designed to cope with "multiple gateways, highly disruptive delays and unreliable nets" between the client and server. Since the NC would be a leaf on the network it is expected that it would only be necessary to implement the subset of NTP known as SNTP on the NC. Most vendors do not ship the NTP daemon with their UNIX implementations.

Time in RiscOS 3.x

RiscOS's various system times are derived from a centi-second interrupt from the Timer0 hardware timer. The oscillator that supplies Timer0 is specified as being accurate to 100ppm; approximately 1 second every 3 hours.

Time-dependent system events (ie OS_CallEvery, OS_CallAfter) are relative to one particular system timer called the `monotonic timer' which is incremented on every Timer0 interrupt.

RiscOS also independently maintains a `Real-time' clock for application use which holds the time-of-day. This is initialised on reset to the value held in the RTC chip combined with the configured year held in NVRAM. It is incremented on every Timer0 interrupt. The RTCAdjust module compares RiscOS's time-of-day value with that held in the RTC chip every hour and re-programs Timer0 to compensate for any inaccuracy in its driving oscillator. This process results in RiscOS's time-of-day being closely synchronised with the RTC chip after two hours.

The kernel has two basic subroutines for reading/writing its time-of-day from/to the RTC:

SetTime:
Sets NCOS's time-of-day, the contents of the RTC and the configured year in NVRAM.
Called by SWI OS_Word 15,xx (write time and/or date).
RTCToRealTime:
Sets NCOS's time-of-day to the value held in the RTC combined with the value for the year held in NVRAM.
Called on kernel initialisation. Also called by SetTime to reset NCOS's time-of-day to the RTC's new contents.

NC operation

The NC will set the time-of-day to a default value at boot-time.

A new NetTime module will attempt to obtain the Internet address of the NC's time server on receiving service Service_DiallerStatus with states 2 or 5 (ie link going up) or Service_NCRegistry with BB_STATUS_BB_VALID delta set in either boot-block.

If the NetTime module can obtain the timeserver's IP address from the registry it will attempt to connect using a non-blocking asynchronous TCP socket. It will set the NC's time using SWI Territory_SetTime and close the socket on receipt of the reply. It will re-contact the time server 30 minutes after a successful connection and 5 minutes after an an unsuccessful connection unless it receives service Service_DiallerStatus with states other than 2 or 5 (ie link going/gone down).


User interface

There is no user interface.


Programmer interface

There is no user interface.


Standards

[RFC868]
J.Postel & K.Harrenstein, "Time Protocol", ISI & SRI, May 1983.
[RFC951]
W.Croft & J.Gilmore, "Bootstrap Protocol (BOOTP)", Stanford University & Sun Microsystems, September 1985.
[RFC1305]
D.L.Mills, "Network Time Protocol", U. of Delaware, March 1992.
[RFC1533]
S.Alexander, "DHCP Options and BOOTP Vendor Extensions", Bucknell University, October 1993.
[RFC1541]
R.Droms, "Dynamic Host Configuration Protocol", Bucknell University, October 1993.
[RFC1769]
D.L.Mills, "Simple Network Time Protocol (SNTP)", U. of Delaware, March 1995.