Return-Path: william@bourbon.usc.edu
Delivery-Date: Tue Oct 28 22:34:56 2008
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.3
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
	by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m9T5YutD013497
	for <cs551@merlot.usc.edu>; Tue, 28 Oct 2008 22:34:56 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
	by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id m9T5k8rk009236
	for <cs551@merlot>; Tue, 28 Oct 2008 22:46:08 -0700
Message-Id: <200810290546.m9T5k8rk009236@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: csci-551 final#1
Date: Tue, 28 Oct 2008 22:46:08 -0700
From: Bill Cheng <william@bourbon.usc.edu>

Someone wrote:

  > you had mentioned that the timeout for the check response is same as
  > that of status message, but in the specs it says it is the join
  > timeout which has to be used

You are absolutely right!  Sorry that I have forgotten
about it.
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>




  On Sun, Oct 26, 2008 at 1:38 PM, Bill Cheng <william@bourbon.usc.edu> wrote:
  > Someone wrote:
  >
  >  > How is the check request msg going to get initiated..? I suppose it is to be
  >  > handled via commandline but i couldn't find its format in the spec.
  >
  > Not via commandline.  In paragraph 6 of the Peer-to-Peer
  > section of the spec:
  >
  >    http://merlot.usc.edu/cs551-f08/projects/final.html#p2p
  >
  > it says:
  >
  >    When a node loses connection with one of its neighbors,
  >    it is possible that it may be disconnect from the SERVANT
  >    network. In order to make sure that it is still connected
  >    to the network, the node must intiatiate a connectivity
  >    check by flooding a check message.
  >
  > So, you must flood a CHECK when you lose *any* connection
  > with a neighbor (unless this node is shutting down of course).
  >
  >  > Also it is mentioned in the spec that 'The flooding of check messages stops
  >  > at a beacon node where the beacon node sends a check response message
  >  > towards the node from which it received the check message'. What should the
  >  > requesting node of check msg set the TTL to to ensure that it stops at a
  >  > beacon node and not anywhere before.
  >
  > You should use the TTL from the startup configuration file.
  >
  >  > The timeout we can use for check response msg is JoinTimeOut, right ?
  >
  > No.  You should use the same logic as for the status command:
  >
  >    http://merlot.usc.edu/cs551-f08/projects/final-faq.html#done-status
  > --
  > Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>