rfc993.txt

RFC 相关的技术文档

   present locally.  If a client has extremely limited amounts of disk
   storage, it is also possible to get a subset of the descriptors from
   the repository.  Short messages can reside on the client, along with
   the descriptors, and long messages can either be printed via the DMSP
   print-message operation, or specially pulled over via the fetch-
   message-text operation.






Clark & Lambert                                                [Page 15]

RFC 993                                                    December 1986


6. Typical interactive-style client-repository interaction

   The following example describes a typical communication session
   between the repository and a client.  The client is one of three be-
   longing to user "Fred".  Its name is "office-client", and since Fred
   uses the client regularly to access his mail, the client is marked as
   "active".  Fred has two mailboxes: "main" is where all of his current
   mail is stored; "archive" is where messages of lasting importance are
   kept.  The example will run through a simple synchronization opera-
   tion followed by a series of typical mail state manipulations.  Typi-
   cally, the synchronization will be performed by an application pro-
   gram that connects to the repository, logs in, synchronizes, and logs
   out.

   For the example, all DMSP operations will be shown in a user-readable
   format.  In reality, the operations would be sent as a stream of USP
   blocks consisting of a block-type number followed by a stream of
   bytes representing the block's components.

   In order to access his global mail state, the client software must
   authenticate Fred to the repository; this is done via the DMSP login
   operation:

       login ["fred", "fred-password", "office-client", F, F]

   This tells the repository that Fred is logging in via "office-
   client", and that "office-client" is identified by an existing client
   object attached to Fred's user object.  The first component of the
   login block is Fred's repository user name.  The second component is
   Fred's password.  The third component is the name of the client com-
   municating with the repository.  The fourth component tells the repo-
   sitory not to create "office-client" even if it cannot find its
   client object.  The final component tells the repository that Fred's
   client is not operating in batch mode but rather in interactive mode.

   Fred's authentication checks out, so the repository logs him in, ack-
   nowledging the login request with an OK block.

   Now that Fred is logged in, the client performs an initial synchroni-
   zation.  This process starts with the client's asking for an up-to-
   date list of mailboxes:

       list-mailboxes []

        The repository replies with:

       mailbox-list [["main", 10, 1, 253],
                     ["archive", 100, 0, 101]]

   This tells the client that there are two mailboxes, "main" and "ar-
   chive".  "Main" has 10 messages, one of which is unseen.  The next



Clark & Lambert                                                [Page 16]

RFC 993                                                    December 1986


   incoming message will be assigned a UID of 253.  "Archive", on the
   other hand, has 100 message, none of which are unseen.  The next mes-
   sage sent to "archive" will be assigned the UID 101.  There are no
   new mailboxes in the list (if there were, the client program would
   create them.  On the other hand, if some mailboxes in the client's
   local list were not in the repository's list, the program would as-
   sume them deleted by another client and delete them locally as well).

   To synchronize the client need only look at each mailbox's contents
   to see if (1) any new mail has arrived, or (2) if Fred changed any
   messages on one of his other two clients subsequent to "office-
   client"'s last connection to the repository.

   The client asks for any changed descriptors via the "get-changed-
   descriptors" operation.  It requests at most ten changed descriptors
   since storage is very limited on "office-client".

       get-changed-descriptors ["main", 10]

        The repository responds with:

       descriptor-list [[descriptor[
                                6,
                                [T T F F F F F F F F F F
                                 F F F F],
                                "Fred@borax",
                                "Joe@fab",
                                "Wed, 23 Jan 86 11:11 EST",
                                "tomorrow's meeting",
                                621,
                                10]]
                         [descriptor[
                                10,
                                [F T F F F F F F F F F F
                                 F F F F],
                                "Fred",
                                "Freds-secretary",
                                "Fri, 25 Jan 86 11:11 EST",
                                "Monthly progress report",
                                13211,
                                350]]
                           ]

   The first descriptor in the list is one which Fred deleted on another
   client yesterday.  "Office-client" marks the local version of the
   message as deleted.  The second descriptor in the list is a new one.
   "Office-client" adds the descriptor to its local list.  Since both
   changes have now been recorded locally, the descriptors can be reset:

       reset-descriptors ["main", 6, 10]




Clark & Lambert                                                [Page 17]

