\documentstyle[marg,underscore,verbinput,12pt]{article}
\title{Athena Global Message System: a short-term design proposal}
\author{Mark W. Eichin, MIT Project Athena}
%\margins{-.5in}{7in}{-.75in}{9.5in}
\margins{0in}{6in}{-.75in}{9.5in}
%%% $Header: ngms.latex,v 1.1 88/09/26 16:31:05 eichin Locked $
\newcommand{\cbar}{\marginpar{\rule[-0pt]{2pt}{12pt}}}
\newcommand{\cbarr}{\marginpar{\rule[-24pt]{2pt}{36pt}}}
\begin{document}
\maketitle
\tableofcontents
\newcommand{\gms}{Global Message System}

\section{Introduction}
Project Athena is a workstation environment with approximately 850
individual workstations and 50 various servers, grouped into 10 public
clusters as well as numerous private ones. Occasionally, the normal
location transparency of this environment is a hindrance. The Athena
Global Message System is designed to provide a way for users to read
messages pertaining to various topics which are important to them
(file server shutdowns, software changes) every time they log in.

\section{Requirements}
\begin{itemize}
\item The system must work.
\item The system must display a short message to the user on login;
this message must be established from a central location.
\item The message should only appear when it is useful; when there is
no current message, the user should not see one. The design should
avoid visual clutter that would encourage users to ignore these
messages. 
\item  A tendency toward consistency is sufficient. It is assumed that
the message is only updated infrequently (daily updates are unlikely).
In addition, the user need not be guaranteed the latest message.
\item The design must scale well, including its impact on the server,
the network, and other services.
\item The short-term system must be completed for the 6.0R Athena
Release timeframe.
\item The display of the message should not preclude any existing
(local) message of the day.
\item The protocol must be fully version number typed. This includes
seperate protocol numbers which must be sent with the request for
message, and be returned with the data.
\item The message must be version numbered and all control operations
must be based on version number, not on message content.
\end{itemize}


\section{Implementation Details}

\subsection{Message Retrieval}
A message is requested via a UDP datagram request to a server which is
identified via a hesiod \verb+sloc+ query. The client waits for a
reply until a timeout\footnote{currently 5 seconds.} is exceeded. If a
reply arrives, it is saved in a known place (specifically,
\verb+/usr/tmp/.messages+,\footnote{to hide it from the user, since
autosave files (for example) share the directory} creating it (mode
666) if it doesn't exist). The timestamp of the reply is saved as the
first line (as it was retrieved originally). If the reply has the time
stamp value `0', this indicates that there is no current message and
the workstation should flush its copy. Since \verb+/usr/tmp+ is
sticky-bitted, there is no way to remove this file without being root.
Instead, utimes() is used to set the timestamp into the distant past
so that the daily \verb+crontab+ entry cleans it out.

After the message has been delivered to the workstation at least once,
there will be a cached copy in \verb+/usr/tmp/.messages+ which will be
used in case of future failures.\footnote{This is consistent with
existing practice, such as the cluster information file kept on each
workstation.} This fallback should be recorded via syslog, although
informing the user is not appropriate. Errors with message retrieval
are logged to facility \verb+LOG_USER+ and level \verb+LOG_INFO+,
which is normally ignored.

\subsection{User Message Timestamp Record}
The \verb+~/.message_times+ file contains a protocol version number on the
first line, followed by one line per message seen consisting of the
message name, the timestamp given, and a comment field which should
consist of at least a human readable form of the timestamp. Given that
it is unlikely that the user will run parallel \verb+get_message+
processes, that any such updates would write the same thing, and that
this is not critical information in any case, this file is not locked.

\subsection{Clearing the Message}
Normally, the server will simply send the timestamp and data in the
file to the client as a single packet. If the file is missing, it logs
this but sends on to the client that it is of zero length. The client
should treat a zero length file as an indication of ``no current
message'' and not display anything for the user; it also clears
the cached copy of the message, if there is one. 

\subsection{Message Update}
For simplicity, the message that the server sends out should be
available on a locker, either exported from or mounted by the server.
Since the version number is the timestamp of the file, editing the
message suffices to make a new one available.  There is an existing
``info'' locker which would be appropriate for this task.

\subsection{Failure Handling}
Due to the ``loose consistency'' and ``limited clutter'' constraints,
the user is not informed of any errors. Interesting ones are
be recorded via syslog, as that will be the method of presenting
errors to the users in the future.

The server daemon is also capable of being run with the \verb+-log+
option, which records via syslog (facility \verb+LOG_DAEMON+, level
\verb+LOG_INFO+) the address of each requesting host.

\section{User Interface}
The \gms\ is visible to the user through the \verb+get_message+ program.
The program is invoked two distinct ways:
\begin{itemize}
\item[]As text output to standard out:
\item From \verb+/bin/login+ sends the
global message to standard output (to appear in the user's login
window, or terminal).
\item[]As output to a Zephyrgram:
\item In the user's .login file\footnote{or Athena standard prototype
files referenced from \verb+.login+.} it sends the message to the user
via Zephyr.
\end{itemize}

\verb+get_message -new+ will display messages that have not
already been seen, based on the contents of the user's
\verb+~/.message_times+ file. As this file is only updated when the
\verb+-new+ option is specified, the user will always have the
message in the login window, yet the later Zephyr message will only
appear once. The \verb+message_times+ file contains a protocol version
number and a message version number, so that the user will see new
messages based on version number rather than content. The Zephyr
message is delivered when the program is invoked with the
\verb+-zephyr+ option.

Thus, the suggested line for \verb+/usr/athena/.login+ is
\begin{verbatim}
/usr/etc/zwgc
if ( ! $status  ) then
       get_message -zephyr -new
endif
\end{verbatim}
(the invocation of \verb+zwgc+ already exists; \verb+$status+ is set
to 0 if \verb+zwgc+ starts successfully.

\section{Conclusions}

We should be able to implement a simple system that meets the above
goals within the 6.0R timeframe. It is prudent to keep in mind that
the design may be extended beyond this timeframe to provide more
general functionality.

\end{document}
