Return-Path: william@bourbon.usc.edu Delivery-Date: Fri Oct 17 13:31:40 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 m9HKVeaw002026 for ; Fri, 17 Oct 2008 13:31:40 -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 m9HKeBG2007685 for ; Fri, 17 Oct 2008 13:40:11 -0700 Message-Id: <200810172040.m9HKeBG2007685@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: Regarding breaking the tie Date: Fri, 17 Oct 2008 13:40:11 -0700 From: Bill Cheng Someone wrote: > I am thinking of the possible cases where I would need to break the tie for > the connection between two nodes. > It is possible when 2 beacon nodes try to exchange HELLO messages. > > I cannot think of any case where a non-beacon node would be involved. > A non-beacon node is considered a part of the network only after JOIN and > HELLO. > Say a non-beacon node A does JOIN, and sends HELLO to a some appropriate > nodes. When a node B will receive the HELLO from A, it'll send a HELLO back > on the same socket. Two non-beacon nodes can end up to be in each other's init_neighbor_list file. They can start (or soft-restart) at about the same time! I think everyone should just implement tie breaking and not worry about when can your code avoid this situation. Always check for this and your code will always work right. -- Bill Cheng // bill.cheng@usc.edu