<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT size=3><FONT face=Arial color=#0000ff
size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<BLOCKQUOTE class=cite cite="" type="cite">In absence of any protocol level
ack (and regardless of protocol level ack), it is the application which has
to implement its own reliability. RDS becomes a passive channel passing
packet back and forth including duplicate packets. The responsibility then
shifts to the application to figure out what is missing, duplicate's
etc.</FONT></BLOCKQUOTE>
<DIV><BR>This would seem at odds with earlier assertions that as long as there
were another path to the endnode, RDS would transparently recover on behalf of
the application. I thought Oracle stated for their application that send
failure would be interpreted as endnode failure and cast out the peer -
perhaps I misread their usage model. Other applications who might want
to use RDS could be designed to deal with the associated faults but if one has
to deal with recovery / resync at the application layer, then that is quite a
bit of work to perform in every application and is again at odds with the
purpose of RDS which is to move reliability to the interconnect to the extent
possible and to RDS so that the UDP application does not need to take on this
complex code and attempt to get it right.<BR><BR><BR><SPAN
class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>[cait] </FONT></SPAN></DIV>
<DIV><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV></BLOCKQUOTE>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>I would agree that there isn't much point in defining a "reliable"
datagram service unless it is more</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>reliable than unreliable.</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>To me that means that the the transport should deal with all networking
problems other than a</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>*total* failure to re-establish contact with the remote end. That
makes it basically equivalent </FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>of a point-to-point Reliable Connection.</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>The biggest difference, and justification, for having something
like RDS is to eliminate point-to-point</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>flow control and allow it to be replaced with ULP based flow control
that is not point-to-point. The</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>resources associated with tracking credits is where a lot of the overhead
inherent in multiple</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>point-to-point connections come from (that, and the synchronization of
that data over the</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff
size=2>network).</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005> </SPAN></DIV></BODY></HTML>