Return-Path: william@bourbon.usc.edu Delivery-Date: Wed Oct 29 09:40:24 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 m9TGeNR7020983 for ; Wed, 29 Oct 2008 09:40:24 -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 m9TGpi6L018219 for ; Wed, 29 Oct 2008 09:51:44 -0700 Message-Id: <200810291651.m9TGpi6L018219@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: non-beacon node notify and log dropped message Date: Wed, 29 Oct 2008 09:51:44 -0700 From: Bill Cheng Someone wrote: > 1. Should we write dropped message information to logfile? No. But if you want to log it, you can do it and just start the line with "//". > 2. When a non-beacon node is at join timeout and try to close > socket, does it need to send notify? No. You only send NOTIFY on a connection if you have sent HELLO before. > 3. In the spec, "Please note that neighbor is a bi-directional > relationship. Therefore, when node B gets a hello message from > node A, and node A is not currently node B's neighbor, node B > should send a hello message to node A." So should B add A to B's > neighbor list? Are you asking about the init_neighbor_list file? The init_neighbor_list is a write-once file. Once it's created, it's never modified. So, you must not modify the init_neighbor_list file. What's in the init_neighbor_list file are a node's *initial neighbors*. A node may get more neighbors when other nodes connect to it. In (3) above, B becomes A's neighbor in memory. B does not become one of A's "initial neighbors". -- Bill Cheng // bill.cheng@usc.edu