Return-Path: william@bourbon.usc.edu Delivery-Date: Sat Apr 28 13:26:25 2007 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, NO_REAL_NAME autolearn=ham version=3.1.3 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.13.5/8.13.5) with ESMTP id l3SKQPtq003690 for ; Sat, 28 Apr 2007 13:26:25 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.13.5/8.13.5) with ESMTP id l3SKPmCc005383 for ; Sat, 28 Apr 2007 13:25:48 -0700 Message-Id: <200704282025.l3SKPmCc005383@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: End-game mode for BitTorrent Date: Sat, 28 Apr 2007 13:25:48 -0700 From: william@bourbon.usc.edu Someone wrote: > We have the following on p. 27 of the following slide: > > http://merlot.usc.edu/cs551-s07/lectures/lecture20/slides.pdf > > What does it mean to "send all sub-pieces request to all > peers after all data sub-pieces request are sent?" > > Specifically, is there any difference between the two "sub-pieces" > mentioned here? I asked the person who created this slide and after some investigation, it seemed that I may have explained things incorrectly regarding the "end-game" mode. In class, I explained that the "end-game" mode is used when there is only one piece of data that a node does not have, so it sends requests for all the sub-pieces of this piece to all peers. This may be a wrong explanation. It looks like the "end-game" mode applies to *every piece* of data. Typically, a piece is 256KB and it is divided into 16 sub-pieces (16KB each). For a piece that has missing sub-pieces, it may send a request for a sub-piece to one peer and send a request for another sub-piece to a different peer. Internally, this node keeps track of what sub-piece requests have been sent. When *all the sub-piece requests have been sent*, it enters the "end-game" mode for this piece and *sends all sub-pieces request to all peers*. I think this explanation is better than the one given inclass. (I haven't read the code, so I don't know for sure if this interpretation is 100% correct.) -- Bill Cheng // bill.cheng@usc.edu