<html>
<body>
<font size=3>At 02:09 PM 11/9/2005, Greg Lindahl wrote:<br>
<blockquote type=cite class=cite cite="">On Wed, Nov 09, 2005 at
01:57:06PM -0800, Michael Krause wrote:<br><br>
> What you indicate above is that RDS <br>
> will implement a resync of the two sides of the association to
determine <br>
> what has been successfully sent.<br><br>
More accurate to say that it "could" implement that. I'm
just<br>
kibbutzing on someone else's proposal.<br><br>
> This then implies that the reliability of the underlying<br>
> interconnect isn't as critical per se as the end-to-end RDS
protocol<br>
> will assure that data is delivered to the RDS components in the
face<br>
> of hardware failures. Correct?<br><br>
Yes. That's the intent that I see in the proposal. The
implementation<br>
required to actually support this may not be what the proposers had
in<br>
mind.</font></blockquote><br>
If it is to be reasonably robust, then RDS should be required to support
the resync between the two sides of the communication. This aligns
with the stated objective of implementing reliability in one location in
software and one location in hardware. Without such resync being
required in the ULP, then one ends up with a ULP that falls shorts of its
stated objectives and pushes complexity back up to the application which
is where the advocates have stated it is too complex or expensive to get
it correct.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>This sort of
message service, by the way, has a long history in distributed
computing.</font></blockquote><br>
Yep. <br><br>
Mike</body>
</html>