Delivery-Date: Fri Nov 14 13:06:32 2008
Message-Id: <200811142102.mAEL2Hr1017248@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: 5 questions about cs551 final project
Date: Fri, 14 Nov 2008 13:02:17 -0800
From: Bill Cheng <william@bourbon.usc.edu>

Someone wrote:

  > 1. In the spec, "All 3 index structures must have a disk image so that 
  > after a node restarts (after a crash or a shutdown), it can reconstruct 
  > the in-memory index structures in a timely fashion."
  >     Does it mean whenever we change in-memory index structures, we have 
  > to change the disk image(the file) immediately? (in case it crash suddenly)

That's one way to do it.  (If you are sure you code does not
have any bugs, then you can write things out when your node
goes down.  But if a power outage happens, then it would be
problematic.)

  > 2. In the Bit-vector part of spec, "If the left half of the resulting 
  > bit-vector is not a vector of zeros, and the right half of the resulting 
  > bit-vector is not a vector of zeros, then it is possible that there may 
  > be keyword match"
  >     What if we enter 3 keywords, and only one keyword match in the 
  > bit-vector(only one bit is set in the left half and only one bit is set 
  > in the right half), do we consider this as potential match and continue 
  > compare all keywords in the file?

If you enter 2 or more keywords, then you should do the
following.  Construct a query bit-vector; let's call this Q.
For each file bit-vector B, we do a bit-wise AND of Q and B.
If the result equals Q, then we have a potential match (and
proceed with string compares).  Otherwise, we declare that
there is no match and move to the next file bit-vector.

  > 3. In the spec, "Please note that a get command should not be allowed if 
  > it does not immediately follow a search or a get command"
  >     I don't quite understand why a get command would follow another get 
  > command.

If your search returns 7 results, you should be able to do
"get 1 file1", immediately followed by "get 2 file2",
immediately followed by "get 3 file3", etc.

  > 4. About deleting a file in the spec, "If it does not have the 
  > corresponding password, it should prompt the user to see if it is okay 
  > to send a delete message based on the random password"
  >     I don't quite understand that since it doesn't have the password, 
  > this illustrate that this node is not the original owner of the file, it 
  > shouldn't have authorization to delete this file.

Correct!  This is mainly for grading purpose!  If you flood
a delete with an invalid password, nodes should not delete
the corresponding file.

  > 5. Continue with Q4, when a node receive a delete message, should it 
  > compute SHA1 of password inside the message and compare it with the 
  > nonce? If it matches, I delete; if it doesn't I ignore this message.

Exactly!
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>