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
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
replicated, scalable version of the repository designed to support a
very large community of users with high availability. This reposito-
ry also uses DMSP and has successfully communicated with clients that
use the current repository implementation. DMSP therefore seems to
be usable over several flavors of repository design.
The IBM PC clients are unfortunately very limited in the way of
resources, making local mail state manipulation difficult at times.
Synchronization is also relatively time consuming due to the low per-
formance of the PCs. The "batch-mode" that the PCs use tends to be
good for those PCs that spend a large percentage of their time un-
plugged and away from a network. It is somewhat inconvenient for
those PCs that are always connected to a network and could make good
use of an "interactive-mode" state manipulation.
The UNIX-based clients are far easier to use than their PC counter-
parts. Synchronization is much faster, and there is far more func-
tionality in the user interface (having an interface that runs within
GNU-EMACS helps a lot in this respect). Most of those people using
the Pcmail system use the UNIX-based client code.
APPENDIX
A. DMSP Protocol Specification
Following are a list of DMSP operations by object type, their block
types and arguments, and their expected acknowledgement block types.
Each DMSP block has a different number; the first digit of each block
type defines the object being manipulated: Operations numbered 5xx
are general, operations numbered 6xx are user operations, operations
numbered 7xx are client operations, operations numbered 8xx are mail-
box operations, operations numbered 9xx are address operations,
operations numbered 10xx are bboard operations, and operations num-
bered 11xx are message operations.
Failure blocks contain two fields, a "code" and a "why". The "code"
is an unsigned number placing the error in one of several broad
categories (listed below). The "why" is a text string, possibly ex-
plaining the error in greater detail.
Error codes:
- 1: network error while reading or writing data
- 2: internal repository error. This can be due to lack
of memory, a fatal bug, lack of disk space, etc.
- 3: requested object already exists. For example, you
tried to create a mailbox that already exists
- 4: requested object not found. For example, you tried
to delete a message or a mailbox that doesn't exist.
- 5: protocol error. Typically DMSP protocol version
skew.
- 6: block argument error. For example, a "set-message-flag"
operation was attempted on a bboard by someone
other than the bboard's owner.
- 7: data read error. The repository was unable to read
the mail state information requested.
- 8: data write error. The repository was unable to
write out changed mail state information, perhaps
because the disk was full.
- 9: operating system error: Should be reserved for
things like fork or pipe call errors.
- 10: unexpected or unknown block type received. For
example, you sent a "delete-mailbox" block and received
a "mailbox-list" block in response.
Blocks marked "=>" flow from client to repository; blocks marked "<="
flow from repository to client. If more than one block can be sent,
the choices are delimited by "or" ("|") characters.
For clarity, each block type is put in a human-understandable form.
The block number is followed by an operation name; this name is never
transmitted as part of a USP block. Block arguments are identified
by name and type, and enclosed in square brackets. "Record" data
types are described by a list of "field-name:field-type" pairs con-
tained in square brackets. "Choice" data types are described by a
list of "tag-name:tag-type" pairs contained in square brackets. USP
data types are defined as follows (the definitions are brief; refer
to the USP specification for more detailed descriptions):
A.1. Primitive data types
string (S): a series of bytes, null-byte padded to even length and
preceded by a 16-bit length specifier. Strings are sent in "net-
ascii" format (newline sequence is carriage return followed by
linefeed, single carriage returns to be followed by a null byte).
- cardinal (C): a 16-bit unsigned number.
- long-cardinal (LC): a 32-bit unsigned number.
- integer (I): a 16-bit signed number.
- long-integer (LI): a 32-bit signed number.
- boolean (B): a 16-bit number with either a 1 or a 0 in the
16th bit.
A.2. Compound data types
- sequence (SEQ): A list of data items, all the same type and
preceded by a 16-bit sequence length specifier.
- array (AR): A fixed-length list of data items, all the same
type. A particular array's length is fixed by the application.
- record (REC): A list of data items of any type. A
particular record's format is fixed by the application.
- choice (CH): One of a list of possible data types. The data
type contained in the choice is identified by a 16-bit numeric
tag. The application interprets the data item based on the tag
value.
A.3. DMSP Abstract Data Types
Following are data types defined and used only by DMSP:
- client: a record with the following format:
REC[name:S, status:C] Status is either 1 (active) or 0
(inactive)
- mailbox: a record with the following format:
REC[name:S, next-uid:LC, #msgs:C, #new-msgs:C]
- bboard: a record with the following format:
REC[name:S, first-unread-message-UID:LC
number-of-unseen-messages:C highest-UID:LC]
- descriptor: a record with the following format:
- REC[UID:LC, flags:SEQ[B], from, to, date, subject:S,
#bytes:LC, #lines:LC]
- desc-choice: a choice with the following format:
CH[expunged-message-UID:LC, desc:descriptor] Descriptor
tag number is 1. Expunged-message tag number is 0.
A.4. General operations
=> 502 (send-version) [version:C]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 503 (send-message) [message:SEQ[S]]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
A.5. User operations
=> 600 (login) [name:S, password:S, client:S,
create-client-object?:B
batch-mode?:B]
<= 500 (ok) [] |
501 (failure) [code:C, why:S] |
705 (force-client-reset) []
=> 601 (logout) []
<= 500 (ok) []
=> 602 (set-password) [old:S, new:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
A.6. Client operations
=> 701 (list-clients) []
<= 700 (client-list) [client-list:SEQ[client]]
=> 702 (create-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 703 (delete-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 704 (reset-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
A.7. Mailbox operations
=> 801 (list-mailboxes) []
<= 800 (mailbox-list) [mailbox-list:SEQ[mailbox]]
=> 802 (create-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 803 (delete-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 804 (reset-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 805 (expunge-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S
A.8. Address operations
=> 901 (list-addresses) [mailbox:S]
<= 501 (failure) [code:C, why:S] |
900 (address-list) [address-list:SEQ[S]]
=> 902 (create-address) [mailbox:S, address:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 903 (delete-address) [mailbox:S, address:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
A.9. Bboard operations
=> 1001 (list-bboards) []
<= 1000 (bboard-list) [bboard-list:SEQ[bboard]]
501 (failure) [code:C, why:S]
=> 1002 (create-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1003 (delete-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1004 (subscribe-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1005 (unsubscribe-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1006 (set-bboard-first-unread) [name:S, UID:LC]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1007 (list-all-bboards) []
<= 1008 (bboard-name-list) [bboard-name-list:SEQ[S]]
501 (failure) [code:C, why:S]
A.10. Message operations
=> 1102 (get-descriptors) [mailbox:S,
low-uid:LC,
high-uid:LC]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=> 1103 (get-changed-descriptors) [mailbox:S,
max-to-send:C]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=> 1104 (reset-changed-descriptors) [
mailbox:S,
start-uid:LC,
end-uid:LC]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1105 (get-message-text) [mailbox:S,
uid:LC]
<= 501 (failure) [code:C, why:S] |
1101 (message) [message:SEQ[S]]
=> 1106 (print-message) [mailbox:S,
uid:LC,
printer-name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=> 1107 copy-message[source-mailbox:S,
target-mailbox:S,
source-uid:LC]
<= 501 (failure) [code:C, why:S]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=> 1108 (set-flag) [mailbox:S,
uid:LC,
flag-number:C,
flag-setting:B]
<= 500 (ok) [] |
501 (failure) [code:C, why:S] 30
DMSP block types by number
General block types
ok 500
failure 501
send-version 502
send-message 503
User operation block types
login 600
logout 601
set-password 602
Client operation block types
client-list 700
list-clients 701
create-client 702
delete-client 703
reset-client 704
force-client-reset 705
Mailbox operation block types
mailbox-list 800
list-mailboxes 801
create-mailbox 802
delete-mailbox 803
reset-mailbox 804
expunge-mailbox 805
Address operation block types
address-list 900
list-addresses 901
create-address 902
delete-address 903
Bboard operation block types
bboard-list 1000
list-bboards 1001
create-bboard 1002
delete-bboard 1003
subscribe-bboard 1004
unsubscribe-bboard 1005
set-bboard-first-unread 1006
get-n-new-bboard-descriptors 1007
list-all-bboards 1008
bboard-name-list 1009
Message operation block types
descriptor-list 1100
message 1101
get-descriptors 1102
get-changed-descriptors 1103
reset-changed-descriptors 1104
get-message-text 1105
print-message 1106
copy-message 1107
set-flag 1108