Return-Path: william@bourbon.usc.edu Delivery-Date: Mon Oct 13 19:00:26 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 m9E20QqB009948 for ; Mon, 13 Oct 2008 19:00:26 -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 m9E2823e019942 for ; Mon, 13 Oct 2008 19:08:02 -0700 Message-Id: <200810140208.m9E2823e019942@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: cs551 Ruminations on global variables Date: Mon, 13 Oct 2008 19:08:02 -0700 From: Bill Cheng 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