rfc1056.txt

<VC++网络游戏建摸与实现>源代码

4.3. DMSP sessions

   A DMSP session proceeds as follows: a client begins the session with
   the repository by opening a connection to the repository's machine.
   The client then authenticates both itself and its user to the
   repository with a "login" operation.  If the authentication is
   successful, the user performs an arbitrary number of DMSP operations
   before ending the session with a "logout" operation, at which time
   the connection is closed by the repository.

   Because DMSP can manipulate a pair of mail states (local and global)
   at once, it is extremely important that all DMSP operations are
   failure-atomic.  Failure of any DMSP operation must leave both states
   in a consistent, known state.  For this reason, a DMSP operation is
   defined to have failed unless an explicit acknowledgement is received
   by the operation initiator.  This acknowledgement consists of a
   response code possibly followed by information, as described above.

   Following is a general discussion of all the DMSP operations.  The
   operations are broken down by type: general operations, user
   operations, client operations, mailbox operations, address
   operations, subscription operations, and message operations.
   Detailed operation specifications appear at the end of this document.

4.4. General operations

   The first group of DMSP operations perform general functions that
   operate on no one particular class of object.  DMSP has three general
   operations which provide the following services:

   In order to prevent protocol version skew between clients and the
   repository, DMSP provides a "send-version" operation.  The client
   supplies its DMSP version number as an argument; the operation
   succeeds if the supplied version number matches the repository's DMSP
   version number.  It fails if the two version numbers do not match.
   The version number is a natural number like "100", "101", "200".  The
   "send-version" operation should be the first that a client sends to
   the repository, since no other operation may work correctly if the
   client and repository are using different versions of DMSP.

   Users can send mail to other users via the "send-message" operation.
   The message must have an Internet-style header as defined by NIC
   RFC-822.  The repository takes the message and distributes it to the
   mailboxes specified by the message header's destination fields.  If
   one or more of the mailboxes exists outside the repository's user
   community, the repository is responsible for handing the message to a



Lambert                                                        [Page 11]

RFC 1056                         PCMAIL                        June 1988


   local SMTP server.  The message envelope is generated by the
   repository from the message contents since it may be difficult for
   some clients to perform envelope-generation functions such as address
   verification and syntax checking.

   A success acknowledgement is sent from the repository only if (1) the
   entire message was successfully transmitted from client to
   repository, and (2) the message header was properly formatted.  Once
   the repository has successfully received the message from the client,
   any subsequent errors in queueing or delivery must be noted via
   return mail to the user.

   The last general operation is the "help" operation.  The repository
   responds to "help" by printing an acknowledgement followed by a list
   of supported commands, terminated with a period plus CR-LF.  The
   information is intended for display and can be in any format as long
   as the individual lines of text returned by the repository are CR-
   LF-terminated.

4.5. User operations

   The next series of DMSP operations manipulates user objects.  The
   most common of these operations are "login" and "logout".  A client
   must perform a login operation before being able to access a user's
   mail state.  A DMSP login operation takes five arguments: (1) the
   user's name, (2) the user's password, (3) the name of the client
   performing the login, (4) a flag set to 1 if the repository should
   create a client object for the client if one does not exist (0 else),
   and (5) a flag set to 1 if the client wishes to operate in "batch
   mode" and 0 if the client wishes to operate in "interactive" mode.
   The last flag value allows the repository to tune internal parameters
   for either mode of operation.

   The repository can make one of three responses.  First, it can make a
   success response, indicating successful authentication.  Second, it
   can make one of several failure responses, indicating failed
   authentication.  Finally, it can make a special response indicating
   that authentication was successful, but that the client has not been
   used in over a week.  This last response serves as a hint that the
   client should consider erasing its local mail state and pulling over
   a complete version of the repository's mail state.  This is done on
   the assumption that so many mail state changes have been made in a
   week that it would be inefficient to perform a normal
   synchronization.

   When a client has completed a session with the repository, it
   performs a logout operation.  This allows the repository to perform
   any necessary cleanup before closing the network connection.



Lambert                                                        [Page 12]

RFC 1056                         PCMAIL                        June 1988


   A user can change his password via the "set-password" operation.  The
   operation works much the same as the UNIX change-password operation,
   taking as arguments the user's current password and a desired new
   password.  If the current password given matches the user's current
   password, the user's current password is changed to the new password
   given.  Because encryption can be difficult to perform on some
   resource-poor clients, passwords are transmitted in clear text.
   Clearly this is not an acceptable long-term solution, and
   alternatives are welcomed.

4.6. Client operations

   DMSP provides four operations to manipulate client objects.  The
   first, "list-clients", tells the repository to send the user's client
   list to the requesting client.  The list is a series of lines, one
   per client, containing the client's name, followed by whitespace,
   followed by a status string.  The status is either "inactive" or
   "active".  As with all text responses, the list is terminated with a
   period plus CR-LF.

   The "create-client" operation allows a user to add a client object to
   his list of client objects.  Although the login operation duplicates
   this functionality via the "create-this- client?" flag, the create-
   client operation is a useful means of creating a number of new client
   objects while logged into the repository via an existing client.  The
   create-client operation requires as an argument the name of the
   client to create.

   The "delete-client" operation removes an existing client object from
   a user's client list.  The client being removed cannot be in use by
   anyone at the time.  Delete-client also requires as an argument the
   name of the client to delete.

   The last client operation, "reset-client", causes the repository to
   place all of the messages in all mailboxes onto the named client's
   update list.  When a client next synchronizes with the repository, it
   will end up receiving a list of all descriptors when it requests a
   list of changed message descriptors for a particular mailbox.  This
   is useful for two reasons.  First, a client's local mail state could
   easily become lost or damaged, especially if it is stored on a floppy
   disk.  Second, if a client has been marked as inactive by the
   repository, the reset-client operation provides a fast way of
   resynchronizing with the repository, assuming that so many
   differences exist between the local and global mail states that a
   normal synchronization would take far too much time.






