Modifying the db servers to track active tokens would be,
at best, an awful pain. At worse, it could be really bad.
The db servers handle mainly read requests. For a heavy load
of writes, ubik is not especially well suited. All the writes
end up being single-threaded on the sync site. You'd really
want to use something that's better suited to a heavy
transaction load. The kaserver people clearly realize
this; the "AuthLog.{dir,pag}" stuff works independently on each
DB server. If your only interest is to track people
who might be affected by bringing down a file server, most
of this effort would be wasted anyways, unless you like to
bring your file servers down real frequently.
If you wanted to track "active" tokens and were especially
concerned about notifying users using a particular file server,
a better way to do this would be on the file server itself.
You can easily do the equivalent of an "rxdebug <file-server>
-allconnections". That will tell you at least where
the connections are coming for, which at least tells you which
workstations to notify. Depending on your workstation base; that
might be good enough. If you could modify the file server code, you
could do even better; since the token gets shipped over to the
file server and is logically associated with the connection,
it would be easy for the file server to generate a list
of all people currently using it, on demand, and most
of the overhead need to track this already has to be done.
Or, you could make the workstation go to the effort of
decoding CID's and deciding which people need to be notified
about an outtage.
Another possibility might be to enrich the callback mechanism. The
client cache manager already knows how to notify people concerning
"interesting events"; so if the file server had some way to pass
a "broadcast" message to all connected workstations, then it
would be quite easy to notify most affected users concerning
impeding outtages and the like. If such a mechanism were implemented,
may I suggest:
(a) the administrator's interface be designed to work
with one-line messages? [ It's rude to send a 30
line message to a user with a 25 line tube. ]
(b) user's have the ability to say "set broadcast off" to
disable such messages? (For things like unattended batch
mode processing, expect, etc., such messages are not always
helpful.)
(c) users be given some API to intercept and capture such
messages? Even on a Unix workstation, users might like
to put it into a separate X windows or log it to disk.
Not all operating system's provide an easy way to capture
console output. And then there are applications like
the IFS macintosh translator, where it would be nice
to capture such stuff and ship it out to the user who
is not actually on the same machine and may not even be reachable
by IP.
-Marcus Watts
UM ITD RS Umich Systems Group
