\documentstyle[marg,underscore,verbinput,12pt]{article}
\title{Athena Global Message System: a design proposal}
\author{Mark W. Eichin, MIT Project Athena}
\margins{-.5in}{7in}{-.75in}{9.5in}
%%% $Header: gms.latex,v 1.2 88/09/13 23:28:13 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 700
individual workstations and 70 servers, grouped into 10 public
clusters as well as numerous private ones.\footnote{I guessed at these
numbers, I need a set that are real and quotable.} One disadvantage of
the workstation environment is that users need to know about parts of
the system that are often physically distant from them about which
they have no immediate information. 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{User Interface}
The \gms\ is visible to the user through the \verb+get_message+ program.
This program is run by the user's .login file.\footnote{under Athena,
the standard prototype files would include something that ran this.}
It takes a list of message names on the command line. These message
names are one word tokens which name what global message the user
wishes to see. For example,
\begin{verbatim}
get_message athena
\end{verbatim}
would retrieve and display the global message for Project Athena as a
whole.

The invocation of \verb+get_message+ can be tailored to depend upon
other aspects of the user's login session. For example, if the user
has successfully started a Zephyr Windowgram Client, he or she may want to
redirect the output to a zephyr notice, to appear graphically. If not,
the user would want it to appear on the terminal directly. This is easily
accomplished with some conditional statements in the .login file.

\verb+get_message+ can take multiple message names on its command
line. The messages are displayed in the order that the names are
listed, with a line before each indicating what message follows.
Another appropriate name would be the cluster name that the user is
currently in. This could be looked up with a hesiod
query.\footnote{Well, under Athena we can currently look up cluster,
and then the line prcluster within that. This could be fixed.}

\verb+get_message -new+ will only print out any messages that have not
already been seen, based on the contents of the user's
\verb+~/.message_times+ file. This file is always updated regardless
of the arguments to \verb+get_message+.

\section{Suggestions for Message Management}
Useful things to put in the athena ``most global'' message would
include:
\begin{itemize}
\item Scheduled downtime of machines (which affects a random
sampling of users, but is relatively rare).
\item New releases being announced.
\end{itemize}
Useful things to put in the cluster specific message would include:
\begin{itemize}
\item Mention of broken equipment in this cluster and workarounds (ie.
the printer here is broken; the nearest alternate is printername in
building number)
\item Mention of cluster closings (which may be imminent.)
\item Warnings of recent upgrades.
\end{itemize}

Some large MIT organizations might also find it useful to have their
own global messages. Living groups and fraternites might want to have
specific ones in their clusters (perhaps beyond the cluster-specific
message).

\iffalse
 For example, the MIT Assassins' Guild conducts
very intense real time games which have begun to gravitate toward
networked computers as a source of real time communication. This is
perhaps the largest example (the Guild having several
hundred\footnote{Well, I saw 200 freshman sign up one Rush Week, but I
don't know the official size. If the example stays in, I'll find it.}
student members) but I am sure other interesting ones are available.
\fi

Large classes (such as 6.111, 6.170, 2.10 and others) which are
already using Athena may want to create their own messages listing
things like weekend lab hours and other last minute changes.

\section{Implementation Details}
\subsection{Message Name Resolution}
Given a message name, a hesiod query for {\tt name_message.sloc}\cbar
will return the name of a server (or list of servers) which has the
global message on it.

\subsection{Message Retrieval}
Given a message name and a list of server names, connect to a known
port on the server and send a one line request containing the message
name.  (If a server fails in any way, the contact is attempted with
each of the others in the list until it is successful or the end of
the list is reached. Searching the list in random order would perform
load sharing between the servers, as well.)  The server will respond
with one line of status, which will be a protocol version identifier
and version number \cbarr (GMS:0) followed by the message name (the
original request string) and a datestamp (the actual last modify time
of the file in seconds (UNIX time), for simplicity.) If the timestamp
begins with a dash, some error occurred, which is described after the
dash. The remainder of the stream will be the message
itself.\footnote{If it seems appropriate to use a datagram protocol
instead, either the message length must be limited or a fragmenting
scheme must be implemented.} The version number and datestamp are
integers in decimal ASCII representation; both the request and the
reply are in Net ASCII format.
\iffalse
gross hack: make the port number smtp (25) and make it send down
``MOTD messagename''???
\fi