Lambert                                                        [Page 13]

RFC 1056                         PCMAIL                        June 1988


4.7. Mailbox operations

   DMSP supports seven operations that manipulate mailbox objects.
   First, "list-mailboxes" has the repository send to the requesting
   client information on each mailbox.  The repository transmits one
   line of information per mailbox, terminating the list with a period
   plus CR-LF.  Each line contains, in order and separated by
   whitespace, the mailbox name, "next available UID", total message
   count, and unseen message count.  This operation is useful in
   synchronizing local and global mail states, since it allows a client
   to compare the user's global mailbox list with a client's local
   mailbox list.  The list of mailboxes also provides a quick summary of
   each mailbox's contents without having the contents present.

   The "create-mailbox" has the repository create a new mailbox and
   attach it to the user's list of mailboxes.  It takes as an argument
   the name of the mailbox to create.

   "Delete-mailbox" removes a mailbox from the user's list of mailboxes.
   All messages within the mailbox are also deleted and permanently
   removed from the system.  Any address objects binding the mailbox
   name to RFC-822-style mailbox addresses are also removed from the
   system.  Delete-mailbox takes as an argument the name of the mailbox
   to delete.

   "Create-bboard-mailbox" allows a user to create a bboard mailbox.
   The name given as an argument must be unique across the entire
   repository user community.  Once the bboard mailbox has been created,
   other users may subscribe to it, using subscription objects to keep
   track of which messages they have read on which bboard mailboxes.

   "Delete-bboard-mailbox" allows a bboard's owner to delete a bboard
   mailbox.  Subscribers who attempt to read from a bboard mailbox after
   it has been deleted are told that the bboard no longer exists.
   Again, the operation's argument is the name of the bboard mailbox to
   delete.

   "Reset-mailbox" causes the repository to place all of the messages in
   a named mailbox onto the current client's update list.  When the
   client next requests a list of changed message descriptors for this
   mailbox, it will receive a list of all message descriptors in the
   mailbox.  This operation is merely a more specific version of the
   reset-client operation (which allows the client to pull over a
   complete copy of the user's global mail state).  Its primary use is
   for mailboxes whose contents have accidentally been destroyed
   locally.

   Finally, DMSP has an "expunge-mailbox" operation.  Any message can be



Lambert                                                        [Page 14]

RFC 1056                         PCMAIL                        June 1988


   deleted and "undeleted" at will, since this simply changes the value
   of a flag attached to the message.  Deletions are made permanent by
   performing an expunge-mailbox operation.  The expunge operation
   causes the repository to look through a named mailbox, removing from
   the system any messages marked "deleted".  Expunge-mailbox takes as
   an argument the name of the mailbox to expunge.

4.8. Address operations

   DMSP provides three operations that allow users to manipulate address
   objects.  First, the "list-address" operation returns a list of
   address objects associated with a particular mailbox.  Each address
   is transmitted on a separate line terminated by a CR-LF; the list is
   terminated with a period plus CR-LF.

   The "create-address" operation adds a new address object that
   associates a (user-name, mailbox-name) pair with a given RFC-822-
   style mailbox address.  It takes as arguments the mailbox name and
   the address name.

   Finally, the "delete-address" operation destroys the address object
   binding the given RFC-822-style mail address and the given (user-
   name, mailbox-name) pair.  Arguments are the address to delete and
   the mailbox it belongs to.

4.9. Subscription operations

   DMSP provides five subscription operations.  The first, "list-
   subscriptions", gives the user a list of the bboards he is currently
   subscribing to.  The list consists of one line of information per
   subscription.  Each entry contains the following information, in
   order:

      - The bulletin board's name

      - The UID of the first message the subscriber has not yet
        seen

      - The number of messages the subscriber has not yet seen

      - The highest message UID in the bulletin board

   "List-available-subscriptions" gives the user a list of all bboards
   he can subscribe to.  The list consists of bboard names, one per
   line, terminated by a period plus CR-LF.  "Createsubscription" adds a
   subscription to the user's list of subscriptions; it takes as an
   argument the name of the bboard to subscribe to.  "Delete-
   subscription" removes a subscription from the list, and takes as an



Lambert                                                        [Page 15]

RFC 1056                         PCMAIL                        June 1988


   argument the name of the subscription to remove.  Note that this does
   not delete the associated bboard mailbox (obviously only the bboard's
   owner can do that).  It merely removes the user from the list of the
   bboard's subscribers.  Finally DMSP allows the user to tell the
   repository which messages in a bboard he has seen.  Every
   subscription object contains the UID of the first message the user