Hard Question...Re: The Lazy Susan...RE: [p2p-hackers] Hard question....

Lemon Obrien lemonobrien at yahoo.com
Sun Apr 2 05:57:56 UTC 2006


given my alogrythm...timestamp the 'stream-file' message; or when sent to save space...and for each 'file-data' packet received calculate the running average of ( now - timestamp ) / # sequences recieved.
   
  Can't resend anything unless we've recieved something...how long to wait; if the connection goes down it should end rather quickly...responsively?

Lemon Obrien <lemonobrien at yahoo.com> wrote:
    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. 
   
  Y sends EOF. and X can send close closing the session streaming on Y.
   
  data is read in sequence as a stream.
   
  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.
   
  i can calculate a runing-mean to some elasped-total.
   
   
  

Matthew Kaufman <matthew at matthew.at> wrote:
  Bob Harris:
> With coding, there is no need for a back channel from the
receiver-to-sender for 
> resends.


Forward error correction has its place, but it is no excuse for eliminating
the feedback necessary to perform proper congestion control. There are
numerous reasons why protocols which fail to perform congestion control
(including RTP, as used for VOIP) are a bad idea for both the individual
user (end-link saturation, excess queueing, impact on the congestion
management of parallel TCP flows, routers which drop or de-prioritize
nonconforming flows, etc.) and the Internet as a whole (router queueing,
congestion collapse, etc.).

TCP or protocols with TCP-friendly congestion management are mandatory for
bulk transfer of data. TCP is the easy answer. Reimplementing TCP on UDP or
using TFRC on UDP is the not-so-easy answer.

My personal (albeit biased) suggestion is to use amicima's MFP, which gets
you congestion controlled delivery for both reliable *and* unreliable flows,
among many other features.

Matthew Kaufman
matthew at matthew.at
http://www.amicima.com


_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences



You don't get no juice unless you squeeze
Lemon Obrien, the Third._______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences



You don't get no juice unless you squeeze
Lemon Obrien, the Third.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060401/298b958e/attachment.html


More information about the P2p-hackers mailing list