Return-Path: william@bourbon.usc.edu
Delivery-Date: Sat Oct 25 14:40:17 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 m9PLeHgC022543
	for <cs551@merlot.usc.edu>; Sat, 25 Oct 2008 14:40:17 -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 m9PLojl5003850
	for <cs551@merlot>; Sat, 25 Oct 2008 14:50:45 -0700
Message-Id: <200810252150.m9PLojl5003850@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: 551- node-id
Date: Sat, 25 Oct 2008 14:50:45 -0700
From: Bill Cheng <william@bourbon.usc.edu>

Someone wrote:

  > I agree that we have to log the KPAV message. I'll rephrase my original
  > question:
  > 
  > For a KPAV message, we cannot retrieve the node id (for <from> and <to>
  > )from the message that is received, because there is no body.
  > Since we know the details of the connection on which it was received, we can
  > lookup our database and find out the node id of the sender.
  > 
  > Just want to confirm that there is no way the receiver can get the node id
  > from the message header.

If your node has a connection with a neighbor, you need to
remember the node ID of who's on the other side!

If you don't have this implemented, it's quite easy to add
this.  You can have a lookup table that associate a socket
descriptor (or whatever you use to identify a connection)
with a node ID.  When you first receive a HELLO from a
neighbor, you update this lookup table.  When you disconnect,
you remove the corresponding entry from the lookup table.
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>





  On Sat, Oct 25, 2008 at 8:23 AM, Bill Cheng <william@bourbon.usc.edu> wrote:
  > Someone wrote:
  >
  >  > While logging the entries, the <from> and <to> are the node id's like
  >  > nunki.usc.edu_port#.
  >  > Messages like KPAV which have no body - specifically sender's hostname
  > and
  >  > port - we cannot extract the details from there.
  >  > So we look up the table where we stored the information about our
  >  > connections, right?
  >
  > For a KPAV message, although the <data> part of the log entry is empty,
  > you still need to log <from> and <to>.
  > --
  > Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>