Return-Path: william@bourbon.usc.edu Delivery-Date: Fri Apr 20 19:39:39 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 l3L2ddX8025165 for ; Fri, 20 Apr 2007 19:39:39 -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 l3L2dUIK019604 for ; Fri, 20 Apr 2007 19:39:30 -0700 Message-Id: <200704210239.l3L2dUIK019604@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: CS551 - Final Project - Question on Grading guidelines Date: Fri, 20 Apr 2007 19:39:30 -0700 From: william@bourbon.usc.edu Someonew rote: | What is meant by: | | > 2. If the file comes from the other two nodes, it should check | > before attempting to store and find that it already has a copy of the same | > file, and discard the response. | | Don't we get files based on the "FileID" which is unique (or atleast | supposed to be) across the network. Correct. But FileID is not part of the file's metadata. It's simply an identifier for the sole purpose of retrieving the file using GET. | So when a user does "get 1" or "get 2" | etc... it actually means get the file with this particular FileID. So if a | user happens to do a get for a FileID that is remote, we still have to get | that remote copy for the user and not the local one. Right? Correct. But when you eventually receive the file, you will attempt to store it in the mini-filesystem. At this time, you should noticed that you already have a file that is identical (with the same FileName, SHA1, and Nonce) to the file you are retrieving! So, the GET should be treated as *successful*, although you discard the copy of the file that you just got. -- Bill Cheng // bill.cheng@usc.edu On 4/20/07, william@bourbon.usc.edu wrote: > Someone wrote: > > > From your response to the question below, what I understand from > > this particular test case is that there is only one copy (same nonce, > sha1, > > filename) of the file "blondie1.mp3" stored in the network when user > invoked > > > > in 1st window, type: > > store blondie1.mp3 1 title="Heart of Glass" > > > > At this point, node at 3rd window should have this file in its cache > > space. After it searches and gets 3 responses, no matter if user does > "get 1 > > 2 or 3", this should always succeed and hence make a copy of the file in > CWD > > because: > > 1. If the file corresponding to 'get' number is a local copy, it > > should simply move it to permanent space. > > 2. If the file comes from the other two nodes, it should check > > before attempting to store and find that it already has a copy of the > same > > file, and discard the response. > > So the permanent space should NEVER be exceeded in this case since > > there is only one file in the network, and a node MUST always have only > one > > copy of the file. I suspect that the person who got the storage exceeded > > must not check for file duplicate before he attempts to store the > received > > file. Please let me know what you think. > > Your analysis is correct! I'm reverting the grading guidelines > back to the previous version! > > Sorry about my confusion! > -- > Bill Cheng // bill.cheng@usc.edu > > > > > > > -----Original Message----- > From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu] > Sent: Friday, April 20, 2007 2:40 PM > To: cs551@merlot.usc.edu > Subject: Re: CS551 - Final Project - Question on Grading guidelines > > Someone wrote: > > > For Test Case (A) Beacon-only networks -> (2) Network with 3 beacon > nodes > > > > The configuration parameters are set with CacheSize=600 and > PermSize=600 > > (These are in KB). > > > > For the following part of the test case: > > > > in 3rd window, type: > > (+1 points) > > search filename=blondie1.mp3 > > should get three responses, then do > > (+1 points) > > get 1 > > "blondie1.mp3" should be created in the > > current directory > > > > in the 4th window, type at the UNIX prompt: > > "ls -l blondie1.mp3" > > (file size should be 474736) > > "openssl sha1 blondie1.mp3" > > (should be > > > ffd3b197e1c0f0c27e7bdc219f553a3e6b139dfb) > > "rm blondie1.mp3" > > > > > > > > =========================> At this point 400 KB of the Perm space is > used > > up; which mean approx 200 KB of perm space is available. If the > following > > "get" commands are executed, then the node at window 3 will not be > able to > > save the file in the permanent area (due to lack of free space 400KB > > > > 200KB) and hence will not be able to provide the file to the user. So > are > > the subsequent steps correct? > > > > in 3rd window, type: > > (+1 points) > > get 2 > > "blondie1.mp3" should be created in the > > current directory > > > > in the 4th window, type at the UNIX prompt: > > "ls -l blondie1.mp3" > > "openssl sha1 blondie1.mp3" > > "rm blondie1.mp3" > > > > in 3rd window, type: > > (+1 points) > > get 3 > > "blondie1.mp3" should be created in the > > current directory > > > > in the 4th window, type at the UNIX prompt: > > "ls -l blondie1.mp3" > > "openssl sha1 blondie1.mp3" > > "rm blondie1.mp3" > > You are correct. I have just changed the grading guidelines > to say that "get 2" should not succeed and I removed "get 3" > and move the +1 point to "get 1". > > Thanks for catching the bug! > -- > Bill Cheng // bill.cheng@usc.edu