<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 'file-data' to X. </div> <div> </div> <div>Y sends EOF. and X can send close closing the session streaming on Y.</div> <div> </div> <div>data is read in sequence as a stream.</div> <div> </div> <div>messages are relayed...i call it lazy cause a resend is only sent when a sequence is determined to be missing. I believe tcp does an 'ack' for each node it traverses.</div> <div> </div> <div>i can calculate a runing-mean to some elasped-total.</div> <div> </div> <div> </div> <div><BR><BR><B><I>Matthew Kaufman <matthew@matthew.at></I></B> wrote:</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff
2px solid">Bob Harris:<BR>> With coding, there is no need for a back channel from the<BR>receiver-to-sender for <BR>> 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.