Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search Store documents

The best documents sold by students who completed their studies

Search through all study resources
Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

From our blog

Exams and Study
Go to the blog

The Berkeley UNIX† Time Synchronization Protocol, Exercises of Network Technologies and TCP/IP

Cornell CollegeNetwork Technologies and TCP/IP

Introduction. The Time Synchronization Protocol (TSP) has been designed for specific use by the program timed, a local area network clock synchronizer for ...

Typology: Exercises

2022/2023

Uploaded on 05/11/2023

seshadrinathan_hin
seshadrinathan_hin 🇺🇸

4.5

(15)

231 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
The Berkeley UNIX†
Time Synchronization Protocol
Riccardo Gusella, Stefano Zatti, and James M. Bloom
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, CA 94720
Introduction
The Time Synchronization Protocol (TSP) has been designed for specific use by the program timed, a
local area network clock synchronizer for the UNIX 4.3BSD operating system. Timed is built on the
DARPA UDP protocol [4] and is based on a master slave scheme.
TSP serves a dual purpose. First, it supports messages for the synchronization of the clocks of the
various hosts in a local area network. Second, it supports messages for the election that occurs among
slave time daemons when, for any reason, the master disappears. The synchronization mechanism and the
election procedure employed by the program timed are described in other documents [1,2,3].
Briefly, the synchronization software, which works in a local area network, consists of a collection of
time daemons (one per machine) and is based on a master-slave structure. The present implementation
keeps processor clocks synchronized within 20 milliseconds. A master time daemon measures the time
difference between the clock of the machine on which it is running and those of all other machines. The
current implementation uses ICMP Time Stamp Requests [5] to measure the clock difference between
machines. The master computes the network time as the average of the times provided by nonfaulty
clocks.1It then sends to each slave time daemon the correction that should be performed on the clock of its
machine. This process is repeated periodically. Since the correction is expressed as a time difference
rather than an absolute time, transmission delays do not interfere with synchronization. When a machine
comes up and joins the network, it starts a slave time daemon, which will ask the master for the correct
time and will reset the machine’s clock before any user activity can begin. The time daemons therefore
maintain a single network time in spite of the drift of clocks away from each other.
Additionally, a time daemon on gateway machines may run as a submaster. A submaster time dae-
mon functions as a slave on one network that already has a master and as master on other networks. In
addition, a submaster is responsible for propagating broadcast packets from one network to the other.
To ensure that service provided is continuous and reliable, it is necessary to implement an election
algorithm that will elect a new master should the machine running the current master crash, the master ter-
minate (for example, because of a run-time error), or the network be partitioned. Under our algorithm,
slaves are able to realize when the master has stopped functioning and to elect a new master from among
themselves. It is important to note that since the failure of the master results only in a gradual divergence
hhhhhhhhhhhhhhhhhh
†UNIX is a trademark of Bell Laboratories.
This work was sponsored by the Defense Advanced Research Projects Agency (DoD), monitored by the Naval Electronics
Systems Command under contract No. N00039-84-C-0089, and by the Italian CSELT Corporation. The views and conclu-
sions contained in this document are those of the authors and should not be interpreted as representing official policies, ei-
ther expressed or implied, of the Defense Research Projects Agency, of the US Government, or of CSELT.
1A clock is considered to be faulty when its value is more than a small specified interval apart from the majority of the
clocks of the machines on the same network. See [1,2] for more details.
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download The Berkeley UNIX† Time Synchronization Protocol and more Exercises Network Technologies and TCP/IP in PDF only on Docsity!

The Berkeley UNIX†

Time Synchronization Protocol

Riccardo Gusella, Stefano Zatti, and James M. Bloom

Computer Systems Research Group

Computer Science Division

Department of Electrical Engineering and Computer Science

University of California, Berkeley

Berkeley, CA 94720

Introduction

The Time Synchronization Protocol (TSP) has been designed for specific use by the program timed , a

local area network clock synchronizer for the UNIX 4.3BSD operating system. Timed is built on the

