<!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
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV><BR>My concern is the requirement that RDS resync the structures in the
face of failure<BR>and know whether to re-transmit or will deal with
duplicates. Having pre-posted buffers<BR>will help enable the resync to
be accomplished but should not be equated to pre-post equals<BR>one can deal
with duplicates or will verify to prevent duplicates from
occurring.<BR><BR>Mike</FONT> <BR><SPAN class=948525920-10112005><FONT
face=Arial color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV></BLOCKQUOTE>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>The
semantics should be that barring an error the flow between any
two</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>endpoints is reliable and ordered.</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>The
difference versus a normal point-to-point definition of reliable is
that</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>a)
lack of a receive buffer is an error, b) the endpoint
communicates</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>with
many known remote peers (as opposed to one known remote</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>peer,
or many unknown).</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>Having
an API with those semantics, particularly as an upgrade in</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>semanitcs from </FONT></SPAN><SPAN class=948525920-10112005><FONT
face=Arial color=#0000ff size=2>SOCK_DGRAM while preserving
SOCK_DGRAM</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>syntax, is something that I believe is of distinct value to
many</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>cluster based applications. Further the API can be
implemeneted</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff size=2>in an
offload device (IB or IP) more efficiently than if it is
simply</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>implemented on top of SOCK_STREAM sockets by the
application.</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>Documenting and clarifying the semantics to make it's general
applicability</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2>clearer </FONT></SPAN><SPAN class=948525920-10112005><FONT face=Arial
color=#0000ff size=2>should definitely be done, however.</FONT></SPAN></DIV>
<DIV><SPAN class=948525920-10112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV></BODY></HTML>