Return-Path: william@bourbon.usc.edu Delivery-Date: Sun Nov 16 20:38:33 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 mAH4cXoc029621 for ; Sun, 16 Nov 2008 20:38:33 -0800 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id mAH4YuN1017292 for ; Sun, 16 Nov 2008 20:34:56 -0800 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 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