RFC 993                                                    December 1986


   The repository removes from "office-client"'s update list all mes-
   sages with UIDs between 6 and 10 (in this case just two messages)
   "Main" has now been synchronized.  The client now turns to Fred's
   "archive" mailbox and asks for the first ten changed descriptors.

       get-changed-descriptors ["archive", 10]

        The repository responds with

       descriptor-list []

   The zero-length list tells "office-client" that no descriptors have
   been changed in "archive" since its last synchronization.  No new
   synchronization needs to be performed.

   Fred's client is now ready to pull over the new message.  The message
   is 320 lines long; there might not be sufficient storage on "office-
   client" to hold the new message.  The client tries anyway:

       fetch-message-text ["main", 10]

        The repository begins transmitting the message:

       message ["From: Fred's-secretary",
                "To: Fred",
                "Subject: Monthly progress report",
                "Date: Fri, 25 Jan 86 11:11 EST",
                "",
                "Dear Fred,",
                "Here is this month's progress report",
                ...
                ]

   Halfway through the message transmission, "office-client" runs out of
   disk space.  Because all DMSP operations are defined to be failure-
   atomic, the portion of the message already transmitted is destroyed
   locally and the operation fails.  "Office-client" informs Fred that
   the message cannot be pulled over because of a lack of disk space.
   The synchronization process is now finished and Fred can start read-
   ing his mail.  The new message that was too big to fit on "office-
   client" will be marked "off line"; Fred can either remote-print it or
   delete other messages until he has enough space to store the new mes-
   sage.

   Since he is running in interactive mode, changes he makes to any mes-
   sages will immediately be transmitted into DMSP operations and sent
   to the repository.  Depending on the client implementation, Fred will
   either have to execute a "synchronize" command periodically or the
   client will synchronize for him automatically every so often.





Clark & Lambert                                                [Page 18]

RFC 993                                                    December 1986


7. A current Pcmail implementation

   The following section briefly describes a current Pcmail system that
   services a small community of users.  The Pcmail repository runs
   under UNIX on a DEC VAX-750 connected to the Internet.  The clients
   run on IBM PCs, XTs, and ATs, as well as Sun workstations, Micro-
   vaxes, and VAX-750s.

7.1. IBM PC client code

   Client code for the IBM machines operates only in batch mode.  Users
   make local state changes, which are queued until the client connects
   to the repository.  At that time, the changes are performed and the
   local and global states synchronized.  The client then disconnects
   from the repository.

   Users access and modify their local mail state via a user interface
   program.  The program uses windows and a full-screen mode of opera-
   tion.  Users are given a variety of commands to operate on individual
   messages as well as mailboxes.  The interface allows use of any text
   editor to compose messages, and adds features of its own to make
   RFC-822-style header composition easier.

   Synchronization and the processing of queued changes is performed by
   a separate program, which the user runs whenever he wishes.  The pro-
   gram takes any actions queued while operating the user interface, and
   converts them into DMSP operations.  All queued changes are made be-
   fore any synchronization is performed.

   The limitation of IBM PC client operation to batch mode was made be-
   cause of development environment limitations.  The user interface
   could not work with the network code inside it due to program size
   limitations.  Since MS-DOS has no multi-processing facilities, the
   two programs could not run in tandem either.  The only solution was
   to provide a two-part client, one part of which read the mail and one
   part of which interacted with the repository.

7.2. UNIX client code

   Client code for the Suns, Microvaxes, and VAX-750s runs on 4.2/4.3BSD
   UNIX.  It is fully interactive, with a powerful user interface inside
   Richard Stallman's GNU-EMACS editor.  Since UNIX-based workstations
   have a good deal of main memory and disk storage, no effort was made
   to lower local mail state size by keeping message descriptors rather
   than message text.

   The local mail state consists of a number of BABYL-format mailboxes.
   The interface is very similar to the RMAIL mail reader already
   present in GNU-EMACS.

   The user interface communicates with the repository through a DMSP



Clark & Lambert                                                [Page 19]

RFC 993                                                    December 1986


   implementation built into the GNU-EMACS kernel.  Changes to the local
   mail state are immediately made on the repository; the repository is
   fast enough that there is little noticeable delay in performing the
   operation over the network.

   There is no provision for automatic synchronization whenever new mail
   arrives or old mail is changed by another client.  Instead, users
   must get any new mail explicitly.  A simple "notification" program
   runs in the background and wakes up every minute to check for new
   mail; when mail arrives, the user executes a command to get the new
   mail, synchronizing the mailbox at the same time.

7.3. Repository code

   The repository is implemented in C on 4.2/4.3BSD UNIX.  Currently it
   runs on DEC VAX-750s and Microvaxes, although other repositories will
   soon be running on IBM RT machines and Sun workstations.  The reposi-
   tory code is designed to allow several clients belonging to a partic-
   ular user to "concurrently" modify the user's state.  A mailbox lock-
   ing scheme prevents one client from modifying a mailbox while another
   client is modifying the same mailbox.

8. Conclusions

   Pcmail is now used by a small community of people at the MIT Labora-
   tory for Computer Science.  The repository design works well, provid-
   ing an efficient means of storing and maintaining mail state for
   several users.  Its performance is quite good when up to ten users
   are connected; it remains to be seen whether or not the repository
   will be efficient at managing the state of ten or a hundred times
   that many users.  Given sufficient disk storage, it should be able
   to, since communication between different users' clients and the re-
   pository is likely to be very asynchronous and likely to occur in
   short bursts with long "quiet intervals" in between as users are busy
   doing other things.

   Members of another research group at LCS are currently working on a