[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

unix rwho

    Date: Thu, 10 Sep 87 14:48:43 EDT
    From: royt@pravda.gatech.edu (Roy M Turner)

    I was looking over the documentation and noticed that the Symbolics
    supports something called unix-rwho service; however, upon looking it
    up in the TCP code, I didn't see that it really *did* anything except 
    intercept rwho packets from unix hosts and store them in a variable.
    Does anyone have any functions to make use of this information, such
    as something that will do the equivalent of unix's rwho command?  Or 
    even better, a replacement server that will send information back to 
    Unix's rwho server, so that information about the lisp machines show
    up in rwho's done on unix?

You don't need a replacement server to send information back, as the
Unix machines aren't expecting a reply.  The way RWHO works is that
every machine periodically broadcasts its current status.  What you need
is a timer queue entry that periodically sends out a broadcast.  When a
machine receives such a broadcast, it simply stores the data away
someplace (on Unix they are stored in files in the directory
/usr/spool/rwho), and the rwho and ruptime commands extract the data
from the files.

When I first noticed the rwho server, I wrote a version of RUPTIME for
the Lispm.  Unfortunately, I continued adding features, and now the only
version I have doesn't work.  I would include what I have in this
message, except that it contains a patch to Symbolics code (the
UNIX-RWHO server doesn't fill in the recvtime slot).

By the way, when I was writing this, I found that the best mechanism for
extracting data from the packet was to define it using LMFS:DEFSTORAGE.
This was not easy, since DEFSTORAGE is neither documented nor is source
distributed (I expect that it is included in the Optional LMFS source,
which we'll be getting soon, but this didn't help me five months ago).
DEFSTORAGE is an incredibly useful tool for anyone implementing network
protocols that use structured binary packets rather than sequential
text.  I managed to figure out how to implement a new defstorage element
type (VAX-WORD, i.e. byte-swapped words) by disassembling existing
accessors.  Believe me, disassembling macro-defining macros that produce
byte-twiddling functions is not fun.  Am I alone in wanting to see this
fully documented?  When I first complained, someone at Symbolics sent me
their online documentation of the syntax of DEFSTORAGE (I suspect it was
simply extracted from a comment at the top of the file that defines it),
but it didn't include the extension features (it said to read the code).