\documentstyle[fullpage]{article}
\title{Grapevine Message Delivery}
\author{Greg Hudson}
\begin{document}

The Grapevine message delivery system aims for high avilability of
delivery service in the face of machine crashes and network outages.
However, the system does not guarantee any minimum delivery time when
a server can be reached.  Thus, messages can arrive without previous
messages which may supply important context, which may confuse users
of the system.

When a client wishes to send a message, it connects to the nearest
available message server, and transmits the message.  The message
server acknowledges the message for transmission, and the client goes
on its way.  It is now the message server's job to transmit the
message to the inboxes of everyone the message is addressed to.  If
the server crashes before finishing this process, the message may be
indefinitely delayed.

In the mean time, the same client or another client may come up with a
message to transmit which depends on the context of the delayed
message.  If the procedure were to wait for the message server to
become available again, there would be no discontinuity, since the
message server would deliver the delayed message before the new
message.  The current implementation will deliver the new message
first, though, possible confusing the recipient.  Note that this
scenario may take place even if all the the recipient's inbox servers
remain up.

One possible way to address this issue is to let the client know when
and whether the message server has successfully delivered the message
to all inboxes.  This requires fairly clever error-handling on the
part of the client, since there is quite often at least one failed
transmission for any message to a large list.  Also, it is not clear
how long the client should wait before assuming that transmission was
unsuccessful, and one cannot decide automatically whether or not to
resend a message.  Simplicity may be more important than consistency
in this case.

Another possibility is to fail to deliver messages when the local
message server is down, rather than using the next available server.
This is probably not beneficial in the long run, since users are
probably more concerned about availability than the possibility of
minor confusion.

We have seen that Grapevine's message delivery system may allow
messages to arrive before important context-supplying previous
messages, but that this may be reasonable given the complexity or
availability costs of the possible solutions.

\end{document}