When a reply is successfully retrieved, it is saved in a known place
(specifically, \verb+/usr/tmp/messages+, creating it (mode 777) if
it doesn't exist) The timestamp of the reply is saved as the first
line (as it was retrieved originally) and the time of retrieval is
also saved (either as a second number on the first line or using
existing filesystem timestamps.) This is to provide a small amount of
backup for commonly retrieved messages in case of server failure.

\subsection{User Message Timestamp Record}
The \verb+~/.message_times+ file contains a file 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. This file
should probably have some sort of interlocks for update, though
failing to update due to a lock is probably not worth blocking for.

It may be appropriate to have this file purged under some
circumstances (such as a special name lookup indicating that some
message name in it does not exist.)

\subsection{Failure Handling}
\subsubsection{Message Name Resolution}
If the message name lookup fails, either nameservice is not available
or the name does not exist. In either case a brief (one line?)
explanation should be given to the user. If nameservice failure is
evident, then the error should be considered a message retrieval
failure (see below) otherwise the user should be informed that the
message name probably doesn't exist anymore.

\subsubsection{Message Retrieval}
If the server is unreachable or the retrieval fails for some other
reason, the \verb+get_message+ program should try looking under a
known subdirectory of \verb+/usr/tmp+ (ie.
\verb+/usr/tmp/messages/messagename+). If this fallback is used, the
program must clearly label the message, with a statement such as
``Couldn't contact server, old y message dated x was:'' If there was
no fallback, the user should be informed that the the message wasn't
available at the time. If the storage time is avaliable, it is also
displayed (to indicate to the user when this message was last known to
be valid, as well as its original timestamp.)

Note that the temporary message set will get purged eventually;
however, the most common messages (such as ``athena'' and the one for
the cluster that the machine is in) will most likely be current, as
very few machines are idle long enough for the automatic cleanup to
reach those files in \verb+/usr/tmp+.

It may be permitted for the \verb+get_message+ program to batch
several requests to the server and send them (seperated by spaces) on
the initial line sent to the server. In this case, the returning
messages should be seperated by something, so that the client can sort
them out and interleave them correctly with other messages.

\subsection{Message Update}
Although initially, keeping the global messages on a small number of
central servers which operations can actually log into and update
would be sufficient for their needs, the greater design of the \gms\
does include a \verb+change_message+ function. Using existing Kerberos
Authentication and the Athena Access Control Library, messages could
be
\begin{itemize}
\item changed simultaneously on multiple servers without much
effort
\item changed from the normal user environment, without requiring
remote editing and actual access to the server (especially if the
server is heavily loaded or has other duties which would discourage
direct access)
\item changed by dynamically changing lists of users, such as the
officers or managers of a group
\iffalse
\footnote{or the Assassins' Guild
current GameMasters.}
\fi
\end{itemize}

The Access Control Lists would be maintained by SMS\footnote{another
three letter acronym that should have a paper to reference it to} and
thus be controllable with standard Athena tools such as {\tt
listmaint}.\footnote{In a non-Athena environment they could be
controlled by directly editing the lists, as configuration files, or
though other existing access control brokers.}

\section{Conclusions}

It is important to note that although the \gms\ described here can be
a useful tool for disseminating information to broad classes of users,
it will not be effective without a policy for managing Athena's use of
this information. If trivial things are made global too often, there
is the risk of users ignoring or avoiding the messages; this would be
detrimental to the usefullness of the system in distributing important
information.

\appendix
\section{Sample Demonstration}
In order to demonstrate more clearly some of the issues involved, I
have constructed a simple demonstration of the user interface involved
through the means of that widely known pseudocode known as the Bourne
Shell. The interface that follows is broken down into conceptual
modules, which are called via \verb+get_message+. To actually use this
sampler, on Athena, 
\begin{verbatim}
attach eichin
/mit/eichin/projects/gms/get_message
\end{verbatim}
All of the source code involved is in the \verb+gms+ directory.

\end{document}