DARPA UDP protocol [4] and is based on a master slave scheme.

TSP serves a dual purpose. First, it supports messages for the synchronization of the clocks of the

various hosts in a local area network. Second, it supports messages for the election that occurs among

slave time daemons when, for any reason, the master disappears. The synchronization mechanism and the

election procedure employed by the program timed are described in other documents [1,2,3].

Briefly, the synchronization software, which works in a local area network, consists of a collection of

time daemons (one per machine) and is based on a master-slave structure. The present implementation

keeps processor clocks synchronized within 20 milliseconds. A master time daemon measures the time

difference between the clock of the machine on which it is running and those of all other machines. The

current implementation uses ICMP Time Stamp Requests [5] to measure the clock difference between

machines. The master computes the network time as the average of the times provided by nonfaulty

clocks.

1 It then sends to each slave time daemon the correction that should be performed on the clock of its

machine. This process is repeated periodically. Since the correction is expressed as a time difference

rather than an absolute time, transmission delays do not interfere with synchronization. When a machine

comes up and joins the network, it starts a slave time daemon, which will ask the master for the correct

time and will reset the machine’s clock before any user activity can begin. The time daemons therefore

maintain a single network time in spite of the drift of clocks away from each other.

Additionally, a time daemon on gateway machines may run as a submaster. A submaster time dae-

mon functions as a slave on one network that already has a master and as master on other networks. In

addition, a submaster is responsible for propagating broadcast packets from one network to the other.

To ensure that service provided is continuous and reliable, it is necessary to implement an election

algorithm that will elect a new master should the machine running the current master crash, the master ter-

minate (for example, because of a run-time error), or the network be partitioned. Under our algorithm,

slaves are able to realize when the master has stopped functioning and to elect a new master from among

themselves. It is important to note that since the failure of the master results only in a gradual divergence

hhhhhhhhhhhhhhhhhh

† UNIX is a trademark of Bell Laboratories.

This work was sponsored by the Defense Advanced Research Projects Agency (DoD), monitored by the Naval Electronics

Systems Command under contract No. N00039-84-C-0089, and by the Italian CSELT Corporation. The views and conclu-

sions contained in this document are those of the authors and should not be interpreted as representing official policies, ei-

ther expressed or implied, of the Defense Research Projects Agency, of the US Government, or of CSELT.

1 A clock is considered to be faulty when its value is more than a small specified interval apart from the majority of the

clocks of the machines on the same network. See [1,2] for more details.

SMM:22-2 The Berkeley UNIX Time Synchronization Protocol

of clock values, the election need not occur immediately.

All the communication occurring among time daemons uses the TSP protocol. While some mes-

sages need not be sent in a reliable way, most communication in TSP requires reliability not provided by

the underlying protocol. Reliability is achieved by the use of acknowledgements, sequence numbers, and

retransmission when message losses occur. When a message that requires acknowledgment is not ack-

nowledged after multiple attempts, the time daemon that has sent the message will assume that the addres-

see is down. This document will not describe the details of how reliability is implemented, but will only

point out when a message type requires a reliable transport mechanism.

The message format in TSP is the same for all message types; however, in some instances, one or

more fields are not used. The next section describes the message format. The following sections describe

in detail the different message types, their use and the contents of each field. NOTE: The message format

is likely to change in future versions of timed.

Message Format

All fields are based upon 8-bit bytes. Fields should be sent in network byte order if they are more

than one byte long. The structure of a TSP message is the following:

  1. A one byte message type.

  2. A one byte version number, specifying the protocol version which the message uses.

  3. A two byte sequence number to be used for recognizing duplicate messages that occur when mes-

sages are retransmitted.

  1. Eight bytes of packet specific data. This field contains two 4 byte time values, a one byte hop count,

or may be unused depending on the type of the packet.

  1. A zero-terminated string of up to 256 ASCII characters with the name of the machine sending the

message.

The following charts describe the message types, show their fields, and explain their usages. For the

purpose of the following discussion, a time daemon can be considered to be in one of three states: slave,

