<div>I'm passive aggresive so my algorythms tend to be...X sends 'stream-file' to Y, Y sends chunks of 'file-data' sequenced and sessioned back to X. X stores all 'file-data' as they appear and sends 'resend' when a sequence is missing; Y calulates according to sequence; and sends&nbsp; 'file-data'&nbsp;to X. </div>  <div>&nbsp;</div>  <div>Y sends EOF. and X can send close closing the session streaming on Y.</div>  <div>&nbsp;</div>  <div>data is read in sequence as a stream.</div>  <div>&nbsp;</div>  <div>messages are relayed...i call it lazy cause a resend is only sent when a sequence is determined to be missing. I&nbsp;believe tcp does an 'ack' for each node it traverses.</div>  <div>&nbsp;</div>  <div>i can calculate a runing-mean to some elasped-total.</div>  <div>&nbsp;</div>  <div>&nbsp;</div>  <div><BR><BR><B><I>Matthew Kaufman &lt;matthew@matthew.at&gt;</I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff
 2px solid">Bob Harris:<BR>&gt; With coding, there is no need for a back channel from the<BR>receiver-to-sender for <BR>&gt; resends.<BR><BR><BR>Forward error correction has its place, but it is no excuse for eliminating<BR>the feedback necessary to perform proper congestion control. There are<BR>numerous reasons why protocols which fail to perform congestion control<BR>(including RTP, as used for VOIP) are a bad idea for both the individual<BR>user (end-link saturation, excess queueing, impact on the congestion<BR>management of parallel TCP flows, routers which drop or de-prioritize<BR>nonconforming flows, etc.) and the Internet as a whole (router queueing,<BR>congestion collapse, etc.).<BR><BR>TCP or protocols with TCP-friendly congestion management are mandatory for<BR>bulk transfer of data. TCP is the easy answer. Reimplementing TCP on UDP or<BR>using TFRC on UDP is the not-so-easy answer.<BR><BR>My personal (albeit biased) suggestion is to use amicima's MFP, which
 gets<BR>you congestion controlled delivery for both reliable *and* unreliable flows,<BR>among many other features.<BR><BR>Matthew Kaufman<BR>matthew@matthew.at<BR>http://www.amicima.com<BR><BR><BR>_______________________________________________<BR>p2p-hackers mailing list<BR>p2p-hackers@zgp.org<BR>http://zgp.org/mailman/listinfo/p2p-hackers<BR>_______________________________________________<BR>Here is a web page listing P2P Conferences:<BR>http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences<BR></BLOCKQUOTE><BR><BR><BR>You don't get no juice unless you squeeze<br>Lemon Obrien, the Third.