Return-Path: william@bourbon.usc.edu Delivery-Date: Thu Oct 9 07:07:50 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.3 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 m99E7oFb003470 for ; Thu, 9 Oct 2008 07:07:50 -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 m99EEKgL023067 for ; Thu, 9 Oct 2008 07:14:20 -0700 Message-Id: <200810091414.m99EEKgL023067@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: Two questions about final project Date: Thu, 09 Oct 2008 07:14:20 -0700 From: Bill Cheng Someone wrote: > I have two questions about final project: > > 1. If we have a timer thread to decrement the timeout of all objects > every second; suppose one object is created and the timeout is set to be > 10, just right after it's created, the timer thread "tick", the timeout > of the object is changed to 9 immediately. i.e. the first second is > imprecise (not full one second). Do we need to handle this situation? > > (I guess not. Since after every "tick" it will decrement the timeout of > every object, this also costs time; so actually every second is imprecise) The answer is "no" but not for the reason you mentioned! The reason is that accuracy is not required on these timeouts. For example, if MsgLifetime is 30 seconds, would it matter if you expire a message after 29 secdons? Would it matter if you expire a message after 31 secdons? How was the number 30 determined? Well, probably someone said that "most responses are received within 15 seconds". So we double that and get 30 seconds as MsgLieftime! These timeouts are there to catch unusual cases. So, it doesn't matter if you are 1 or 2 seconds off. This is also why if KeepAlive timeout is X, you should send at least every X/2 seconds. > 2. (Maybe it's obvious, I'd just like to make sure) When regular node > (say r1) starts up, it connects to ONLY one beacon node(say b1). After > it selects its neighbors(say b2, r2), it connect to b2, r2, and > DISCONNECT with b1, right? If this regular node has never been part of the SERVANT network, it needs to "discover" the network by performing a JOIN. If the Location of each node is random, then JOIN would create a network that's random looking. If the node always has to connect to a beacon node as its neighbor, the network topology won't look random. -- Bill Cheng // bill.cheng@usc.edu