Return-Path: william@bourbon.usc.edu Delivery-Date: Wed Oct 15 11:51:13 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 m9FIpDb3006191 for ; Wed, 15 Oct 2008 11:51:13 -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 m9FIxDuW005027 for ; Wed, 15 Oct 2008 11:59:13 -0700 Message-Id: <200810151859.m9FIxDuW005027@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: cs551 Ruminations on global variables Date: Wed, 15 Oct 2008 11:59:13 -0700 From: Bill Cheng Someone wrote: > Continuing from the message below: > So should Ctrl-C restarts (expires) all the timers? I'm not sure what you meant by "all the timers". Your node has a commandline interface where the user can enter a command and your node "execute this command". For part (1), the commands you need to handle are "status neighbors..." and "shutdown". For part (2), you need to handle other commands. Some of these commands can take a while to "execute". The meaning of is to "short-circuit" the execution of these commands, i.e., pretend that the time for waiting has elapsed. does not "short-circuit" anything else in your node; just the commandline interface. > If this is true, then the *ONLY* way of terminating the program is to type > in "shutdown" right? Entering the "shutdown" command would be the only "normal" way. I guess you can always send the uncatchable SIGKILL (or "kill -9") to your process! Obviously, that's bad. -- Bill Cheng // bill.cheng@usc.edu On Mon, Oct 13, 2008 at 7:08 PM, Bill Cheng wrote: > Someone wrote: > > > You mentioned during a lecture that there was a message default for a > status > > neighbors request, but I couldn't find that in the spec. If there is > one, > > what is it, if there isnt, how do you know when you are done receiving > data? > > You can assume that after MsgLifetime, all the nodes in the > middle of the network will not be forwarding response > messages for your request. So, you can use a timeout value > that's slightly longer than MsgLifetime. > > By the way, you also need to handle properly. If > the user press before your timer expires, you must > treat this as if the timer has expired and you should perform > your normal processing of the status response messages. > should never cause your program to terminate. > -- > Bill Cheng // bill.cheng@usc.edu