Delivery-Date: Sun Nov 16 20:38:33 2008
Message-Id: <200811170434.mAH4YuN1017292@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: status msg
Date: Sun, 16 Nov 2008 20:34:56 -0800
From: Bill Cheng <william@bourbon.usc.edu>

Someone wrote:

  > a status request has a request type, but a status response doesn't
  > have one. so how do we distinguish between status responses of that
  > for "neighbors" and that for "files". Do we do it by setting a global
  > variable, like...
  > 
  > while sending status request :
  > if(status request)
  > {
  >     if(status "neighbors")   type=1
  > 
  >     if(status "files")   type = 2
  > }
  > 
  > and while receiving responses
  > if(status response)
  > {
  >     if(type=1)   then expect status neighbors
  >     if(type=2)   then expect status files
  > 
  > }

Yes.  Your user interface can only be doing one thing at a
time when it initiates something.  So, you can store a state
for the user interface (you used this variable called "type"
above).  If it's waiting for a "status files" response, it
cannot be waiting for a "status neighbors" response at the
same time.  You don't even need a lock!

  > in this case , if a node receives a status request for files but is
  > delayed in sending a reply because it cannot acquire some lock
  > and user presses ctrl c at the receiver side and sends a status
  > neighbor request immediately and now our node acquired that lock and
  > sent the status files response, the receiver will crash. shouldnt
  > status response also have a type field?

What I said above is about a node who has *initiated* a
"status files" or a "statue neighbors".  I don't see how
this can be related to a node *receiving* "status files"
or "status neighbors".  They seem to be completely unrelated.
I think you need to make sure that initiating a status
command is not related to processing another status message
(or I'm just missing some subtle points here).
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>