<!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>