I think the bandwidth problems with remote access are pretty clear, but
they don't have that much to do with AFS. As to reading mail, you can
put the communication link in a number of places, assuming that you have
a remote server that can also do (local, high-bandwidth) AFS access for
you. As Lyle points out, AMDS delivers mail as separate messages in
your ~/Mailbox/ directory, and AMS stores/files mail as separate files
in a ~/.MESSAGES/mail/ directory, so AMS can, for the most part, just
rename the incoming messages. (Sometimes it has to add a header field,
though, in which case it has to copy the whole message.) AMS has
another interesting feature, though, which is to use a separate
``messageserver'' process to do all access to both incoming messages and
the message store; when that process is on the other side of your slow
link, it can do all the AFS-local copying and you can see just the bits
that are being displayed on your local machine. The more common
situation is likely the IMAP one, though, which is vaguely, sort of,
like a dressed-up messageserver in that the messages stay at the IMAP
server. Even if it uses a message store in AFS, it doesn't pay the
slow-link penalty except for specific communication that it does with
your client.
I had to respond to this one, though...
Excerpts from transarc.external.info-afs: 6-Oct-94 Re: SL/IP, AFS and
Applicat.. Rainer [EMAIL PROTECTED] (3238*)
> Also, at such slow speeds it would be nice to have a little window which
> shows which file/chunk is in the process of being transferred. The modem
> lights tell me in which direction, but it would be reassuring anyway.
I still run the old Andrew ToolKit ``console'' program that does exactly
this. You can get messages from the CM about file fetches and stores
via the ``fs monitor'' direction, but I know none of the details. I'd
guess that the argument for ``fs monitor'' is an address to which the CM
sends UDP messages to a distinguished port (2106). Yup, a hack, but an
entertaining one.
Disclaiming all, here....
Craig