master, or candidate for election to master. Also, the term broadcast refers to the sending of a message to

all active time daemons.

Adjtime Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Seconds of Adjustment iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Microseconds of Adjustment iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_ADJTIME (1)

The master sends this message to a slave to communicate the difference between the clock of the

slave and the network time the master has just computed. The slave will accordingly adjust the time of its

machine. This message requires an acknowledgment.

SMM:22-4 The Berkeley UNIX Time Synchronization Protocol

Set Network Time Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Seconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Microseconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_SETTIME (5)

The master sends this message to slave time daemons to set their time. This packet is sent to newly

started time daemons and when the network date is changed. It contains the master’s time as an approxi-

mation of the network time. It requires an acknowledgment. The next synchronization round will elim-

inate the small time difference caused by the random delay in the communication channel.

Master Active Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_MASTERUP (6)

The master broadcasts this message to solicit the names of the active slaves. Slaves will reply with a

Slave Active message.

Slave Active Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_SLAVEUP (7)

A slave sends this message to the master in answer to a Master Active message. This message is also

sent when a new slave starts up to inform the master that it wants to be synchronized.

The Berkeley UNIX Time Synchronization Protocol SMM:22-

Master Candidature Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_ELECTION (8)

A slave eligible to become a master broadcasts this message when its election timer expires. The

message declares that the slave wishes to become the new master.

Candidature Acceptance Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_ACCEPT (9)

A slave sends this message to accept the candidature of the time daemon that has broadcast an Elec-

tion message. The candidate will add the slave’s name to the list of machines that it will control should it

become the master.

Candidature Rejection Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_REFUSE (10)

After a slave accepts the candidature of a time daemon, it will reply to any election messages from

other slaves with this message. This rejects any candidature other than the first received.

The Berkeley UNIX Time Synchronization Protocol SMM:22-

Set Date Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Seconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Microseconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_SETDATE (22)

The program date (1) sends this message to the local time daemon when a super-user wants to set the

network date. If the local time daemon is the master, it will set the date; if it is a slave, it will communicate

the desired date to the master.

Set Date Request Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Seconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Microseconds of Time to Set iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_SETDATEREQ (23)

A slave that has received a Set Date message will communicate the desired date to the master using

this message.

Set Date Acknowledgment Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_DATEACK (16)

The master sends this message to a slave in acknowledgment of a Set Date Request Message. The

same message is sent by the local time daemon to the program date(1) to confirm that the network date has

been set by the master.

SMM:22-8 The Berkeley UNIX Time Synchronization Protocol

Start Tracing Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_TRACEON (17)

The controlling program timedc sends this message to the local time daemon to start the recording in

a system file of all messages received.

Stop Tracing Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_TRACEOFF (18)

Timedc sends this message to the local time daemon to stop the recording of messages received.

Master Site Message

Byte 1 Byte 2 Byte 3 c

c Byte 4 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Type c

c

c

Version No. c

c

c

Sequence No. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

( unused ) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Machine Name iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c

c

c

c

c

c

cc

c

c

c

c

c

c

Type: TSP_MSITE (19)

Timedc sends this message to the local time daemon to find out where the master is running.

SMM:22-10 The Berkeley UNIX Time Synchronization Protocol

References

  1. R. Gusella and S. Zatti, TEMPO: A Network Time Controller for Distributed Berkeley UNIX System ,

USENIX Summer Conference Proceedings, Salt Lake City, June 1984.

  1. R. Gusella and S. Zatti, Clock Synchronization in a Local Area Network , University of California,

Berkeley, Technical Report, to appear.

  1. R. Gusella and S. Zatti, An Election Algorithm for a Distributed Clock Synchronization Program ,

University of California, Berkeley, CS Technical Report #275, Dec. 1985.

  1. Postel, J., User Datagram Protocol , RFC 768. Network Information Center, SRI International,

Menlo Park, California, August 1980.

  1. Postel, J., Internet Control Message Protocol , RFC 792. Network Information Center, SRI Interna-

tional, Menlo Park, California, September 1981.