Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!ucsd!ucbvax!LCS.MIT.EDU!MAP
From: MAP@LCS.MIT.EDU (Michael A. Patton)
Newsgroups: comp.protocols.tcp-ip
Subject: Reliable protocols on top of email
Message-ID: <8909201935.AA09671@gaak.LCS.MIT.EDU>
Date: 20 Sep 89 19:35:59 GMT
References: <12785@joshua.athertn.Atherton.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24


	Joshua Levy asks about considering E-Mail as an unreliable
datagram transport and using existing protocols to make it reliable.

From reading the description later, I would guess what you want has
different characteristics than "reliable stream" or "reliable single
transaction" approaches.  You may want to think out the design of the
reliability part of your protocol in a different light.  One thing to
ask is do you care about ordering?  It seems to me that the thing you
are designing is basically a standard distributed transaction protocol
over a replicated and distributed database, all the standard synchrony
and ordering considerations apply.  Since I expect you want it to be
running in more than two locations, you have to consider whether you
require serializability and if so what kind.  Then you need to think
about which of the various methods you wish to use.  Most of these are
topics of current research.  There are many designs which have various
features, different tradeoffs, or restrictions.  The problem here is
that once you realize that you are proposing a distributed database
maintained at more than two nodes you discover that the simple
peer-to-peer models are not quite adequate.

I might be able to dredge up some references from the course I took 18
months ago, but starting from more current articles on transaction
protocols might be better.