Return-Path: william@bourbon.usc.edu
Delivery-Date: Thu May 4 23:37:22 2006
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id k456bMNC001591;
Thu, 4 May 2006 23:37:22 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id k456bFvD009913;
Thu, 4 May 2006 23:37:15 -0700
Message-Id: <200605050637.k456bFvD009913@bourbon.usc.edu>
To: cs530@merlot.usc.edu, cs551@merlot.usc.edu, csac@merlot.usc.edu
Subject: Fwd: JPL Summer Job (US citizenship required)
Date: Thu, 04 May 2006 23:37:15 -0700
From: william@bourbon.usc.edu
Hi,
I got the following summer job announcement from JPL (in
Pasadena, CA). Please look through the requirements before
applying. Both jobs require US citizenship.
--
Bill Cheng // bill.cheng@usc.edu
-----
Begin forwarded message:
> From: "Scott Darden"
> Date: May 4, 2006 3:15:57 PM PDT
> To: ortega@sipi.usc.edu
> Cc: "Clay Okino" ,
> "Winston Kwong"
> Subject: JPL Summer Job
>
> JPL is looking for summer interns for the following job descriptions.
>
> Job Description #1: Video over space links
>
> There is interest in investigating off the shelf video techniques for
> use in a space environment. In particular, of video teleconference
> applications.
>
> Requirements: U.S. Citizenship, graduate student with a background in
> video codex, VTC protocols (such as H.323), C or C++, Visual
> Studio. Knowledge of computer and or communication networks is
> desired but not required.
>
> Job Description #2: VOIP over space links
>
> There is interest in investigating off the shelf voice over IP
> techniques for use in a space environment.
>
> Requirements: U.S. Citizenship, graduate student with a background in
> audio codex (such as CELP and MELP), C or C++, Visual Studio.
> Knowledge of session initiation protocol (SIP), real time protocol
> (RTP), real time control protocol (RTCP).
>
> Please send resumes to Scott Darden at darden@aria.jpl.nasa.gov.
>
> Scott
Return-Path: william@bourbon.usc.edu
Delivery-Date: Wed Dec 21 07:59:31 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jBLFxUa2017349
for ; Wed, 21 Dec 2005 07:59:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jBLFvOOx009589
for ; Wed, 21 Dec 2005 07:57:24 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jBLFvOYh009588
for cs551@merlot; Wed, 21 Dec 2005 07:57:24 -0800
Date: Wed, 21 Dec 2005 07:57:24 -0800
From: william@bourbon.usc.edu
Message-Id: <200512211557.jBLFvOYh009588@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: deleting project spec...
Hi,
I'm deleting the project specs this Friday. If you think you
might need it when you go for job interviews in the future,
you should save a copy of it. (Once I've deleted the spec,
I will not put it back up or find it in the database and
send it to you.)
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Mon Dec 12 11:39:29 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jBCJdTOc023480
for ; Mon, 12 Dec 2005 11:39:29 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jBCJbrDV019663
for ; Mon, 12 Dec 2005 11:37:53 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jBCJbrra019662
for cs551@merlot; Mon, 12 Dec 2005 11:37:53 -0800
Date: Mon, 12 Dec 2005 11:37:53 -0800
From: william@bourbon.usc.edu
Message-Id: <200512121937.jBCJbrra019662@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: final letter grade...
Hi,
I just want to mention that there are *huge* gaps between
letter grades. So, if you are thinking about complaining
about the project grades here and there just to get a few
points, chances are, they will have no impact of your final
letter grade.
Please also remember that we must grade what you have
submitted. You will not get *any* credit for work done after
the submission deadline. (When it comes to grading, fairness
is my primary concern.)
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Dec 6 11:46:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB6JkbUM032257
for ; Tue, 6 Dec 2005 11:46:37 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB6JjLCR029274
for ; Tue, 6 Dec 2005 11:45:21 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB6JjLbN029273
for cs551@merlot.usc.edu; Tue, 6 Dec 2005 11:45:21 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB6JjLin029270
for ; Tue, 6 Dec 2005 11:45:21 -0800
Message-Id: <200512061945.jB6JjLin029270@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: TCP throughput modeling
Date: Tue, 06 Dec 2005 11:45:21 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Are we expected to know the TCP throughput modeling equations for Bandwidth
> B(p), from the TCP throughput modeling paper?
You do not need to know the derivation, but you should
be familiar with the solution form.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Dec 5 13:33:08 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LX8DN020167
for ; Mon, 5 Dec 2005 13:33:08 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LVtjl024150
for ; Mon, 5 Dec 2005 13:31:55 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB5LVti8024149
for cs551@merlot.usc.edu; Mon, 5 Dec 2005 13:31:55 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LVtBc024146
for ; Mon, 5 Dec 2005 13:31:55 -0800
Message-Id: <200512052131.jB5LVtBc024146@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: RED (cont)
Date: Mon, 05 Dec 2005 13:31:55 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I just wanted to add, that I do understand how early drop is done and what
> it does, but I didn't understand how this early drop helps accommodate
> burst.
Early drop keeps the queue size relatively low, so when a
burst of packets come in, there is room in the queue to
handle it (instead of dropping some of it).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Dec 5 13:31:03 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LV2Xr020098
for ; Mon, 5 Dec 2005 13:31:02 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LTo2b024117
for ; Mon, 5 Dec 2005 13:29:50 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB5LToDn024116
for cs551@merlot.usc.edu; Mon, 5 Dec 2005 13:29:50 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LTokD024113
for ; Mon, 5 Dec 2005 13:29:50 -0800
Message-Id: <200512052129.jB5LTokD024113@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: RED
Date: Mon, 05 Dec 2005 13:29:50 -0800
From: william@bourbon.usc.edu
Someone wrote:
> In RED active queue management, there is a statement saying that the queue
> size should reflect the burst size we want to absorb and not steady-state
> queuing. I did not understand what it means?
That justifies early drop. Basically, it says that it's okay
to drop packets early (before the queue becomes full) because
large steady-state queue should not occur.
> Actually I have not understood
> the concept of how RED accommodates congestion, maybe that is where the
> doubt comes from.
RED accomodates congestion by random drop and early drop (while
a drop-tail queue accomodated congestion by drop-tail).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Dec 5 13:24:10 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LOA5P019906
for ; Mon, 5 Dec 2005 13:24:10 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LMwsY024040
for ; Mon, 5 Dec 2005 13:22:58 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB5LMwdM024039
for cs551@merlot.usc.edu; Mon, 5 Dec 2005 13:22:58 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5LMwjD024036
for ; Mon, 5 Dec 2005 13:22:58 -0800
Message-Id: <200512052122.jB5LMwjD024036@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: lect 23 slide 17
Date: Mon, 05 Dec 2005 13:22:58 -0800
From: william@bourbon.usc.edu
Someone wrote:
> But if it sends the reply with a new address.. I think this is really a
> basic doubt.
>
> If I have a TCP connection between IP add x (port a) and IP add y (port b).
> i.e x:a <---> y:b
>
> Now if the reply comes with a different IP address z (instead of y), then
> will it still go to the process waiting on x:a ?
The packet will go to the right process. Although the response
will look like an unsolicited response.
The would also depend on the application. If the application
on CH does not check the source address of the response, then
it would work. If it does, then it may throw away packets
not coming from where it's expecting.
I think the mobile host can also reply with its original IP
address! But if the foreign network has source filtering
turned on, then then pack will not get out of the foreign
network. But then if the foreign network is mobile IP-aware,
it would probably allow it.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Monday, December 05, 2005 2:25 PM
To: cs551@bourbon.usc.edu
Subject: Re: lect 23 slide 17
Someone wrote:
> In 17th slide of lect 23, when the mobile host replies t the "CH", it
does
> this directly? Then what will be the source IP address in this reply
packet.
> Will it be the new IP address that the mobile host has got in the
foreign
> network or will it be the IP address that it was using in home network?
It will be the new IP address.
So, this may cause problems because the response would look
like an unsolicited response. If the CH has some security
software installed that detects "strange" connections. This
type of reply may cause the security software to block the
reply!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Dec 5 09:25:42 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HPgWK012774
for ; Mon, 5 Dec 2005 09:25:42 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HOU8l022625
for ; Mon, 5 Dec 2005 09:24:30 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB5HOUbu022624
for cs551@merlot.usc.edu; Mon, 5 Dec 2005 09:24:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HOUQi022621
for ; Mon, 5 Dec 2005 09:24:30 -0800
Message-Id: <200512051724.jB5HOUQi022621@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: lect 23 slide 17
Date: Mon, 05 Dec 2005 09:24:30 -0800
From: william@bourbon.usc.edu
Someone wrote:
> In 17th slide of lect 23, when the mobile host replies t the "CH", it does
> this directly? Then what will be the source IP address in this reply packet.
> Will it be the new IP address that the mobile host has got in the foreign
> network or will it be the IP address that it was using in home network?
It will be the new IP address.
So, this may cause problems because the response would look
like an unsolicited response. If the CH has some security
software installed that detects "strange" connections. This
type of reply may cause the security software to block the
reply!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Dec 5 09:21:45 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HLjWm012647
for ; Mon, 5 Dec 2005 09:21:45 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HKYW4022604
for ; Mon, 5 Dec 2005 09:20:34 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jB5HKY3x022603
for cs551@merlot.usc.edu; Mon, 5 Dec 2005 09:20:34 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jB5HKYhf022600
for ; Mon, 5 Dec 2005 09:20:34 -0800
Message-Id: <200512051720.jB5HKYhf022600@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: lect 22 slide 7
Date: Mon, 05 Dec 2005 09:20:34 -0800
From: william@bourbon.usc.edu
[ Sorry for the late reply. I was sick most of Sunday. ]
Someone wrote:
> I did not understand what you were trying to say for the 7th
> slide of lec 22.
>
> It is about loss patterns.
>
> Is the loss pattern for data exponentially distributed or does
> it have heavy tail distribution.
Loss pattern for data is exponentially distributed while loss
pattern for ACKs was not.
> What happens on bursts. Wht is the distribution of ack losses.
When you have a burst of losses, it's referred to as an outage
in the paper. Part of the ACK outage duration is consistent
with the Pareto distribution.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 30 12:04:49 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAUK4nYV002772
for ; Wed, 30 Nov 2005 12:04:49 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAUK3tdw006704
for ; Wed, 30 Nov 2005 12:03:55 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAUK3tl1006703
for cs551@merlot.usc.edu; Wed, 30 Nov 2005 12:03:55 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAUK3tlx006700
for ; Wed, 30 Nov 2005 12:03:55 -0800
Message-Id: <200511302003.jAUK3tlx006700@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Enhanced-clustered cache replacement scheme
Date: Wed, 30 Nov 2005 12:03:55 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I have a doubt in Enhanced-clustered cache replacement scheme
> [slide 17 of lecture 18]
>
> We dont want to strictly throw off the farthest one.
> In slide 17 of lecture 18, the algorithm presented is doing the reverse.
> If v is farther from u, we are evicting it with probablity = 1.
> I did not understand why is this so.
It's not that "we don't want to throw away the farthest one".
It's "we don't want to *always* throw away the farthest one".
To achieve Small World Model, we must have short-distance
clustering and long-distance shortcuts.
So, the first rule on slide 17 of lecture 18 is to achieve
short-distance clustering. The 2nd (the one you asked about)
is to achieve long-distance shortcuts. (And it's not with
probability 1, but some p, which can be a function of the
distance between u and the seed).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 23 14:59:16 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jANMxG20006655
for ; Wed, 23 Nov 2005 14:59:16 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jANMwk0i016153
for ; Wed, 23 Nov 2005 14:58:46 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jANMwkvw016152
for cs551@merlot.usc.edu; Wed, 23 Nov 2005 14:58:46 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jANMwkYd016149
for ; Wed, 23 Nov 2005 14:58:46 -0800
Message-Id: <200511232258.jANMwkYd016149@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: difference between Cached and Permenant files
Date: Wed, 23 Nov 2005 14:58:46 -0800
From: william@bourbon.usc.edu
Someone wrote:
> The spec says this abt StoreProb...
>
> StoreProb - When a node receives a store request from a neighbor,
> it flips a coin (with this probability of getting a positive
> outcome) to decide if it should cache a copy of it. If the result
> is positive, a copy of the file is stored. The node where this
> store request was originated ignores this value. The default
> value is 0.1.
>
> here the underline part "cache a copy" means should the file be a
> part of permament files or the cache ones?
Cache.
> because in the next
> statement it is sayed, a copy of the file is stored.
You can "store" in either the permanent space or the cached
space.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 22 23:21:17 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAN7LHTa016333
for ; Tue, 22 Nov 2005 23:21:17 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN7Ko52012271
for ; Tue, 22 Nov 2005 23:20:50 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAN7KoYj012270
for cs551@merlot.usc.edu; Tue, 22 Nov 2005 23:20:50 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN7Kojx012267
for ; Tue, 22 Nov 2005 23:20:50 -0800
Message-Id: <200511230720.jAN7Kojx012267@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: nounce
Date: Tue, 22 Nov 2005 23:20:50 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Just wanted to confirm..
> In Section B) Mixed nodes, part 1a),
> we are performing 3 get's. So, before making a copy of the
> get file in the permanent memory of
> the node that originated get msg, should i check if that file
> is already there in the node's permanent memory?
>
> And if present, should i still copy this again?
Again, if you do not give me a line number in the grading
guidelines file, I cannot answer your specific question. I'll
answer your question in general.
If you type, for example, "get 2" and the corresponding file
is already in the permanent storage of that node, then you
don't have to send out a GET request. But, you still need
to copy the corresponding file into the current working
directory.
--
Bill Cheng // bill.cheng@usc.edu
----- Original Message -----
From: william@bourbon.usc.edu
Date: Tuesday, November 22, 2005 8:54 pm
Subject: Re: nounce
To: cs551@bourbon.usc.edu
> Someone wrote:
>
> > When we recieve the store msg from neighbour node, should we copy
> > the meta and data file in the store msg as it is?
>
> Yes.
>
> > If yes, i have
> > a doubt in the grading guidelines Section "(B) Mix of nodes"
> >
> > In 1a) CacheProb=1, StoreProb=1, NeighborStoreProb=1
> > First we did a "store" at node 02.
> > [store blondie1.mp3 2 title="Heart of Glass"]
> >
> > blondie1.mp3 is stored at other nodes because, they recieved store
> > from node 02. So, All the files will have same sha, nounce and
> > filenames. Is this correct?
>
> Exactly.
>
> > then in the node 08: search filename=blondie1.mp3
> > should get 5 responses,
> > look for the nonce that matches the
> nonce at
> > node *02, let's call this x, then
> type: get [x]
> >
> > Why will the nonce values be different?
>
> They should all have the same nonce value *for this particular
> example*. In general, that need not be true. The grading
> guidelines have gone through several revisions. In a previous
> version, there were other blondie1.mp3 stored. Sorry about
> the confusion.
> --
> Bill Cheng // bill.cheng@usc.edu
>
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 22 20:53:57 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4rv8Z012895
for ; Tue, 22 Nov 2005 20:53:57 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4rUPC011611
for ; Tue, 22 Nov 2005 20:53:30 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAN4rUNW011610
for cs551@merlot.usc.edu; Tue, 22 Nov 2005 20:53:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4rU9g011607
for ; Tue, 22 Nov 2005 20:53:30 -0800
Message-Id: <200511230453.jAN4rU9g011607@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: nounce
Date: Tue, 22 Nov 2005 20:53:30 -0800
From: william@bourbon.usc.edu
Someone wrote:
> When we recieve the store msg from neighbour node, should we copy
> the meta and data file in the store msg as it is?
Yes.
> If yes, i have
> a doubt in the grading guidelines Section "(B) Mix of nodes"
>
> In 1a) CacheProb=1, StoreProb=1, NeighborStoreProb=1
> First we did a "store" at node 02.
> [store blondie1.mp3 2 title="Heart of Glass"]
>
> blondie1.mp3 is stored at other nodes because, they recieved store
> from node 02. So, All the files will have same sha, nounce and
> filenames. Is this correct?
Exactly.
> then in the node 08: search filename=blondie1.mp3
> should get 5 responses,
> look for the nonce that matches the nonce at
> node *02, let's call this x, then type: get [x]
>
> Why will the nonce values be different?
They should all have the same nonce value *for this particular
example*. In general, that need not be true. The grading
guidelines have gone through several revisions. In a previous
version, there were other blondie1.mp3 stored. Sorry about
the confusion.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 22 20:48:59 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4mxSV012788
for ; Tue, 22 Nov 2005 20:48:59 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4mWTA011530
for ; Tue, 22 Nov 2005 20:48:32 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAN4mWhF011529
for cs551@merlot.usc.edu; Tue, 22 Nov 2005 20:48:32 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAN4mV4g011526
for ; Tue, 22 Nov 2005 20:48:31 -0800
Message-Id: <200511230448.jAN4mV4g011526@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: storeprob
Date: Tue, 22 Nov 2005 20:48:31 -0800
From: william@bourbon.usc.edu
Someone wrote:
> When a node gets a store message, i.e when a node gets a file to
> store - shud it store this file or cache it?
If this node originated a GET, then it should store it in permanent
storage. All other nodes should store it in cache, if it decides
to store it.
> StoreProb - When a node receives a store request from a neighbor,
> it flips a coin (with this probability of getting a positive
> outcome) to decide if it should cache a copy of it. If the result
> is positive, a copy of the file is stored. The node where this
> store request was originated ignores this value. The default
> value is 0.1.
>
> The specs says the above, so I guess we need to cache it.
>
> So I just want to confirm that the node stores a file only if
> gets a reply to its own "get" message or a file is locally
> stored. Is that right?
If this node originated the GET request, then it must store
it in permanent storage. All other nodes should store it in
cache, if it decides to store it. I'm not sure what you meant
by "locally stored".
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 22 08:13:12 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAMGDCHq028011
for ; Tue, 22 Nov 2005 08:13:12 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAMGClVe008431
for ; Tue, 22 Nov 2005 08:12:47 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAMGClBD008430
for cs551@merlot.usc.edu; Tue, 22 Nov 2005 08:12:47 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAMGCl5R008427
for ; Tue, 22 Nov 2005 08:12:47 -0800
Message-Id: <200511221612.jAMGCl5R008427@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Format of "get" result
Date: Tue, 22 Nov 2005 08:12:47 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I got a bit confused.
> When the user says "get 1 [], if the extfile
> exists, the user shuld be asked for replacement or not? If
> the user says no, should the 5.data,5.cert and 5.certify be
> created?
I think they should still be created. You can create these
files first and then prompt the user and copy 5.data to the
current working directory.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Nov 21 23:01:27 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAM71R9m014710
for ; Mon, 21 Nov 2005 23:01:27 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAM713PN006572
for ; Mon, 21 Nov 2005 23:01:03 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAM713QL006571
for cs551@merlot.usc.edu; Mon, 21 Nov 2005 23:01:03 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAM7132L006568
for ; Mon, 21 Nov 2005 23:01:03 -0800
Message-Id: <200511220701.jAM7132L006568@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Format of "get" result
Date: Mon, 21 Nov 2005 23:01:03 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Should the output of get be written to one file or should be it divided into
> .meta, .cert and .data files ? Also, if written to one file, is there any
> specific format or can I just append meta + cert + data in that order ?
I'm not sure what you meant by "output of get".
There are 2 things you should do. If you look at line 876 of
the grading guidelines, it says:
get 1
"blondie1.mp3" should be created in the
current directory
So, the *output* of "get 1" here is to create a file "blondie1.mp3"
in the currently working directory.
*Also*, according to item (8) in the Summary of Basic Message Types
section of the spec:
If the user at node X attempts to retrieve file F and file F was
successfully retrived, node X must serve file F (i.e., respond
properly to future search messages). File F should be stored in
the permanent area and not stored in its cache. Intermediate
nodes, i.e., nodes on the return path of the get response message
(other than the originating and the final nodes) cache file F
probabilistically.
If the next availabe file number is 5, you should also create
"5.data", "5.meta", "5.cert", etc. in the files subdirectory
of the node's HomeDir *so that you can serve this file*. Of
couse, you need to update all your indices and index files so
that this node can repond to search and get and delete messages
properly.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Sat Nov 19 14:39:48 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJMdmE6007589
for ; Sat, 19 Nov 2005 14:39:48 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJMZWVd019136
for ; Sat, 19 Nov 2005 14:35:32 -0800
Message-Id: <200511192235.jAJMZWVd019136@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: final project part (2) extension!
Date: Sat, 19 Nov 2005 14:35:32 -0800
From: william@bourbon.usc.edu
Hi,
I forgot to mention, the machine I read e-mails on will also
be shutdown. Since it cannot be turned on remotely, I will
only be able to boot it on Monday around 10am. So, I won't
be able to reply to e-mail messages between midnight tonight
and 10am on Monday. Sorry about the inconvenience.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
Date: Sat, 19 Nov 2005 14:23:46 -0800
From: william@bourbon.usc.edu
To: cs551@merlot.usc.edu
Subject: final project part (2) extension!
I was going to see if it was my mistake regarding the
bit-vector. And if it were, I will extend the deadline by
one day. Then I got the message below regarding an emergency
power outage for tomorrow (Sunday 11/20) from 2am to 10pm.
I'm not sure if nunki and aludra will be down during this
time. But looks like the USC network will be down. So, this
is what I'm going to do.
The deadline for final project part (2) will be extended by
two days to Wed 11/23/2005 at 11:45pm. There will be no
additional extension if the power outage will last till
Monday. (If it lasts till Tuesday, we will most likely have
another extension).
Most likely, USC network will be down. This means that you
will not be able to access the web server and I will not be
able to reach my e-mail. It would probably be a good idea if
you make a copy of the project spec, especially if you have a
home machine to continue to work on your project.
--
Bill Cheng // bill.cheng@usc.edu
-----Forwarded Message-----
Date: Sat, 19 Nov 2005 12:53:35 -0800
From: CS Sys Admin
To: CS System Administrator
Subject: Alert: Power/Network Outage on Sunday 20 NOV
Hi All,
Please take note of the below message from ISD.
There will be Power and/or Network outage on Sunday, November 20th, 2:00
a.m. until 10:00 p.m on most buildings in University Park Campus. The
emergency Power shutdown is because of the electric work on the Biegler
vault.
SAL, PHE, HNB, ACB, OHE are included on the list for confirmed power and
network outage.
RTH may not have power outage but network outage is confirmed because the
rest of the network switches will be down. Detailed list is given in below
emails.
Please shutdown computers/equipment (or take appropriate precautionary
measures).
http://www.usc.edu/isd/it/alerts/upc_power_outage_november_20th.html
Regards,
Vishal Thakkar
IT and Web Consultant
Computer Science Department, USC
---------- Forwarded message ----------
Date: Nov 19, 2005 10:47 AM
Subject: Fwd: Power Outage Sunday, please forward
ISD has learned from FMS this morning that this outage will be extended
until 10:00 p.m. Sunday night.
---------- Forwarded message ----------
Date: Nov 18, 2005 11:25 PM
Subject: Power Outage Sunday, please forward
ISD has learned of an emergency power outage scheduled for the University
Park campus this weekend. Facilities Management Services has informed us
that the outage will take place on Sunday, November 20th, 2:00 a.m. until
6:00 p.m., and will affect all buildings fed by the Biegler Vault (see
complete list below). Buildings fed by this vault will be without power an
d
network service for the duration of the outage.
In addition, because Bridge Hall and Powell Hall house network switches tha
t
support adjacent buildings, network service likely will be unavailable in
those adjacent buildings as well, even though the power there will remain
on.
Should you encounter any difficulty re-establishing network connectivity
once the power has been restored, please call ISDÂ’s Customer Support Center
at x05555.
We apologize in advance to members of the University community for any
inconvenience that may result from this power outage.
Buildings Served by Biegler Vault:
Administration
Ahmanson - East/West
Alan Hancock
Annex Building II
Biegler Hall of Eng.
Birnkrant (N. Complex)
Bookstore
Bridge Hall
Center for Electron Microscopy
Childs Way I and II
College University (N. Complex)
Commons
Davidson Conf.
Dedeaux Field
Denny Research
Dental School
Doheny Library
Drama Center
Electrical Engineering Bldg.
EVK (N. Complex)
Faculty Center
Financial Services
Gerontology
Grace Ford Sal.
Harris Hall of Architecture
Harris Hall of Residence (N. Complex)
Hedco Neurosciences
Hedco/PCE
Henry Salvatori
Hoffman Hall/GSBA
Human Relations Center
Law Center
Lewis Hall 120/208
Loker Hydrocarbon '95 Add..
Loker Hydrocarbon Original
Mudd Hall of Philosophy
Norris Cinema Theater
North Complex
Olin Hall of Engineering
Organic Chemistry Wing
Parking Structure "A"
Parkside Apartments
Powell Hall
Rapp Research/APL
Scene Dock
School of Accounting
Science Hall (North and South)
Seaver Science Building
Seaver Science Library
Seeley G. Mudd
Stabler Hall
Stauffer Hall of Science
Stauffer Lecture Hall
Stonier Hall
Student Union
Student Admin. Services
Telephone Vault/Olin Hall
Tennis Stadium
Topping Student Center
Town and Gown
Vivian Hall of Engineering
Watt Hall
Webb Tower
YWCA
Return-Path: william@bourbon.usc.edu
Delivery-Date: Sat Nov 19 14:28:02 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJMS21Z007338
for ; Sat, 19 Nov 2005 14:28:02 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJMNksu019060
for ; Sat, 19 Nov 2005 14:23:46 -0800
Message-Id: <200511192223.jAJMNksu019060@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: final project part (2) extension!
Date: Sat, 19 Nov 2005 14:23:46 -0800
From: william@bourbon.usc.edu
I was going to see if it was my mistake regarding the
bit-vector. And if it were, I will extend the deadline by
one day. Then I got the message below regarding an emergency
power outage for tomorrow (Sunday 11/20) from 2am to 10pm.
I'm not sure if nunki and aludra will be down during this
time. But looks like the USC network will be down. So, this
is what I'm going to do.
The deadline for final project part (2) will be extended by
two days to Wed 11/23/2005 at 11:45pm. There will be no
additional extension if the power outage will last till
Monday. (If it lasts till Tuesday, we will most likely have
another extension).
Most likely, USC network will be down. This means that you
will not be able to access the web server and I will not be
able to reach my e-mail. It would probably be a good idea if
you make a copy of the project spec, especially if you have a
home machine to continue to work on your project.
--
Bill Cheng // bill.cheng@usc.edu
-----Forwarded Message-----
Date: Sat, 19 Nov 2005 12:53:35 -0800
From: CS Sys Admin
To: CS System Administrator
Subject: Alert: Power/Network Outage on Sunday 20 NOV
Hi All,
Please take note of the below message from ISD.
There will be Power and/or Network outage on Sunday, November 20th, 2:00
a.m. until 10:00 p.m on most buildings in University Park Campus. The
emergency Power shutdown is because of the electric work on the Biegler
vault.
SAL, PHE, HNB, ACB, OHE are included on the list for confirmed power and
network outage.
RTH may not have power outage but network outage is confirmed because the
rest of the network switches will be down. Detailed list is given in below
emails.
Please shutdown computers/equipment (or take appropriate precautionary
measures).
http://www.usc.edu/isd/it/alerts/upc_power_outage_november_20th.html
Regards,
Vishal Thakkar
IT and Web Consultant
Computer Science Department, USC
---------- Forwarded message ----------
Date: Nov 19, 2005 10:47 AM
Subject: Fwd: Power Outage Sunday, please forward
ISD has learned from FMS this morning that this outage will be extended
until 10:00 p.m. Sunday night.
---------- Forwarded message ----------
Date: Nov 18, 2005 11:25 PM
Subject: Power Outage Sunday, please forward
ISD has learned of an emergency power outage scheduled for the University
Park campus this weekend. Facilities Management Services has informed us
that the outage will take place on Sunday, November 20th, 2:00 a.m. until
6:00 p.m., and will affect all buildings fed by the Biegler Vault (see
complete list below). Buildings fed by this vault will be without power and
network service for the duration of the outage.
In addition, because Bridge Hall and Powell Hall house network switches that
support adjacent buildings, network service likely will be unavailable in
those adjacent buildings as well, even though the power there will remain
on.
Should you encounter any difficulty re-establishing network connectivity
once the power has been restored, please call ISDÂ’s Customer Support Center
at x05555.
We apologize in advance to members of the University community for any
inconvenience that may result from this power outage.
Buildings Served by Biegler Vault:
Administration
Ahmanson - East/West
Alan Hancock
Annex Building II
Biegler Hall of Eng.
Birnkrant (N. Complex)
Bookstore
Bridge Hall
Center for Electron Microscopy
Childs Way I and II
College University (N. Complex)
Commons
Davidson Conf.
Dedeaux Field
Denny Research
Dental School
Doheny Library
Drama Center
Electrical Engineering Bldg.
EVK (N. Complex)
Faculty Center
Financial Services
Gerontology
Grace Ford Sal.
Harris Hall of Architecture
Harris Hall of Residence (N. Complex)
Hedco Neurosciences
Hedco/PCE
Henry Salvatori
Hoffman Hall/GSBA
Human Relations Center
Law Center
Lewis Hall 120/208
Loker Hydrocarbon '95 Add..
Loker Hydrocarbon Original
Mudd Hall of Philosophy
Norris Cinema Theater
North Complex
Olin Hall of Engineering
Organic Chemistry Wing
Parking Structure "A"
Parkside Apartments
Powell Hall
Rapp Research/APL
Scene Dock
School of Accounting
Science Hall (North and South)
Seaver Science Building
Seaver Science Library
Seeley G. Mudd
Stabler Hall
Stauffer Hall of Science
Stauffer Lecture Hall
Stonier Hall
Student Union
Student Admin. Services
Telephone Vault/Olin Hall
Tennis Stadium
Topping Student Center
Town and Gown
Vivian Hall of Engineering
Watt Hall
Webb Tower
YWCA
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Nov 19 14:10:57 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJMAvjO006886
for ; Sat, 19 Nov 2005 14:10:57 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJM6f5b019007
for ; Sat, 19 Nov 2005 14:06:41 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAJM6f4i019006
for cs551@merlot.usc.edu; Sat, 19 Nov 2005 14:06:41 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJM6fHT019003
for ; Sat, 19 Nov 2005 14:06:41 -0800
Message-Id: <200511192206.jAJM6fHT019003@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: grading guidline
Date: Sat, 19 Nov 2005 14:06:41 -0800
From: william@bourbon.usc.edu
Someone wrote:
> In the following test case -
> (B) Mix of nodes : +25 points
> ----------------------------------------------------------------------------
>
> (1) Network with 2 beacon nodes and 4 non-beacon nodes : +25 points
> autoshutdown=600 sec, keepalive timeout=10 sec, msglifetime=15
> sec, CacheSize=5, PermSize=25
>
> (a) CacheProb=1, StoreProb=1, NeighborStoreProb=1
> (+15 points)
> topology: /------ n08
> | |
> v v
> n00* <--> n01*
> ^^ ^
> || |
> |\------ n04 <----\
> | ^ |
> | | |
> \------- n03 <-- n02
>
> in one window, do:
> ./sv_node n00.ini
> (wait till all other nodes get started)
>
> in 2nd window, do:
> ./sv_node n01.ini
> (wait till all other nodes get started)
>
> in 3rd window, do:
> ./sv_node n04.ini
> (wait till all other nodes get started)
>
> in 4th window, do:
> ./sv_node n03.ini
> (wait till all other nodes get started)
>
> in 5th window, do:
> ./sv_node n02.ini
> (wait till all other nodes get started)
>
> in 6th window, do:
> ./sv_node n08.ini
> (wait till all other nodes get started)
>
> *wait* for all nodes to autoshutdown
>
> (+2 points)
> in 1st window (node *00), type:
> "status neighbors 5 00.out", look at "00.out",
> and make sure the network looks corrct.
>
> *restart the net in the same order in windows 1 through 6*
>
> in 5th window (node *02), type:
> store blondie1.mp3 2 title="Heart of Glass"
>
> in 5th window (node *02), type:
> "status files 5 04.out", look at "04.out",
> (+1 points)
> every node except node *08 should have this
> file, node *08 should have no files
>
> Why have you said that node 08 shud have no files when the .ini file of all
> the nodes is identical. They all have storeprob and cacheprob = 1
>
> And I am getting the files in all nodes (even node 08).
The "store" command above is done at node *02 and a TTL of 2
was used. Given the network topology above, the "store"
message should not reached node *08.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Nov 19 14:07:00 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJM70mB006779
for ; Sat, 19 Nov 2005 14:07:00 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJM2iKY018966
for ; Sat, 19 Nov 2005 14:02:44 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAJM2iv1018965
for cs551@merlot.usc.edu; Sat, 19 Nov 2005 14:02:44 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJM2iia018962
for ; Sat, 19 Nov 2005 14:02:44 -0800
Message-Id: <200511192202.jAJM2iia018962@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: grading guidlines
Date: Sat, 19 Nov 2005 14:02:44 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I am also getting the same bit-vector as mentioned in the email below. Here
> is what I get:
>
> Keywords=categories audio mp3 artist blondie
> Bit-vector=
> 010000000000000000020000000000000000000000000000
> 000000000000000000200000000000000000000000000000
> 000000000004800000000000000000000000000000000000
> 000000000000000000000008800000000000000040008000
> 000000000000000000000010000000000000000000000000
> 0000000000000000
>
> In the grading guidelines the list of keywords in the meta file reads:
> Keywords=categories audio mp3 artist Blondie
>
> The 'B' in blondie should be lowercase. Perhaps thats the reason for a
> different bit-vector.
I checked and that wasn't the reason.
--
Bill Cheng // bill.cheng@usc.edu
----- Original Message -----
From:
To:
Sent: Saturday, November 19, 2005 9:52 AM
Subject: Re: grading guidlines
> Someone wrote:
>
> > I'm another one that got different bitvector on
> > Keywords=categories audio mp3 artist Blondie.
> > I don't know why this particular set of keywords I got the answer
> > different from grading guideline, although my program generated right
> > answers on all other examples.
> >
> > This is my bitvector that I got for 'Keywords=categories audio mp3
> > artist Blondie'.
> > 010000000000000000020000000000000000000000000000
> > 000000000000000000200000000000000000000000000000
> > 000000000004800000000000000000000000000000000000
> > 000000000000000000000008800000000000000040008000
> > 000000000000000000000010000000000000000000000000
> > 0000000000000000
> >
> > Could Professor check the bitvector of these keywords in grading
> > guideline again?
>
> Hmm... I checked again and it seemed that what's in the
> grading guideline was wrong! I have *not* modified the
> grading guidelines yet. If anyone get the same value as the
> previous grading guidelines, please let me know ASAP!
>
> I won't get a chance to check e-mail until later this
> afternoon. If by 6pm I do not get an e-mail saying that the
> previous grading guidelines was correct, then I will make the
> change. Thanks!
> --
> Bill Cheng // bill.cheng@usc.edu
>
>
>
>
> -----Original Message-----
> From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
> Sent: Thursday, November 17, 2005 12:15 PM
> To: cs551@bourbon.usc.edu
> Subject: Re: grading guidlines
>
> Someone wrote:
>
> > For the very first test case where we are storing the following -
> >
> > store blondie1.mp3 1 categories="audio mp3" artist="Blondie"
> >
> > my bitvector is turing on wrong bits for the keyword artist, though
> it is
> > computing the sha1 and md5 on the word "artist". Could there be a
> reason?
>
> The spec says that you must convert a keyword to all lowercase
> before computing the bit-vector. Imagine that if you don't
> and others do, then searching will be a problem.
> --
> Bill Cheng // bill.cheng@usc.edu
>
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Nov 19 09:56:28 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJHuSB6001070
for ; Sat, 19 Nov 2005 09:56:28 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJHqDY0018197
for ; Sat, 19 Nov 2005 09:52:13 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAJHqDZn018196
for cs551@merlot.usc.edu; Sat, 19 Nov 2005 09:52:13 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJHqDGF018193
for ; Sat, 19 Nov 2005 09:52:13 -0800
Message-Id: <200511191752.jAJHqDGF018193@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: grading guidlines
Date: Sat, 19 Nov 2005 09:52:13 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I'm another one that got different bitvector on
> Keywords=categories audio mp3 artist Blondie.
> I don't know why this particular set of keywords I got the answer
> different from grading guideline, although my program generated right
> answers on all other examples.
>
> This is my bitvector that I got for 'Keywords=categories audio mp3
> artist Blondie'.
> 010000000000000000020000000000000000000000000000
> 000000000000000000200000000000000000000000000000
> 000000000004800000000000000000000000000000000000
> 000000000000000000000008800000000000000040008000
> 000000000000000000000010000000000000000000000000
> 0000000000000000
>
> Could Professor check the bitvector of these keywords in grading
> guideline again?
Hmm... I checked again and it seemed that what's in the
grading guideline was wrong! I have *not* modified the
grading guidelines yet. If anyone get the same value as the
previous grading guidelines, please let me know ASAP!
I won't get a chance to check e-mail until later this
afternoon. If by 6pm I do not get an e-mail saying that the
previous grading guidelines was correct, then I will make the
change. Thanks!
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Thursday, November 17, 2005 12:15 PM
To: cs551@bourbon.usc.edu
Subject: Re: grading guidlines
Someone wrote:
> For the very first test case where we are storing the following -
>
> store blondie1.mp3 1 categories="audio mp3" artist="Blondie"
>
> my bitvector is turing on wrong bits for the keyword artist, though
it is
> computing the sha1 and md5 on the word "artist". Could there be a
reason?
The spec says that you must convert a keyword to all lowercase
before computing the bit-vector. Imagine that if you don't
and others do, then searching will be a problem.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Nov 18 21:38:27 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAJ5cR3f016113
for ; Fri, 18 Nov 2005 21:38:27 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJ5YE1k016399
for ; Fri, 18 Nov 2005 21:34:14 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAJ5YD1U016398
for cs551@merlot.usc.edu; Fri, 18 Nov 2005 21:34:13 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAJ5YDgH016395
for ; Fri, 18 Nov 2005 21:34:13 -0800
Message-Id: <200511190534.jAJ5YDgH016395@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: cachesize = 0, permsize = 0
Date: Fri, 18 Nov 2005 21:34:13 -0800
From: william@bourbon.usc.edu
Someone wrote:
> When cache size and permsize both are zero -
>
> 1. if I search for a file and a remote node replies.
> 2. I do a get (ex get 1)
> 3. now I get this file - but I am not supposed to store it as my
> permsize = 0, right?
> 4. so I can only do a get 1 'filename' and store this file in the given
> filename. Right?
If I'm not misunderstanding what you are saying, it would be
correct.
> Please tell me if this is wrong, cuz the grading guidelines wants me us to
> store the file as a reply of get evn if permsize is zero.
I'm not sure exactly what you meant by "store" here. When
you do a get, a copy of the file should be "stored" in the
current working directory. This should be done independent
of PermSize.
I think you are asking, in addition, if PermSize is zero (or
your perm space is used up), should a copy of the file goes
into the mini filesystem. In this case, the answer is no.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Fri Nov 18 12:21:02 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAIKL2lr003372
for ; Fri, 18 Nov 2005 12:21:02 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAIKGoc2014414
for ; Fri, 18 Nov 2005 12:16:50 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAIKGosq014413
for cs551@merlot; Fri, 18 Nov 2005 12:16:50 -0800
Date: Fri, 18 Nov 2005 12:16:50 -0800
From: william@bourbon.usc.edu
Message-Id: <200511182016.jAIKGosq014413@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: cancelling office hour next Monday (11/21)...
Hi,
I apologize that I have to cancel office hour next Monday.
I've a doctor's appointment that cannot be changed. If you
have questions regarding the final project, please send me
e-mails. I apologize about the inconvenience.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 17 23:28:00 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAI7S0bm017579
for ; Thu, 17 Nov 2005 23:28:00 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAI7Noex012039
for ; Thu, 17 Nov 2005 23:23:50 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAI7NoKI012038
for cs551@merlot.usc.edu; Thu, 17 Nov 2005 23:23:50 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAI7NoKV012035
for ; Thu, 17 Nov 2005 23:23:50 -0800
Message-Id: <200511180723.jAI7NoKV012035@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: status file format
Date: Thu, 17 Nov 2005 23:23:50 -0800
From: william@bourbon.usc.edu
Someone wrote:
> regarding the number of files :
>
> there is no means to tell the number of files till the end of
> message. Since the data is read sequentially from the socket,
> (with a upper limit on the buffer size), this would require that
> we write the data into a temporary file (consider a situation
> where one node has lotsa/huge metafiles stored), count the number
> of files and then report it and proceed to print the temporary
> file into the required status_file.
>
> is it ok to store the temporary file?
Yes. I don't recall having any restriction on using temporary
files in general for this project.
> PS:another option is to tweak the status_reponse to include the
> number of records.
That would be too much change in the spec!
Well, given what you said, I think it's a bit unnecessarily
complex. Therefore, I'm removing the restriction on the
number of files. You can either output the number of files
in the output as in the following example:
nunki.usc.edu:12345 has 2 files
or you can output it without the number of files as in the
following example (please choose the appropriate one):
nunki.usc.edu:12345 has no file
nunki.usc.edu:12345 has the following file
nunki.usc.edu:12345 has the following files
You should be able to decide which one of the 3 to output
without using a temporary file. I've updated the spec.
--
Bill Cheng // bill.cheng@usc.edu
----- Original Message -----
From: william@bourbon.usc.edu
Date: Tuesday, November 15, 2005 11:44 am
Subject: Re: status file format
To: cs551@bourbon.usc.edu
> Someone wrote:
>
> > What is the expected format of the status output file in case
> of
> > "Status file" Command?
>
> You need to have the hostname and hostport of the reporting
> host and the files that it has (full metadata). For example,
> you can have (please replace the "..." with the correct
> information in the status response message):
>
> nunki.usc.edu:12345 has with 2 files
>
> [metadata]
> FileName=blondie1.mp3
> FileSize=1874
> SHA1=8ae005585be9c44ef1910d25dd6f8da58c432ab5
> Nonce=...
> Keywords=categories audio mp3 artist Blondie
> Bit-vector=...
>
> [metadata]
> FileName=usctommy.gif
> FileSize=1689
> SHA1=11cddf2a0378d6a892cf43198847ce379e85d149
> Nonce=...
> Keywords=usc tommy trojan gif
> Bit-vector=...
>
> I will soon update the spec with this information.
> --
> Bill Cheng // bill.cheng@usc.edu
>
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 17 12:19:30 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKJUdR002240
for ; Thu, 17 Nov 2005 12:19:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKFLWg008400
for ; Thu, 17 Nov 2005 12:15:21 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAHKFLXA008399
for cs551@merlot.usc.edu; Thu, 17 Nov 2005 12:15:21 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKFL1D008396
for ; Thu, 17 Nov 2005 12:15:21 -0800
Message-Id: <200511172015.jAHKFL1D008396@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: grading guidlines
Date: Thu, 17 Nov 2005 12:15:21 -0800
From: william@bourbon.usc.edu
Someone wrote:
> For the very first test case where we are storing the following -
>
> store blondie1.mp3 1 categories="audio mp3" artist="Blondie"
>
> my bitvector is turing on wrong bits for the keyword artist, though it is
> computing the sha1 and md5 on the word "artist". Could there be a reason?
The spec says that you must convert a keyword to all lowercase
before computing the bit-vector. Imagine that if you don't
and others do, then searching will be a problem.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 17 12:17:05 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKH5Xp002180
for ; Thu, 17 Nov 2005 12:17:05 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKCupW008358
for ; Thu, 17 Nov 2005 12:12:56 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAHKCujC008357
for cs551@merlot.usc.edu; Thu, 17 Nov 2005 12:12:56 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKCux2008354
for ; Thu, 17 Nov 2005 12:12:56 -0800
Message-Id: <200511172012.jAHKCux2008354@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: " " marks in keywords
Date: Thu, 17 Nov 2005 12:12:56 -0800
From: william@bourbon.usc.edu
Someone wrote:
> In the three beacons network, there is a test case as follows
> search keywords=glass of heart title
> should get 3 responses
>
> the above keywords should be inside double quote according the following
> spec
>
> search keywords="key1 key2 key3"
>
> There should be no blank characters around the equal sign. The double
> quotation marks are mandatory unless there is only one keyword.
Thanks for catching it! There is another one like it. I've
fixed the grading guidelines.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 17 12:11:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAHKBaeI001986
for ; Thu, 17 Nov 2005 12:11:36 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHK7S6P008253
for ; Thu, 17 Nov 2005 12:07:28 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAHK7S49008252
for cs551@merlot.usc.edu; Thu, 17 Nov 2005 12:07:28 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAHK7Rkw008249
for ; Thu, 17 Nov 2005 12:07:27 -0800
Message-Id: <200511172007.jAHK7Rkw008249@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: delete msg
Date: Thu, 17 Nov 2005 12:07:27 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I could generate and verify the digital signature for a file
> using
> openssl smime -sign -in foo -out bar -nocerts -signer cert.pem
> -inkey private.pem and
> openssl smime -verify -noverify -in bar -out /dev/null -signer
> cert.pem -certfile cert.pem
>
> While sending the delete msg, we should sign the filespec
> digitally and send it.
> I did not understand this part[signing the filespec digitally].
> User will input the filespec [filename, sha, nounce] in the cmd
> line.
> we will put it all together in the msg [separate by \r\n] and
> send it.
And you need to put it in the specified format:
FileName=...\r\n
SHA1=...\r\n
Nonce=...\r\n
> Before sending how should i sign the filespec digitally.
> How should i use the above cmds[openssl ---] from the program?
Please see:
http://merlot.usc.edu/cs551-f05/projects/final.html#popen
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 15 23:02:01 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAG721N9006128
for ; Tue, 15 Nov 2005 23:02:01 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAG6vvnI022272
for ; Tue, 15 Nov 2005 22:57:57 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAG6vvXO022271
for cs551@merlot.usc.edu; Tue, 15 Nov 2005 22:57:57 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAG6vvAX022268
for ; Tue, 15 Nov 2005 22:57:57 -0800
Message-Id: <200511160657.jAG6vvAX022268@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: difference between Cached and Permenant files
Date: Tue, 15 Nov 2005 22:57:57 -0800
From: william@bourbon.usc.edu
Someone wrote:
> So then what is the difference between chached files and permanent files?
> I don't understand why we have those two categories?
Well, caching is to improve performance. Permanent files is
more about "functionality" (may be this is not exactly the
right word, but that's the best I can think of right now).
How would the network behave if caching is turned off
everywhere? Files will still get copied if someone does a
"store" or a "get". So, if a file is popular, it would
still get copied everywhere. Caching, in addition, can
improve performance in this type of a p2p network.
> Will I store the cached file in the Homedir/files dir too? With n.data
> n.meta names?
There is no specific one should do this. But I would
probably store both cached files and permanent files in the
$HomeDir/files directory and just keep a bit somewhere to
indicate if a file is cached or permanent. For example, if
you have a file called "n.extra" to keep additional
information about "n.data" and "n.meta" and it's in the INI
format, you can have:
Cached=0 (or 1)
in it.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Wednesday, November 16, 2005 3:00 AM
To: cs551@bourbon.usc.edu
Subject: Re: difference between Cached and Permenant files
Someone wrote:
> What is the difference between cached and permanent files?
The only difference is that a cached file is subject to LRU
replacement.
> If I get a search will I search in my cache too? Or just in permanent?
If you only search permanent files, then what would be the
point of caching? You should search all files.
> Will I delete all my cache files when the node goes down?
No. This is similar to the cached files in your browser.
When you shutdown your browser, it does not delete all the
cached files.
For us, when you do -reset, all files disappaer.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 15 22:04:13 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAG64DHU004840
for ; Tue, 15 Nov 2005 22:04:13 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAG6094R022061
for ; Tue, 15 Nov 2005 22:00:09 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAG609G2022060
for cs551@merlot.usc.edu; Tue, 15 Nov 2005 22:00:09 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAG609ZR022057
for ; Tue, 15 Nov 2005 22:00:09 -0800
Message-Id: <200511160600.jAG609ZR022057@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: difference between Cached and Permenant files
Date: Tue, 15 Nov 2005 22:00:09 -0800
From: william@bourbon.usc.edu
Someone wrote:
> What is the difference between cached and permanent files?
The only difference is that a cached file is subject to LRU
replacement.
> If I get a search will I search in my cache too? Or just in permanent?
If you only search permanent files, then what would be the
point of caching? You should search all files.
> Will I delete all my cache files when the node goes down?
No. This is similar to the cached files in your browser.
When you shutdown your browser, it does not delete all the
cached files.
For us, when you do -reset, all files disappaer.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 15 12:20:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAFKKb0c023814
for ; Tue, 15 Nov 2005 12:20:37 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAFKGZfu020060
for ; Tue, 15 Nov 2005 12:16:35 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAFKGZ4Z020059
for cs551@merlot.usc.edu; Tue, 15 Nov 2005 12:16:35 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAFKGZES020056
for ; Tue, 15 Nov 2005 12:16:35 -0800
Message-Id: <200511152016.jAFKGZES020056@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: status file format
Date: Tue, 15 Nov 2005 12:16:35 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Should it have FileID in Status output? I saw the follow line in grading
> guidline.
>
> (a) CacheProb=0, StoreProb=1, NeighborStoreProb=1
> (+15 points)
>
> in one window, do:
> ~csci551b/bin/resetf2
> /bin/rm n??.ini ??.out
> cp ~csci551b/grading/guidelines/final2/b4/n??.ini .
> cp ~csci551b/public/final2/*.gif .
> cp ~csci551b/public/final2/*.jpg .
> cp ~csci551b/public/final2/*.mp3 .
> ./sv_node n00.ini
> (wait till all other nodes get started)
>
> in 2nd window, do:
> ./sv_node n01.ini
> (wait till all other nodes get started)
>
> in 3rd window, do:
> ./sv_node n02.ini
> (wait till all other nodes get started)
>
> in 1st window, type:
> store blondie1.mp3 1 title="Heart of Glass"
>
> in 2nd window, type:
> "status files 1 01.out", look at "01.out",
> every node should have this file, make sure the
> << file ID >> are different, the metadata should
> look like the following:
>
> It has mentioned to << File ID >> in the status files output.
I'm glad you caught this! It's a bug in the grading guidelines!
Since you only need a FileID when you send search responses, there
should not be a FileID in a status response. I've just updated
the grading guidelines. Thanks!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Tue Nov 15 11:57:30 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAFJvUs5023141
for ; Tue, 15 Nov 2005 11:57:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAFJrSim019820
for ; Tue, 15 Nov 2005 11:53:28 -0800
Message-Id: <200511151953.jAFJrSim019820@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: status file format
Date: Tue, 15 Nov 2005 11:53:28 -0800
From: william@bourbon.usc.edu
I've just udpated the spec. I've also removed the blank lines
in the example. Please see:
http://merlot.usc.edu/cs551-f05/projects/final.html#cmdline
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
Date: Tue, 15 Nov 2005 11:39:42 -0800
From: william@bourbon.usc.edu
To: cs551@bourbon.usc.edu
Subject: Re: status file format
Someone wrote:
> What is the expected format of the status output file in case of
> "Status file" Command?
You need to have the hostname and hostport of the reporting
host and the files that it has (full metadata). For example,
you can have (please replace the "..." with the correct
information in the status response message):
nunki.usc.edu:12345 has with 2 files
[metadata]
FileName=blondie1.mp3
FileSize=1874
SHA1=8ae005585be9c44ef1910d25dd6f8da58c432ab5
Nonce=...
Keywords=categories audio mp3 artist Blondie
Bit-vector=...
[metadata]
FileName=usctommy.gif
FileSize=1689
SHA1=11cddf2a0378d6a892cf43198847ce379e85d149
Nonce=...
Keywords=usc tommy trojan gif
Bit-vector=...
I will soon update the spec with this information.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 15 11:43:44 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAFJhilM022772
for ; Tue, 15 Nov 2005 11:43:44 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAFJdhcW019740
for ; Tue, 15 Nov 2005 11:39:43 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAFJdhtx019739
for cs551@merlot.usc.edu; Tue, 15 Nov 2005 11:39:43 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAFJdgA4019736
for ; Tue, 15 Nov 2005 11:39:42 -0800
Message-Id: <200511151939.jAFJdgA4019736@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: status file format
Date: Tue, 15 Nov 2005 11:39:42 -0800
From: william@bourbon.usc.edu
Someone wrote:
> What is the expected format of the status output file in case of
> "Status file" Command?
You need to have the hostname and hostport of the reporting
host and the files that it has (full metadata). For example,
you can have (please replace the "..." with the correct
information in the status response message):
nunki.usc.edu:12345 has with 2 files
[metadata]
FileName=blondie1.mp3
FileSize=1874
SHA1=8ae005585be9c44ef1910d25dd6f8da58c432ab5
Nonce=...
Keywords=categories audio mp3 artist Blondie
Bit-vector=...
[metadata]
FileName=usctommy.gif
FileSize=1689
SHA1=11cddf2a0378d6a892cf43198847ce379e85d149
Nonce=...
Keywords=usc tommy trojan gif
Bit-vector=...
I will soon update the spec with this information.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Nov 14 22:34:38 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAF6YcPL028397
for ; Mon, 14 Nov 2005 22:34:38 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAF6UdK4016701
for ; Mon, 14 Nov 2005 22:30:39 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAF6UdCw016700
for cs551@merlot.usc.edu; Mon, 14 Nov 2005 22:30:39 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAF6Uc0Q016697
for ; Mon, 14 Nov 2005 22:30:38 -0800
Message-Id: <200511150630.jAF6Uc0Q016697@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Store Keywords
Date: Mon, 14 Nov 2005 22:30:38 -0800
From: william@bourbon.usc.edu
Someone wrote:
> For a keyvalue pair like -- categories="audio mp3" -- should we
> consider 'audio' and 'mp3' as seperate keywords or we should
> consider 'audio mp3' as one keyword.
There are 3 keywords here: "categories", "audio", and "mp3".
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Nov 12 20:57:42 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAD4vgZ6001291
for ; Sat, 12 Nov 2005 20:57:42 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAD4roei018382
for ; Sat, 12 Nov 2005 20:53:50 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAD4roVU018381
for cs551@merlot.usc.edu; Sat, 12 Nov 2005 20:53:50 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAD4rosh018378
for ; Sat, 12 Nov 2005 20:53:50 -0800
Message-Id: <200511130453.jAD4rosh018378@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: CHECK messages...
Date: Sat, 12 Nov 2005 20:53:50 -0800
From: william@bourbon.usc.edu
Someone wrote:
> referring to the line in grading guidelines (towards the end)
>
> "Any CHECK messages in a log file : -2 points"
>
> consider the possibility
>
> 1. 3 nodes, A<-->B<-->C
> 2. Node A shutsdown.... (sends notify)
> 3. I am slow in typing shutdown on node B,
> a) node B receives notify from A
>
> option 1.
> Behave normally, send a CHECK to node C
>
> option 2.
> NOT implement (remove from code) CHECK messaging
>
> option 3.
> Just ignore the CHECK messages got, that is, don't log/flood them
>
> which one of options 1/2/3 do we choose?
>
> it really wont matter as far as the system operation goes, since
> node B would probably shutdown (user typed) soon after sending
> the CHECK message (my implementation will shutdown after pending
> writes on the port, to maintain sane reads on the client).
So, given the above choices, I would say (2). But, for part
(2) of the final project, NoCheck in all startup configuration
file is set to 1. So I wouldn't say "not implement check",
but would say "implement check" according the value of NoCheck
in a startup configuration file.
This should be really easy to implement, especially if you have
check implemented already.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 10 11:45:30 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAAJjUeH017312
for ; Thu, 10 Nov 2005 11:45:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAAJfiuA011797
for ; Thu, 10 Nov 2005 11:41:44 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAAJfiBQ011795
for cs551@merlot.usc.edu; Thu, 10 Nov 2005 11:41:44 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAAJfigM011792
for ; Thu, 10 Nov 2005 11:41:44 -0800
Message-Id: <200511101941.jAAJfigM011792@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Date: Thu, 10 Nov 2005 11:41:44 -0800
From: william@bourbon.usc.edu
Someone wrote:
> So when I get a "get" message - I should chek if I have that FileID - else I
> shud pass it on?
You should always pass it on, based on TTL.
> But isn't this very inefficient - that every node checks for the FileID
Yes! Do you have a suggestion (and preserves anonymity)?
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Thursday, November 10, 2005 12:35 PM
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Someone wrote:
> I understand that I can use GetUOID to generate the FileID, but the get
> message is going to come to me with this FileID - so when I send a
search
> reply shoud I keep a list mapping FileID's to my files inode number -
cuz if
> I try to generate this FileID again I am going to get a different
number.
You definitely should have an in-memory index so that you can
search efficiently. This would be true if you only generate
a temporary FileID (in-memory) when you get a hit or if you
generate a permanent FileID (has an image on disk) when a
file is created. Again, which approach you take is up to you,
but there are different efficiency implications if you decide
to go one way or another.
> How long shud this mapping list live? Wht happens if I get search req
from
> multiple neighbors? How will I identify one mapping list form the other.
If you take the in-memory only FileID approach, I would say
that you need to keep this in memory until your node dies.
The reason is that there is no time limit set between the
time a search response is received and the time subsequent
get requests are issued. If someone issues a get request
after your node reboots, it is okay not to respond.
If you take the on-disk FileID approach, you will need to
build an in-memory cache of FileID's whenever your node
reboots. So, you need to create an on-disk FileID index
file, similar to the SHA1 index file.
I'm not sure what you meant when you ask about multiple
neighbors. For a file, say "3.data", if you take the in-memory
only FileID approach, you can have multiple FileID's for
this file! If you take the on-disk FileID approach, then
each file should only have one unique FileID. The in-memory
index should be keyed on FileID (just like SHA1) and a node
in the index data structure can just store the value "3" to
respond to a get request.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Thursday, November 10, 2005 4:36 AM
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Someone wrote:
> I did not understand how is the FileID generated. When I am sending
the
file
> across I shud generate a FileID for every file. But how?
You can just use GetUOID(). It's *like* another nonce (but
different from the nonce in a file metadata).
Please read the description about Nonce & FileID carefully.
You don't need to generate a FileID for every file. When you
get a hit for a search command, it's only at that time you
need to genearte a FileID for a file that got a hit. Of
course, you could generate a FileID for every file if you
want. This is entirely up to you.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 10 07:38:36 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAAFcaKL011736
for ; Thu, 10 Nov 2005 07:38:36 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAAFYphc010894
for ; Thu, 10 Nov 2005 07:34:51 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAAFYpUx010893
for cs551@merlot.usc.edu; Thu, 10 Nov 2005 07:34:51 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAAFYoEU010890
for ; Thu, 10 Nov 2005 07:34:50 -0800
Message-Id: <200511101534.jAAFYoEU010890@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Date: Thu, 10 Nov 2005 07:34:50 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I understand that I can use GetUOID to generate the FileID, but the get
> message is going to come to me with this FileID - so when I send a search
> reply shoud I keep a list mapping FileID's to my files inode number - cuz if
> I try to generate this FileID again I am going to get a different number.
You definitely should have an in-memory index so that you can
search efficiently. This would be true if you only generate
a temporary FileID (in-memory) when you get a hit or if you
generate a permanent FileID (has an image on disk) when a
file is created. Again, which approach you take is up to you,
but there are different efficiency implications if you decide
to go one way or another.
> How long shud this mapping list live? Wht happens if I get search req from
> multiple neighbors? How will I identify one mapping list form the other.
If you take the in-memory only FileID approach, I would say
that you need to keep this in memory until your node dies.
The reason is that there is no time limit set between the
time a search response is received and the time subsequent
get requests are issued. If someone issues a get request
after your node reboots, it is okay not to respond.
If you take the on-disk FileID approach, you will need to
build an in-memory cache of FileID's whenever your node
reboots. So, you need to create an on-disk FileID index
file, similar to the SHA1 index file.
I'm not sure what you meant when you ask about multiple
neighbors. For a file, say "3.data", if you take the in-memory
only FileID approach, you can have multiple FileID's for
this file! If you take the on-disk FileID approach, then
each file should only have one unique FileID. The in-memory
index should be keyed on FileID (just like SHA1) and a node
in the index data structure can just store the value "3" to
respond to a get request.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Thursday, November 10, 2005 4:36 AM
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Someone wrote:
> I did not understand how is the FileID generated. When I am sending the
file
> across I shud generate a FileID for every file. But how?
You can just use GetUOID(). It's *like* another nonce (but
different from the nonce in a file metadata).
Please read the description about Nonce & FileID carefully.
You don't need to generate a FileID for every file. When you
get a hit for a search command, it's only at that time you
need to genearte a FileID for a file that got a hit. Of
course, you could generate a FileID for every file if you
want. This is entirely up to you.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 9 23:39:57 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAA7dvZi032422
for ; Wed, 9 Nov 2005 23:39:57 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAA7aDHd009329
for ; Wed, 9 Nov 2005 23:36:13 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAA7aDA8009328
for cs551@merlot.usc.edu; Wed, 9 Nov 2005 23:36:13 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAA7aCRL009325
for ; Wed, 9 Nov 2005 23:36:13 -0800
Message-Id: <200511100736.jAA7aCRL009325@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: FileID
Date: Wed, 09 Nov 2005 23:36:12 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I did not understand how is the FileID generated. When I am sending the file
> across I shud generate a FileID for every file. But how?
You can just use GetUOID(). It's *like* another nonce (but
different from the nonce in a file metadata).
Please read the description about Nonce & FileID carefully.
You don't need to generate a FileID for every file. When you
get a hit for a search command, it's only at that time you
need to genearte a FileID for a file that got a hit. Of
course, you could generate a FileID for every file if you
want. This is entirely up to you.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 9 23:03:58 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jAA73wvT031512
for ; Wed, 9 Nov 2005 23:03:58 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAA70EaK009228
for ; Wed, 9 Nov 2005 23:00:14 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jAA70EM1009227
for cs551@merlot.usc.edu; Wed, 9 Nov 2005 23:00:14 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jAA70E1I009224
for ; Wed, 9 Nov 2005 23:00:14 -0800
Message-Id: <200511100700.jAA70E1I009224@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: final project
Date: Wed, 09 Nov 2005 23:00:14 -0800
From: william@bourbon.usc.edu
Someone wrote:
> As one of previous message suggested that not all the things of
> part 1 needs to be done for part 2. Is there anything I could
> skip from part 1 and I would be fine with part 2. I am asking
> this as I was only able to make part 1 work for beacon only
> network, and I have only enough time that I could do the same for
> part 2.
Although Join and Check do not have to work, for a regular
node, you must handle a manually created init_neighbor_list
file correctly.
Please also read my messages with timestamps "Mon 31 Oct
13:14" and "Wed 02 Nov 17:00".
The grading guidelines for part (2) have been posted for
a week now. Please take a look when you have some time.
The TA has mentioned to me that some students' part (1)
cannot work with any of the startup configuration files
specified in the part (1) grading guidelines. I really
don't understand why these students do not test their
code against the startup configuration files specified
in the part (1) grading guidelines. I think I've made it
very clear that the TA will use the grading guidelines to
grade!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Wed Nov 9 12:43:47 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA9Khk7X016656
for ; Wed, 9 Nov 2005 12:43:47 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA9Ke4Yi006626
for ; Wed, 9 Nov 2005 12:40:04 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA9Ke48V006625
for cs551@merlot; Wed, 9 Nov 2005 12:40:04 -0800
Date: Wed, 9 Nov 2005 12:40:04 -0800
From: william@bourbon.usc.edu
Message-Id: <200511092040.jA9Ke48V006625@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: correct to today's lecture...
Hi,
I just realized that I've made a mistake in today's lecture.
I was talking about the fact that ACK compression can cause
problem for bottleneck bandwidth estimation on the ACK path.
I made the comment that in the forward path, *data*
timing compression cannot cause a similar problem. That is
incorrect. (I must have been thinking about something else.)
The good news is that data timing compression does not happen
very often. But one still needs to examine the measurements
very carefully to throw out bad measurements when data timing
compression do occur.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Nov 7 08:03:21 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA7G3LHC018185
for ; Mon, 7 Nov 2005 08:03:21 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA7FxkJF030022
for ; Mon, 7 Nov 2005 07:59:46 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA7FxklM030021
for cs551@merlot.usc.edu; Mon, 7 Nov 2005 07:59:46 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA7FxkGv030018
for ; Mon, 7 Nov 2005 07:59:46 -0800
Message-Id: <200511071559.jA7FxkGv030018@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Regarding first part final project
Date: Mon, 07 Nov 2005 07:59:46 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I just found out a big flaw in my first
> part submission of final project. Can I allow to make changes
> into the first part..
> Actually, I have created a linklist and at one point I for got to
> move the pointer to next that's why it goes to infinite loop
> while I send status message into more than 2 mesh.
The modification deadline was 24 hours after the submission
deadline and it costs 3 points per line during the
modification period. There was no provision made to make
changes after the modification deadline.
Please remember that one major reason points are taken off
for projects is for not testing your program well enough.
So, even if a bug is minor, you can lose many points. Also,
please keep in mind that given infinite amount of time,
everyone can get their project to work right. Therefore,
doing things on time is important when it comes to grading.
Also, grading of these projects is very time consuming.
Asking the TA to do regrades after regrades is not fair to
him, so there must be a deadline for regrade requests.
You can show your changes to the TA and may be he can give
you a few points back. But he cannot do a regrade base on
changes after the modification deadline.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Nov 4 22:09:22 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA569LLO002735
for ; Fri, 4 Nov 2005 22:09:22 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA565t65029884
for ; Fri, 4 Nov 2005 22:05:55 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA565toS029883
for cs551@merlot.usc.edu; Fri, 4 Nov 2005 22:05:55 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA565tiw029880
for ; Fri, 4 Nov 2005 22:05:55 -0800
Message-Id: <200511050605.jA565tiw029880@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: filename in store msg
Date: Fri, 04 Nov 2005 22:05:55 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Store msg is flooded to neighbors according to the
> "neighborStoreProb".
> what should we do, if the neighbour node already has a file with
> the the same filename that is specified in the metadata of the
> store message.
>
> Shall i overwrite it or ignore the store msg.
In the first paragraph of:
http://merlot.usc.edu/cs551-f05/projects/final.html#nonce
the spec says:
we consider that file Y is a copy of file X if X and Y have
identical FileName, SHA1, and Nonce
So, if only the FileName is the same, then you must store the
file. (Even if the FileName and SHA1 are the same but the
Nonce is different, you must also store the file.)
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Nov 4 14:39:53 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA4MdrbO024591
for ; Fri, 4 Nov 2005 14:39:53 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA4MaSjx025431
for ; Fri, 4 Nov 2005 14:36:28 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA4MaSTr025430
for cs551@merlot.usc.edu; Fri, 4 Nov 2005 14:36:28 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA4MaSJi025427
for ; Fri, 4 Nov 2005 14:36:28 -0800
Message-Id: <200511042236.jA4MaSJi025427@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: store probability
Date: Fri, 04 Nov 2005 14:36:28 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I did not understand how to use the "StoreProb".
> Upon recieving a store message, should we store it only if
> the StoreProb >= 0.5
>
> i did not understand how exactly should i treat StoreProb
Well, let's say that StoreProb=0.1. This means that you should
store every 1 out of 10 times. If you use drand48(), it will
return you a value between 0 and 1.0, uniformly distributed.
So, if you want to store 10% of the time, you can say that if
drand48() returns anything <= 0.1 (which is the value of StoreProb
above), you will store.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Nov 3 16:39:48 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA40dmNj026226
for ; Thu, 3 Nov 2005 16:39:48 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA40aQ6G020731
for ; Thu, 3 Nov 2005 16:36:26 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA40aQZj020730
for cs551@merlot.usc.edu; Thu, 3 Nov 2005 16:36:26 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA40aQiM020727
for ; Thu, 3 Nov 2005 16:36:26 -0800
Message-Id: <200511040036.jA40aQiM020727@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: bitvector
Date: Thu, 03 Nov 2005 16:36:26 -0800
From: william@bourbon.usc.edu
Someone wrote:
> we have the following file meta data example in the spec:
> [metadata]
> FileName=blondie1.mp3
> FileSize=4885526
> SHA1=730764e28a5b66e3f95ceadc976c038d389bd89e
> Nonce=b56dba4b2ec8f224de8fc45d6041cdb9f2db9d69
> Keywords=categories audio mp3 artist Blondie \
> title Heart of Glass \
> url http://www.blondie.net/ \
> additional_keywords debra harry
> Bit-vector= \
> 110000100000000420020000000000000000000000000000 \
> 100000000000000000200000000000000000010000010004 \
> 000000000004800000000800000000000000000000000000 \
> 000000000000000000100008800000000000000040048400 \
> 000002100000000000000810000000000000200002000200 \
> 0000000000000000
>
>
> 1) I tried to calculate the metadata value for the keywords given above.
> My answer matched with the above given bit vector, when i changed all
> capital letters in the keywords into lower case. is this right..
> [example "Heart" -> "heart" ]
Yes. That's what the spec says in:
http://merlot.usc.edu/cs551-f05/projects/final.html#bitvec
> 2) for Nounce, to generate a 20byte random number, iam using RAND_bytes( )
> function of "openssl/rand.h". is this correct?
You can just use GetUIOD().
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Wed Nov 2 17:03:52 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA313qjC024833
for ; Wed, 2 Nov 2005 17:03:52 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA310Ygt015713
for ; Wed, 2 Nov 2005 17:00:34 -0800
Message-Id: <200511030100.jA310Ygt015713@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: final project part (2) grading guidelines is available...
Date: Wed, 02 Nov 2005 17:00:34 -0800
From: william@bourbon.usc.edu
Hi,
I've just made the grading guidelines for final project part
(2) available on the project spec (near the bottom). The
grading guidelines is fairly long (almost 900 lines).
It's probably not a good idea to read through it. Once your
code is in a reasonable shape, you should just cut and paste
from this file and see if things are what you expect. If you
don't use csh/tcsh, you can simply do "tcsh" before you cut
and paste.
I've also added additional notes at the bottom of part (2)
testdata page. There are some scripts that have been created
to help you covert the test data files to use your own ports.
The scripts is not bulletproof. So, please follow the
instructions carefully and make sure you are in the *correct
directory*! If you are in the wrong directory, press c
right away! (The script does "rm -rf final2". So, please
make sure you don't have a directory named final2 or your
current working directory is not just above where all your
code is.) It's probably a good idea to make a backup of your
work before you run these scripts.
By the way, part (2) still assumes that you have "status
neighbors" implemented correctly. If it's not working, you
need to get it to work!
If you have questions, please let me know.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 2 13:55:07 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA2Lt7YL019698
for ; Wed, 2 Nov 2005 13:55:07 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA2Lpoac014278
for ; Wed, 2 Nov 2005 13:51:50 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA2LpnNk014277
for cs551@merlot.usc.edu; Wed, 2 Nov 2005 13:51:50 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA2Lpndl014274
for ; Wed, 2 Nov 2005 13:51:49 -0800
Message-Id: <200511022151.jA2Lpndl014274@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Calculating SHA1
Date: Wed, 02 Nov 2005 13:51:49 -0800
From: william@bourbon.usc.edu
I just noticed that the link was provided in the spec.
May be I misunderstood the question. You should do what
you did in warmup #1 but with SHA1 and verify what you
calculated with the output of running "openssl" from the
commandline.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
Date: Wed, 02 Nov 2005 13:46:39 -0800
From: william@bourbon.usc.edu
To: cs551@bourbon.usc.edu
Subject: Re: Calculating SHA1
Someone wrote:
> This might be a silly doubt, but I was wondering how should we calculate
> SHA1 for the file? By reading blocks of data and computing SHA1 on them l
ike
> we did to compute MD5 in warmup1. or is there another way?
I forgot to provide a link to:
http://www.openssl.org/docs/crypto/sha.html
It's very similar to MD5 in terms of calling convention.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Nov 2 13:49:57 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA2Lnv5L019503
for ; Wed, 2 Nov 2005 13:49:57 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA2Lkdnl014244
for ; Wed, 2 Nov 2005 13:46:39 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA2LkdPG014243
for cs551@merlot.usc.edu; Wed, 2 Nov 2005 13:46:39 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA2LkddC014240
for ; Wed, 2 Nov 2005 13:46:39 -0800
Message-Id: <200511022146.jA2LkddC014240@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Calculating SHA1
Date: Wed, 02 Nov 2005 13:46:39 -0800
From: william@bourbon.usc.edu
Someone wrote:
> This might be a silly doubt, but I was wondering how should we calculate
> SHA1 for the file? By reading blocks of data and computing SHA1 on them like
> we did to compute MD5 in warmup1. or is there another way?
I forgot to provide a link to:
http://www.openssl.org/docs/crypto/sha.html
It's very similar to MD5 in terms of calling convention.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Tue Nov 1 11:45:56 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA1JjuOf013890
for ; Tue, 1 Nov 2005 11:45:56 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA1JggWT002553
for ; Tue, 1 Nov 2005 11:42:42 -0800
Message-Id: <200511011942.jA1JggWT002553@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: About the grading guideline.
Date: Tue, 01 Nov 2005 11:42:42 -0800
From: william@bourbon.usc.edu
Hi,
I decided to just change the AutoShutdown value for beacon
nodes to be 1.5 times that for the non-beacon nodes. Things
should work now if the TA types/grades fast enough, :-)
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
Date: Tue, 01 Nov 2005 11:29:51 -0800
From: william@bourbon.usc.edu
To: cs551@bourbon.usc.edu
Subject: Re: About the grading guideline.
Someone wrote:
> I am sorry if I was not able to clearly mention what I meant abt the grad
ing
> guidelines. I did not mean that anything was wrong with them. They are do
ing
> the right thing.
>
> Whatever I have been saying is only for TA's convenience in grading the
> project.
> I am talking abt the test cases where the first test case B(a) and B(b) -
> i.e the first test case in section B of the grading guidelines and second
> test case in section B.
> The test case (a) is testing if the node does a join.
> Test case (b) checks if the node does a join even if it has a
> init_neighbor_list file.
> If the TA runs the test case B(a). The reqular node will come up and crea
te
> its init_neighbor_file. Now if we let both the nodes autoshutdown in test
> case (a) and then run test case B(b), I guess it is expected that the
> regualar node uses the init_neighbor_list file it creates in the earlier
> test case i.e B(a). But as the shutdown timeouts are same when both nodes
> auto shutdown at the end of test case B(a) - the init_neighbor_file will
be
> deleted and when Leslie runs test case B(b) - to check if the node is doi
ng
> a join if it has a init_nieghbor_list file - that file will not exist and
> the node will do a join.
>
> So the problem is running B(b) after B(a) - that's all. So for his
> convenience if he sets the autoshutdown of beacon higher - he will have t
he
> init_neighbor_list file for the regular node when he runs B(b).
>
> I hope I have been able to say it clearly this time. I am sure Leslie wil
l
> be able to find a work around otherwise.
Good point! Thanks for pointing out the problem!
So, the grading guidlines must be modified. Instead of having:
*wait* for both nodes to autoshutdown
on line 200, it should be:
type "shutdown" in the 2nd window
type "shutdown" in the 1st window
It would also make sense to make the AutoShutdown value for
beacon nodes longer.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Tue Nov 1 11:33:05 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id jA1JX5mX013516
for ; Tue, 1 Nov 2005 11:33:05 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA1JTpTp002366
for ; Tue, 1 Nov 2005 11:29:51 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id jA1JTp1c002365
for cs551@merlot.usc.edu; Tue, 1 Nov 2005 11:29:51 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id jA1JTpgx002362
for ; Tue, 1 Nov 2005 11:29:51 -0800
Message-Id: <200511011929.jA1JTpgx002362@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: About the grading guideline.
Date: Tue, 01 Nov 2005 11:29:51 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I am sorry if I was not able to clearly mention what I meant abt the grading
> guidelines. I did not mean that anything was wrong with them. They are doing
> the right thing.
>
> Whatever I have been saying is only for TA's convenience in grading the
> project.
> I am talking abt the test cases where the first test case B(a) and B(b) -
> i.e the first test case in section B of the grading guidelines and second
> test case in section B.
> The test case (a) is testing if the node does a join.
> Test case (b) checks if the node does a join even if it has a
> init_neighbor_list file.
> If the TA runs the test case B(a). The reqular node will come up and create
> its init_neighbor_file. Now if we let both the nodes autoshutdown in test
> case (a) and then run test case B(b), I guess it is expected that the
> regualar node uses the init_neighbor_list file it creates in the earlier
> test case i.e B(a). But as the shutdown timeouts are same when both nodes
> auto shutdown at the end of test case B(a) - the init_neighbor_file will be
> deleted and when Leslie runs test case B(b) - to check if the node is doing
> a join if it has a init_nieghbor_list file - that file will not exist and
> the node will do a join.
>
> So the problem is running B(b) after B(a) - that's all. So for his
> convenience if he sets the autoshutdown of beacon higher - he will have the
> init_neighbor_list file for the regular node when he runs B(b).
>
> I hope I have been able to say it clearly this time. I am sure Leslie will
> be able to find a work around otherwise.
Good point! Thanks for pointing out the problem!
So, the grading guidlines must be modified. Instead of having:
*wait* for both nodes to autoshutdown
on line 200, it should be:
type "shutdown" in the 2nd window
type "shutdown" in the 1st window
It would also make sense to make the AutoShutdown value for
beacon nodes longer.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Mon Oct 31 14:06:31 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9VM6VYN016022
for ; Mon, 31 Oct 2005 14:06:31 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9VM3LVJ029509
for ; Mon, 31 Oct 2005 14:03:21 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9VM3Lxb029508
for cs551@merlot.usc.edu; Mon, 31 Oct 2005 14:03:21 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9VM3KeV029505
for ; Mon, 31 Oct 2005 14:03:20 -0800
Message-Id: <200510312203.j9VM3KeV029505@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Regarding the change in 3 lines
Date: Mon, 31 Oct 2005 14:03:20 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I wanted to know what is the procedure for changing three
> lines in the code. Whom should I mail, and what should be the
> mail content,like line nos or something like that.
Please see:
http://merlot.usc.edu/cs551-f05/projects.html#mods
The deadline for this is the end of tonight.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Mon Oct 31 13:17:31 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9VLHVKj014755
for ; Mon, 31 Oct 2005 13:17:31 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9VLELqa029032
for ; Mon, 31 Oct 2005 13:14:21 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9VLELTB029031
for cs551@merlot; Mon, 31 Oct 2005 13:14:21 -0800
Date: Mon, 31 Oct 2005 13:14:21 -0800
From: william@bourbon.usc.edu
Message-Id: <200510312114.j9VLELTB029031@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: new commandline option for sv_node...
Hi,
I've just modified the definitino of the NoCheck key in the
startup configuration file. It now reads:
[BC: Modified 10/31/2005]
If this value is 0, sending of check messages is enabled when
a non-beacon node loses connection with one of its neighbors.
If this value is 1, sending of cehck messgaes should be
disabled for a non-beacon node. For a beacon node, it must
ignore all check messages. The default value is 0. Please
note that for grading of part (2), this value will always be
1 for all nodes.
During class today, I mentioned about adding a -nocheck
commandline argument. Since there is a NoCheck key in the
startup configuration file already, there is no need to add
the -nocheck commandline argument.
As I mentioned in class today, for the grading of part (2),
we will supply all the init_neighbor_list files for non-beacon
nodes and all startup configuration files will have NoCheck=1
in them. Also, each line in an init_neighbor_list file can be
terminated by either a '\n' or "\r\n", you must make sure you
can handle both cases. You can read a line as before, then
check if the last character (just before '\n') is a '\r'.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Sun Oct 30 22:29:31 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9V6TVpK019878
for ; Sun, 30 Oct 2005 22:29:31 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9V6QNld019823
for ; Sun, 30 Oct 2005 22:26:23 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9V6QNhe019822
for cs551@merlot; Sun, 30 Oct 2005 22:26:23 -0800
Date: Sun, 30 Oct 2005 22:26:23 -0800
From: william@bourbon.usc.edu
Message-Id: <200510310626.j9V6QNhe019822@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: submission event ID for final project part (1)...
Hi,
Just want to make sure that you are using the correct event ID
for making your final project part (1) submission. The event
ID was changed a few weeks back and it is:
merlot.usc.edu_9996_1128715191_1
If you have an old printout of the Electronic Submission
Guidelines web page, the information is out of date. Please
make sure you use the correct event ID when submitting. Thanks!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: william@bourbon.usc.edu
Delivery-Date: Sun Oct 30 21:26:18 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9V5QIJn018162
for ; Sun, 30 Oct 2005 21:26:18 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9V5NAxK019340
for ; Sun, 30 Oct 2005 21:23:10 -0800
Received: (from william@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9V5NAeI019339
for cs551@merlot; Sun, 30 Oct 2005 21:23:10 -0800
Date: Sun, 30 Oct 2005 21:23:10 -0800
From: william@bourbon.usc.edu
Message-Id: <200510310523.j9V5NAeI019339@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: project part (1) deadline approaching...
Hi,
Some of you have not submitted *anything*. I strongly urge
that you submit something *now*. Please remember that the
penalty for late submission is severe and I cannot make any
exceptions. Even if you are one second late, according to
the server clock, 25% of the total points will be taken off!
Please also remember that you can make multiple submissions
and by default, we will grade the last one-time submission.
For those who are not aware, we are no longer in day light
savings time since last night! Please be aware of the server's
clock. If you want to synchronize your watch with the server's
clock, please visit:
http://merlot.usc.edu:9996/bistro/myip.html
--
Bill Cheng // bill.cheng@acm.org
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 15:18:56 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNIuuS009768
for ; Sun, 30 Oct 2005 15:18:56 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNFn1L017649
for ; Sun, 30 Oct 2005 15:15:49 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UNFnob017648
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 15:15:49 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNFnrm017645
for ; Sun, 30 Oct 2005 15:15:49 -0800
Message-Id: <200510302315.j9UNFnrm017645@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Date: Sun, 30 Oct 2005 15:15:49 -0800
From: william@bourbon.usc.edu
Someone wrote:
> About the test case. I am was talking in general but I can explain what I am
> saying with example of test case B(a) and B(b).
> In B(a) - the new node will send a join and join the n/w. now as there r
> only 2 nodes in the n/w. so the beacon is going to be this nodes neighbor.
> When the beacon will go down(Which will before the req node, cuz we r
> starting the beacon early), the node will delete its init_neighbor and try
> to reconnect. This test case is fine - cuz we can see the result with
> status.
> But now when we restart the reg node in B(b) - its init_neighbor_list is
> deleted in earlier excution i.e in B(a) - so it will send a join again.
>
> Which is not what we r trying to test.
If you don't tell me which line you are referring to in the
grading guidlines, I cannot figure out what "are we trying
to test" here!
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Sunday, October 30, 2005 6:10 PM
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Someone wrote:
> I still have a doubt in notify. If I get a keepalive timeout, that means
my
> neighbor is already dead.
How do you know the state of your neighbor? What if it's a
configuration error and its keeplive timeout is wrong?
> Then how will / or why will I send a notify on a
> dead connection. Shud I just log in my log file that this neighbor died?
Or
> I shud still send it a notify with error code 0 and log that in my file
-
> but this message is not going to go to my neighbor. It is dead !!
You must send NTFY.
It's a distributed system. You must follow the protocol and not
assume anything that you cannot determine for sure.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Saturday, October 22, 2005 1:41 PM
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Someone wrote:
> just a final clarification.
>
> When I do not receive keepalive msg from my neighbor for more than
> keepalivetimeout time I send this node a notify message with error
code
= 0.
> Is this right?
Yes (and you close the connection right after).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 15:16:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNGbT2009713
for ; Sun, 30 Oct 2005 15:16:37 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNDUYL017631
for ; Sun, 30 Oct 2005 15:13:30 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UNDUhR017630
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 15:13:30 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UNDUeC017627
for ; Sun, 30 Oct 2005 15:13:30 -0800
Message-Id: <200510302313.j9UNDUeC017627@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: log
Date: Sun, 30 Oct 2005 15:13:30 -0800
From: william@bourbon.usc.edu
Someone wrote:
> should i log only last 4 bytes or all the 20 bytes for the
> in the data part of JNRS msg.
Isn't the spec very clear about this?
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 13:16:56 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9ULGubJ005744
for ; Sun, 30 Oct 2005 13:16:56 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9ULDnI1015873
for ; Sun, 30 Oct 2005 13:13:49 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9ULDnco015872
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 13:13:49 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9ULDnsv015869
for ; Sun, 30 Oct 2005 13:13:49 -0800
Message-Id: <200510302113.j9ULDnsv015869@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Date: Sun, 30 Oct 2005 13:13:49 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Just one more doubt - if I am going down cuz my check failed.. wht shud be
> the notify error -2?
There are only 3 codes:
0: Unknown
1: user shutdown
2: unexpected kill signal received
Failing CHECK is certainly neither 1 or 2.
--
Bill Cheng // bill.cheng@usc.edu
> -----Original Message-----
> From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
> Sent: Saturday, October 22, 2005 1:41 PM
> To: cs551@bourbon.usc.edu
> Subject: Re: closing socket
>
> Someone wrote:
>
> > just a final clarification.
> >
> > When I do not receive keepalive msg from my neighbor for more than
> > keepalivetimeout time I send this node a notify message with error code
> = 0.
> > Is this right?
>
> Yes (and you close the connection right after).
> --
> Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 13:12:54 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9ULCsI4005646
for ; Sun, 30 Oct 2005 13:12:54 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UL9lrl015775
for ; Sun, 30 Oct 2005 13:09:47 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UL9llk015774
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 13:09:47 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UL9kR0015771
for ; Sun, 30 Oct 2005 13:09:46 -0800
Message-Id: <200510302109.j9UL9kR0015771@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Date: Sun, 30 Oct 2005 13:09:46 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I still have a doubt in notify. If I get a keepalive timeout, that means my
> neighbor is already dead.
How do you know the state of your neighbor? What if it's a
configuration error and its keeplive timeout is wrong?
> Then how will / or why will I send a notify on a
> dead connection. Shud I just log in my log file that this neighbor died? Or
> I shud still send it a notify with error code 0 and log that in my file -
> but this message is not going to go to my neighbor. It is dead !!
You must send NTFY.
It's a distributed system. You must follow the protocol and not
assume anything that you cannot determine for sure.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Saturday, October 22, 2005 1:41 PM
To: cs551@bourbon.usc.edu
Subject: Re: closing socket
Someone wrote:
> just a final clarification.
>
> When I do not receive keepalive msg from my neighbor for more than
> keepalivetimeout time I send this node a notify message with error code
= 0.
> Is this right?
Yes (and you close the connection right after).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 13:10:40 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9ULAeJQ005591
for ; Sun, 30 Oct 2005 13:10:40 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UL7XLJ015678
for ; Sun, 30 Oct 2005 13:07:33 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UL7XRs015677
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 13:07:33 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UL7XZA015674
for ; Sun, 30 Oct 2005 13:07:33 -0800
Message-Id: <200510302107.j9UL7XZA015674@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: About the grading guideline.
Date: Sun, 30 Oct 2005 13:07:33 -0800
From: william@bourbon.usc.edu
Someone wrote:
> Even I have been thinking about this problem. According to me the problem is
> not in the same test case where we are testing join, but in the one
> following it. As the one following it checks if the node sends a join if it
> has an init_neighbor_list file. But this file is getting deleted before the
> node goes down.. so it again send a join request in the next test case.
I really have no idea which case you are referring to without
a specific line number.
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu]
Sent: Sunday, October 30, 2005 12:36 PM
To: cs551@bourbon.usc.edu
Subject: Re: About the grading guideline.
Someone wrote:
> I have some comments on the grading guideline. In many test cases,
> beacon nodes and normal nodes usually have the same AutoShutdown value.
> This might raise some problem on grading. For example, suppose we want
> to test node B 'join function', we start beacon node A first and then
> after 10 sec start node B.
> Node B successfully performs its join function and writes the output to
> 'init_neighbor_list' file. Suppose AutoShutdown period is 60 sec and
> JoinTimeout is 5 sec.
> At 60th sec, the beacon node A shutdown itself. Node B senses that it
> get disconnect from neighbor and flood check-req message.
> At 65th sec, check-req timeout, node B will delete it
> 'init_neighbor_list' and rejoin the network which ultimately it will
> fail to rejoin and shutdown itself.
What you said is correct. I don't see how this is in conflict
with the grading guidelines. Could you point out exactly which
line number or give me a section.subsection.subsubsection.
> So, we cannot see the result of node B 'join function' which is our
> original intention due to auto-deletion of init_neigbor_list.
And that's an expected behavior.
> I would like to inform this problem on grading, but if I
> misunderstand in any point, please remind me.
It's possible that you may have misunderstood the grading
guidelines since it's not possible to give *all* details.
The TA is suppose to exercise his judgement and grade fairly!
The grading guidelines is there to give you an idea how
grading is done. You should worry about doing things correctly
and not spend too much time on the grading guidelines. If
your program is behaving largely correct according to the
grading guidelines, you are in pretty good shape!
Even after the grading ends, if you see a bug in the grading
guidelines, please let me know!
As I've mentioned before, the grading guidelines may be changed.
But if there is no good enough reason to change it, it will stay
as it is.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 07:56:44 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFuicd030878
for ; Sun, 30 Oct 2005 07:56:44 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFrcTs012281
for ; Sun, 30 Oct 2005 07:53:38 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UFrclM012280
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 07:53:38 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFrc5s012277
for ; Sun, 30 Oct 2005 07:53:38 -0800
Message-Id: <200510301553.j9UFrc5s012277@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: notify msg [error code = 2]
Date: Sun, 30 Oct 2005 07:53:38 -0800
From: william@bourbon.usc.edu
Someone wrote:
> In notify messages, it is said that error code = 2 if we catch
> SIGTERM or SIGINT.
I search the spec and could not find any mention of SIGINT.
I've said that in an e-mail, but that's a mistake (sorry!).
The spec is correct.
> But, when a node recieves notify from a neighbour, it will close
> the socket connection between these two
> nodes. And it is said that when cntrl+C is pressed, the node
> should not shutdown.
>
> here, cntrl+ C generates SIGINT/SIGTERM signals.
> so, am i supposed to send notify msg with error code = 2 when
> cntrl + C is pressed.
>
> I did not understand when exactly should the error code in notify
> msg be 2.
> If i have to send notify msg with error code = 2 when cntrl+C is
> pressed, should i terminate the node?
The spec is very clear about this:
^C (Control-c) should never cause your program to terminate.
> can i send a word document for readme file rather than text
> document [ like to include my architecture figure ]
No! If you have a picture, save it in JPEG or GIF and include
it with your submission and refer to it by filename. Please
make sure you do not forget to include it in your submission!
If you forgot, you won't get a chance to submit it after the
deadline.
If you really want to have the pictures inline, you only acceptable
formats are Text, PDF, Postscript and HTML. Postscript file
generated in Windows often cannot be printed. So, if you cannot
view it to verify that it's viewable, please use another format.
If you don't have a PDF generator in Windows, you can find some
free PDF generators on the net. MS Word also export in HTML,
but the figures are kept in separate files. Please maks sure
you verify your submission:
http://merlot.usc.edu/cs551-f05/submit.html#verify
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 07:39:14 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFdEh6030419
for ; Sun, 30 Oct 2005 07:39:14 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFa8Ma011907
for ; Sun, 30 Oct 2005 07:36:08 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UFa8CR011906
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 07:36:08 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFa8I5011903
for ; Sun, 30 Oct 2005 07:36:08 -0800
Message-Id: <200510301536.j9UFa8I5011903@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: About the grading guideline.
Date: Sun, 30 Oct 2005 07:36:08 -0800
From: william@bourbon.usc.edu
Someone wrote:
> I have some comments on the grading guideline. In many test cases,
> beacon nodes and normal nodes usually have the same AutoShutdown value.
> This might raise some problem on grading. For example, suppose we want
> to test node B 'join function', we start beacon node A first and then
> after 10 sec start node B.
> Node B successfully performs its join function and writes the output to
> 'init_neighbor_list' file. Suppose AutoShutdown period is 60 sec and
> JoinTimeout is 5 sec.
> At 60th sec, the beacon node A shutdown itself. Node B senses that it
> get disconnect from neighbor and flood check-req message.
> At 65th sec, check-req timeout, node B will delete it
> 'init_neighbor_list' and rejoin the network which ultimately it will
> fail to rejoin and shutdown itself.
What you said is correct. I don't see how this is in conflict
with the grading guidelines. Could you point out exactly which
line number or give me a section.subsection.subsubsection.
> So, we cannot see the result of node B 'join function' which is our
> original intention due to auto-deletion of init_neigbor_list.
And that's an expected behavior.
> I would like to inform this problem on grading, but if I
> misunderstand in any point, please remind me.
It's possible that you may have misunderstood the grading
guidelines since it's not possible to give *all* details.
The TA is suppose to exercise his judgement and grade fairly!
The grading guidelines is there to give you an idea how
grading is done. You should worry about doing things correctly
and not spend too much time on the grading guidelines. If
your program is behaving largely correct according to the
grading guidelines, you are in pretty good shape!
Even after the grading ends, if you see a bug in the grading
guidelines, please let me know!
As I've mentioned before, the grading guidelines may be changed.
But if there is no good enough reason to change it, it will stay
as it is.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sun Oct 30 07:30:32 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFUVHI030228
for ; Sun, 30 Oct 2005 07:30:32 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFRPoM011840
for ; Sun, 30 Oct 2005 07:27:25 -0800
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9UFRPe7011839
for cs551@merlot.usc.edu; Sun, 30 Oct 2005 07:27:25 -0800
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9UFRPcB011836
for ; Sun, 30 Oct 2005 07:27:25 -0800
Message-Id: <200510301527.j9UFRPcB011836@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: error code for notify messages
Date: Sun, 30 Oct 2005 07:27:25 -0800
From: william@bourbon.usc.edu
Someone wrote:
> while getting UOID, is it true that
>
> all messages (join, hello, etc) have "msg" as the obj_type in
> the GetUOID function?
It doesn't matter! You can use "msg", or you can use "join",
"hello", "foobar", or whatever.
> the uniqueness is coming from the seq_no within the function....
Yes!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 23:06:51 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9U66pP0026859
for ; Sat, 29 Oct 2005 23:06:51 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U63kbo021000
for ; Sat, 29 Oct 2005 23:03:46 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9U63kgi020999
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 23:03:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U63kan020996
for ; Sat, 29 Oct 2005 23:03:46 -0700
Message-Id: <200510300603.j9U63kan020996@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: error code for notify messages
Date: Sat, 29 Oct 2005 23:03:46 -0700
From: william@bourbon.usc.edu
Someone wrote:
> According to the previous message...on a keepalive timeout the
> error code for notify message shld be 0....lets consider this
> scenario....node A is connected to node B....node A goes
> down...after some time node B's keepalive timer for A will
> expire.....what I dont understand is to whom will B now send a
> notify message with error code 0 since A is already down......
If node B gets a NTFY from node A, node B will know that
node A will disconnect soon. Therefore, node B should
close the connection (or soon A will close the connection
anyway). So, there will be no connection left between A
and b.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 21:00:50 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9U40o1J023377
for ; Sat, 29 Oct 2005 21:00:50 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U3vkYP020251
for ; Sat, 29 Oct 2005 20:57:46 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9U3vkwh020250
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 20:57:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U3vkeb020231
for ; Sat, 29 Oct 2005 20:57:46 -0700
Message-Id: <200510300357.j9U3vkeb020231@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: error code for notify messages
Date: Sat, 29 Oct 2005 20:57:46 -0700
From: william@bourbon.usc.edu
Someone wrote:
> According to specs ....for notify messages....a error code of 1
> stands for user shutdown and a 2 stands for kill signal....
> Does this mean..that Autoshutdown corresponds to error code
> 1...and user entered 'shutdown' corresponds to 2.
Please see my message with timestamp "Fri, 21 Oct 21:30".
> Also am i supposed to send a notify message in both the cases.
You should send NTFY in both cases and more. Before you
call close() on a socket, send NTFY.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 20:56:30 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9U3uU2F023268
for ; Sat, 29 Oct 2005 20:56:30 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U3rPrr020169
for ; Sat, 29 Oct 2005 20:53:25 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9U3rPdF020168
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 20:53:25 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9U3rPXO020165
for ; Sat, 29 Oct 2005 20:53:25 -0700
Message-Id: <200510300353.j9U3rPXO020165@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: -reset for beacon (final project question)
Date: Sat, 29 Oct 2005 20:53:25 -0700
From: william@bourbon.usc.edu
Someone wrote:
> 1) what does "-reset " in the commad line argument mean for a
> beacon node? (I am asking this because beacon will never send a
> joint request to another beacon according to my understanding of
> the spec)
You may create any files in your HomeDir. So, if a -reset
command is issued, you should delete all files created by
your node.
> 2) will a beacon ever send a join request to another beacon?
> if not, isnt -reset invalid for beacon node?
A beacon node never sends a join to another beacon. Please
see above regarding -reset.
> 3) In hello message logging: is port and host name.
> Shouldnt it be host and port number of destination instead of
> data part of the hello message?
It's what's in the message body.
> 4)In logging for each entry is == 26 always ? as it should
> account for message header.
It should be at least 26. It should be actual size of the message.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 13:47:47 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9TKllou013508
for ; Sat, 29 Oct 2005 13:47:47 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TKiinw018991
for ; Sat, 29 Oct 2005 13:44:44 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9TKiijH018990
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 13:44:44 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TKii6T018987
for ; Sat, 29 Oct 2005 13:44:44 -0700
Message-Id: <200510292044.j9TKii6T018987@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: starting the node in background
Date: Sat, 29 Oct 2005 13:44:44 -0700
From: william@bourbon.usc.edu
Someone wrote:
> my hash tables is configurable. for our current n/w a hash table size of 10
> is also giving a good performance. i am logging collisions that occur and i
> have only found a few in last part of test cases.
> But if the size of the n/w increases my hash table size can be configured
> accordingly. thats why i feel they r giving a good performace..
Well, as long as it's less than or equal to O(log(n)), then
it's fine. You should mention what you said above in your
README file.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 08:51:39 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFpda1006823
for ; Sat, 29 Oct 2005 08:51:39 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFma0m018305
for ; Sat, 29 Oct 2005 08:48:36 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9TFmaU5018304
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 08:48:36 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFmawU018301
for ; Sat, 29 Oct 2005 08:48:36 -0700
Message-Id: <200510291548.j9TFmawU018301@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: timespan for keepalive messages
Date: Sat, 29 Oct 2005 08:48:36 -0700
From: william@bourbon.usc.edu
Someone wrote:
> Can you please tell me the when are we supposed to send keepalive
> messages to our neighbours. I mean in what duration......should
> it be constant...
Please see my message with timestamp "Tue 11 Oct 19:38".
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 08:47:46 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFlkAF006716
for ; Sat, 29 Oct 2005 08:47:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFihcT018232
for ; Sat, 29 Oct 2005 08:44:43 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9TFihqo018231
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 08:44:43 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9TFihMD018228
for ; Sat, 29 Oct 2005 08:44:43 -0700
Message-Id: <200510291544.j9TFihMD018228@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Request for Extension
Date: Sat, 29 Oct 2005 08:44:43 -0700
From: william@bourbon.usc.edu
Someone wrote:
> Its a little bit tough to complete first part before Sunday
> midnight. It would be great for most of the students if you can
> kindly give us 24-48 hrs extension on part 1 with keeping the
> deadline for part 2 as it is. My honest suggestion is that please
> flood the message of polling on class mailing list and please
> take your decision based on majority replies. By doing that I
> think whole class will be benefited along with me and we will get
> more better code to submit.
Unfortunately, this class is graded on a curve. If it's on
an absolute scale, then an extension would be possible.
I think some students have finished part (1). It would be
extremely unfair to them if there is an extension and they
don't get a lot of extra points. (Voting is not right at
this point because if 90% of the class decides to be unfair
to the rest of the class, I must not allow that to happen.)
5 weeks is a lot of time and it was your job to plan your
time (and took my warnings seriously). And I do expect you
to finish part (1) even if you cannot meet the deadline
because part (2) depends on it.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Sat Oct 29 00:06:21 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9T76LR6026749
for ; Sat, 29 Oct 2005 00:06:21 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9T73Kt3016628
for ; Sat, 29 Oct 2005 00:03:20 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9T73KFN016627
for cs551@merlot.usc.edu; Sat, 29 Oct 2005 00:03:20 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9T73KXr016624
for ; Sat, 29 Oct 2005 00:03:20 -0700
Message-Id: <200510290703.j9T73KXr016624@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: starting the node in background
Date: Sat, 29 Oct 2005 00:03:20 -0700
From: william@bourbon.usc.edu
Someone wrote:
> About the hash tables, did you mean to say that hash tables will give a
> performance better than O(log(n)) for our project and so they shud be fine.
> Or u meant that I shud prove that they r giving a performance better than
> log(n). According to me for our assignment hash tables will surely give a
> better performance than binary tree.
The usual claim for a hash table is that it's O(1). But
how do you know it's O(1)? Clearly, if there is only one
bucket in the hash table and it uses a linear list to handle
collisions, then the performance is O(n). So, are you using
an O(1) hash table?
Certainly I don't want to see a "proof" in your README file.
But you should know how good your hash table is and if it's
really that good.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 16:57:41 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNvfX2016525
for ; Fri, 28 Oct 2005 16:57:41 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNsfox014826
for ; Fri, 28 Oct 2005 16:54:41 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SNsfpj014825
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 16:54:41 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNsef7014822
for ; Fri, 28 Oct 2005 16:54:41 -0700
Message-Id: <200510282354.j9SNsef7014822@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: starting the node in background
Date: Fri, 28 Oct 2005 16:54:40 -0700
From: william@bourbon.usc.edu
Someone wrote:
> i was trying to start the node is background to comply with the following
> specs -
>
> You should be able to bootstrap your SERVANT system using a shell script
> for several nodes to be running on the same machine. For example, the
> following shell script should bootstrap into a SERVANT system with 4
> nodes on the same machine:
>
> #!/bin/csh -f
>
> sv_node start-12311.ini &
> sleep 2
> sv_node start-12312.ini &
> sv_node start-12313.ini &
> sleep 3
> sv_node start-12314.ini &
>
> It could be the case that these 4 nodes are all beacon nodes if the
> [beacons] section of the .ini files has all of them cross listed and these
> nodes are started on the correct machine. (It should be clear that
> multiple nodes will run on the same machine.)
>
> You might want to think about how to kill all these processes to make it
> easy for yourself to restart your experiment.
>
> *Hint:* If a sv_node is started in the background, it cannot read standard
> input. So you might want to feed it an empty file as standard input. For
> example, if you create an empty file and call it "null", you can then do:
>
> sv_node start-12311.ini < null &
If this is what you are trying to do, you should make sure that
once you read EOF from the keyboard, you don't write the prompt
and attempt to read the keyboard any more.
> Also will you cut points if I am using a hash table for routing cache?
Hash table should have performance better than O(log(n)).
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 16:53:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNrbQD016427
for ; Fri, 28 Oct 2005 16:53:37 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNobsl014769
for ; Fri, 28 Oct 2005 16:50:37 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SNobV6014768
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 16:50:37 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SNoajd014765
for ; Fri, 28 Oct 2005 16:50:36 -0700
Message-Id: <200510282350.j9SNoajd014765@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Broken pipe over connection
Date: Fri, 28 Oct 2005 16:50:36 -0700
From: william@bourbon.usc.edu
Someone wrote:
> yes what leslie mentioned is abt writing after a successful connects. but
> the given solution also solves the problem if connect is blocking. I have no
> clue why this was happening but, my connect suddenly started blocking one
> fine day (ofcourse after i made soem changes to the code:)) and the i tried
> to put my socket call inside the for loop and it worked and that is how this
> really unexplainable solution came up in the first place. It was never meant
> to be for SIGPIPES, but it works for that too. and i am curious to knw why?
Well, I don't have a general answer since it probably depends
on exactly what your code looks like.
> but at the same time - its worth mentioning that at this point of time my
> socket was not currupted, i cudnt evn see it on netstat.
May be you need to use some other netstat parameters to see it.
If it's there, netstat should know about it.
> so it was not
> blocked or anything. So I thought maybe I cant reuse a socket if connect
> fails, which i am sure is not true and whole thing comes down to having some
> currupted memory somewhere. which i am too scared to find out where at this
> point of time. :)
My guess is that it's also very important to close the socket
if connect() failed.
In general, we do not know exactly how one vendor implements
functions such as connect(). So, is a specific behavior
vendor dependant? Who knows for sure! All I know is that
if you want your connect() to work right, you need to do
something like what's in:
http://merlot.usc.edu/cs551-f05/projects/connect.html
And boy, does it have a lot of #ifdef's! But this is what
we have to deal with if we want to do this "professionally".
--
Bill Cheng // bill.cheng@usc.edu
On 10/28/05, william@bourbon.usc.edu wrote:
>
> Hi,
>
> I think what Leslie mentioned is probably the cause of most
> of the SIGPIPE problems right after a successful connect().
> "Inside the loop" is the key. Another way to look at it is
> to make what's inside the while loop a function. I've
> mentioned that you should have checked out the approach taken
> in:
>
> http://merlot.usc.edu/cs551-f05/projects/connect.html
> --
> Bill Cheng // bill.cheng@usc.edu
>
>
>
>
> -----Original Message-----
> Date: Fri, 28 Oct 2005 15:50:17 -0700
> From: leslie cheung
> To: cs551@merlot.usc.edu
> Subject: Re: Broken pipe over connection
>
> Hi all,
>
> I debugged a couple SIGPIPE problems, and I hope this information
> is useful.
>
> So I assume if we are unable to connect to the other node (e.g.,
> it has not been started), we sleep for a while, and try again
> later. One problem I saw is that when you try "reusing" a socket,
> it is able to complete "connect", but whenever you send something
> using that reused socket, you get SIGPIPE. Why? I have no idea
> either, but this is how things work
>
> Instead of saying...
>
> -------------------------------------
> int sockfd = socket(...);
>
> while (!done){
> if (connect(sockfd, ...) < 0){
> //cannot connect
> } else {
> //it won't give you an error for connect, so it comes here
> //but if you try to send something, it gives you SIGPIPE
> write(sockfd, ...); //this line give you SIGPIPE
> }
> sleep(10);
> }
> -------------------------------------
>
> You should do
>
> -------------------------------------
>
> while (!done){
> int sockfd = socket(...);
> if (connect(sockfd, ...) < 0){
> //cannot connect
> //you should now close the socket
> close(sockfd);
> } else {
> //connected
> //now if you send something, it should work
> write(sockfd, ...); //this should work
> }
> sleep(10);
> }
> -------------------------------------
>
> In other words, you should create a new socket "inside the loop".
> Again, this is just one possible scenario that may give you SIGPIPE. Yours
> might be some other problems.
>
>
> Leslie
>
> ----- Original Message -----
> From: william@bourbon.usc.edu
> Date: Friday, October 28, 2005 3:12 pm
> Subject: Re: Broken pipe over connection
> To: cs551@bourbon.usc.edu
>
> > Someone wrote:
> >
> > > I am also getting the same error. I have tried hard enough but
> > > cannot find the problem. I am catching SIGPIPE but that still
> > > doesnt solve the problem. I dont know what to do.
> >
> > Well, until you can find the bug, you can simply ignore SIGPIPE.
> > Or you can catch it and do nothing but log it. One day, you
> > may notice that, "Hey, if I do this and that, there is no SIGPIPE
> > in my log file!" Then it may help you further debug your code.
> > --
> > Bill Cheng // bill.cheng@usc.edu
> >
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 16:00:29 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SN0TjZ015121
for ; Fri, 28 Oct 2005 16:00:29 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMvTOo014508
for ; Fri, 28 Oct 2005 15:57:29 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SMvTOV014507
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 15:57:29 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMvTEL014504
for ; Fri, 28 Oct 2005 15:57:29 -0700
Message-Id: <200510282257.j9SMvTEL014504@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Broken pipe over connection
Date: Fri, 28 Oct 2005 15:57:29 -0700
From: william@bourbon.usc.edu
Hi,
I think what Leslie mentioned is probably the cause of most
of the SIGPIPE problems right after a successful connect().
"Inside the loop" is the key. Another way to look at it is
to make what's inside the while loop a function. I've
mentioned that you should have checked out the approach taken
in:
http://merlot.usc.edu/cs551-f05/projects/connect.html
--
Bill Cheng // bill.cheng@usc.edu
-----Original Message-----
Date: Fri, 28 Oct 2005 15:50:17 -0700
From: leslie cheung
To: cs551@merlot.usc.edu
Subject: Re: Broken pipe over connection
Hi all,
I debugged a couple SIGPIPE problems, and I hope this information
is useful.
So I assume if we are unable to connect to the other node (e.g.,
it has not been started), we sleep for a while, and try again
later. One problem I saw is that when you try "reusing" a socket,
it is able to complete "connect", but whenever you send something
using that reused socket, you get SIGPIPE. Why? I have no idea
either, but this is how things work
Instead of saying...
-------------------------------------
int sockfd = socket(...);
while (!done){
if (connect(sockfd, ...) < 0){
//cannot connect
} else {
//it won't give you an error for connect, so it comes here
//but if you try to send something, it gives you SIGPIPE
write(sockfd, ...); //this line give you SIGPIPE
}
sleep(10);
}
-------------------------------------
You should do
-------------------------------------
while (!done){
int sockfd = socket(...);
if (connect(sockfd, ...) < 0){
//cannot connect
//you should now close the socket
close(sockfd);
} else {
//connected
//now if you send something, it should work
write(sockfd, ...); //this should work
}
sleep(10);
}
-------------------------------------
In other words, you should create a new socket "inside the loop".
Again, this is just one possible scenario that may give you SIGPIPE. Yours might be some other problems.
Leslie
----- Original Message -----
From: william@bourbon.usc.edu
Date: Friday, October 28, 2005 3:12 pm
Subject: Re: Broken pipe over connection
To: cs551@bourbon.usc.edu
> Someone wrote:
>
> > I am also getting the same error. I have tried hard enough but
> > cannot find the problem. I am catching SIGPIPE but that still
> > doesnt solve the problem. I dont know what to do.
>
> Well, until you can find the bug, you can simply ignore SIGPIPE.
> Or you can catch it and do nothing but log it. One day, you
> may notice that, "Hey, if I do this and that, there is no SIGPIPE
> in my log file!" Then it may help you further debug your code.
> --
> Bill Cheng // bill.cheng@usc.edu
>
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 15:46:46 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMkkJx014765
for ; Fri, 28 Oct 2005 15:46:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMhk0S014376
for ; Fri, 28 Oct 2005 15:43:46 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SMhkdL014375
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 15:43:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMhkuo014372
for ; Fri, 28 Oct 2005 15:43:46 -0700
Message-Id: <200510282243.j9SMhkuo014372@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: regarding TTL for Notify
Date: Fri, 28 Oct 2005 15:43:46 -0700
From: william@bourbon.usc.edu
Someone wrote:
> I am confused when the regular node sends a join request msg, it
> gets the join response msgs and then it goes down to restart all
> over again. when it is going down, should it send a notify msg to
> the beacon it has connected ?
In this case, you don't need to send a NTFY message because
this regular node is *not participating in the network* yet.
(But if you are sending it, it should not cause any problem.)
--
Bill Cheng // bill.cheng@usc.edu
william@bourbon.usc.edu wrote:
Someone wrote:
> What should be the TTL for Notify?
Shouldn't it be one?
> Also, when a regular node joins the network, should its neighbour
> list consist of the beacon node?
I'm not sure what you mean by "neighbor list". But if you
mean "init_neighbor_list file", please look at slide 14 of
lecture 10 to see that it doesn't have to be the case.
> And after joining the network, when the regular node is going
> down, should it send the NTFY msg?
I'm not sure why you asked about "regular node". Remember,
operationally, there is very little difference between a
regular node and a beacon node. If a node is going down,
it should send NTFY messages to its connected neighbors
telling them that it is disconnecting.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 15:12:21 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SMCLGv013829
for ; Fri, 28 Oct 2005 15:12:21 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SM9LJF011938
for ; Fri, 28 Oct 2005 15:09:21 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SM9LM6011937
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 15:09:21 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SM9L1R011934
for ; Fri, 28 Oct 2005 15:09:21 -0700
Message-Id: <200510282209.j9SM9L1R011934@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Broken pipe over connection
Date: Fri, 28 Oct 2005 15:09:21 -0700
From: william@bourbon.usc.edu
Someone wrote:
> I am also getting the same error. I have tried hard enough but
> cannot find the problem. I am catching SIGPIPE but that still
> doesnt solve the problem. I dont know what to do.
Well, until you can find the bug, you can simply ignore SIGPIPE.
Or you can catch it and do nothing but log it. One day, you
may notice that, "Hey, if I do this and that, there is no SIGPIPE
in my log file!" Then it may help you further debug your code.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 15:00:09 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SM09js013548
for ; Fri, 28 Oct 2005 15:00:09 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SLv9W8011765
for ; Fri, 28 Oct 2005 14:57:09 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SLv9sR011764
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 14:57:09 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SLv9eq011761
for ; Fri, 28 Oct 2005 14:57:09 -0700
Message-Id: <200510282157.j9SLv9eq011761@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: starting the node in background
Date: Fri, 28 Oct 2005 14:57:09 -0700
From: william@bourbon.usc.edu
Someone wrote:
> I am not sure what all needs to be dne before starting a node in background.
>
> If i start my node is background with i/p redirected to an empty file. my
> prog simply prints the servent:port> prompt indefinetly. I dnt have a clue
> where or how i shud address this .. can u please get me started?
I don't know if it makes sense to put a node in the background
since it needs to interact with keyboard input. I'm not sure
why you would be getting input from the keyboard indefinitely.
The only thing I can think of is that if you use non-blocking
I/O when you read the keyboard input, you may be getting it
returned infinitely often. But I'm not sure about this since
it may depend on exactly how it's done.
> also can u please mention if there is anything else missing in the grading
> guidlines - like the necessity of O(log(n)) search on routing table.
> or running all those test cases is all that is expected?
The TA may even modify the grading guidelines if he sees that
something is missed! So, there is no way I can be complete.
(The grading guidelines is already really really long!)
Well, the only way I can be complete is to say that if you
violate the spec, points *may be* taken off. The O(log(n))
stuff was clearly mentioned in the spec. I added it because
something someone said reminded me that I didn't put it in
the grading guidelines.
*If* you did not use a BST for the route/message cache and
*if* you are *not* completely sure that making it work with a
BST will not break any of your existing code, I strongly
suggest that you should let the 5 ponts go at this point of
the project! Risking losing all those positive points just
to save 5 negative points is not a good strategy.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 14:44:40 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SLieIO013172
for ; Fri, 28 Oct 2005 14:44:40 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SLfeLR011704
for ; Fri, 28 Oct 2005 14:41:40 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SLfecW011703
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 14:41:40 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SLfeAa011700
for ; Fri, 28 Oct 2005 14:41:40 -0700
Message-Id: <200510282141.j9SLfeAa011700@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: regarding TTL for Notify
Date: Fri, 28 Oct 2005 14:41:40 -0700
From: william@bourbon.usc.edu
Someone wrote:
> What should be the TTL for Notify?
Shouldn't it be one?
> Also, when a regular node joins the network, should its neighbour
> list consist of the beacon node?
I'm not sure what you mean by "neighbor list". But if you
mean "init_neighbor_list file", please look at slide 14 of
lecture 10 to see that it doesn't have to be the case.
> And after joining the network, when the regular node is going
> down, should it send the NTFY msg?
I'm not sure why you asked about "regular node". Remember,
operationally, there is very little difference between a
regular node and a beacon node. If a node is going down,
it should send NTFY messages to its connected neighbors
telling them that it is disconnecting.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 07:55:34 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEtYrk003849
for ; Fri, 28 Oct 2005 07:55:34 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEqZIj010554
for ; Fri, 28 Oct 2005 07:52:35 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SEqZ26010553
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 07:52:35 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEqZWV010550
for ; Fri, 28 Oct 2005 07:52:35 -0700
Message-Id: <200510281452.j9SEqZWV010550@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Question Regarding Caching
Date: Fri, 28 Oct 2005 07:52:35 -0700
From: william@bourbon.usc.edu
Someone wrote:
> We need to store UOIDs in to the cache. Specification states that
> lookup of UOID in cache requires O(logn) efficeincy. So do we
> need to implement a binary tree search? or is there any other
> method for the lookup?
You should use at least a binary search tree (which is probably
the simplest for achieving O(log n) or better). You can also
use other trees or hash tables.
If you are out of time, you can just use a linked list and
mention it in the README file and lose a few points. (I forgot
to mention this in the grading guidlines, I'll need to mofidy
it.)
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Fri Oct 28 07:48:55 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEmtV6003699
for ; Fri, 28 Oct 2005 07:48:55 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEjulE010499
for ; Fri, 28 Oct 2005 07:45:56 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9SEju8D010498
for cs551@merlot.usc.edu; Fri, 28 Oct 2005 07:45:56 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9SEju9Q010495
for ; Fri, 28 Oct 2005 07:45:56 -0700
Message-Id: <200510281445.j9SEju9Q010495@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Broken pipe over connection
Date: Fri, 28 Oct 2005 07:45:56 -0700
From: william@bourbon.usc.edu
Someone wrote:
> When my nodes establishes connection between them and one of the
> node tries to send HLLO message, it gets broken pipe and
> connection breaks. Any hint why this is happening?
First make sure you are catching SIGPIPE. As I explained
before, you should think of getting SIGPIPE as "normal"
for network programming since you never know when the other
size may disconnect. Not catching it is just asking for
trouble!
Given that you've caught SIGPIPE, I guess you are asking
why would you get SIGPIPE if the other side has not closed
the connection. Well, my guess is that it's a memory
corruption bug that somehow affected your socket calls.
Please see the usual URL:
http://merlot.usc.edu/cs551-f05/projects.html#segfault
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Oct 27 14:18:07 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9RLI79p010801
for ; Thu, 27 Oct 2005 14:18:07 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RLFBGY006649
for ; Thu, 27 Oct 2005 14:15:11 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9RLFB40006648
for cs551@merlot.usc.edu; Thu, 27 Oct 2005 14:15:11 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RLFB3W006645
for ; Thu, 27 Oct 2005 14:15:11 -0700
Message-Id: <200510272115.j9RLFB3W006645@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: autoshut down
Date: Thu, 27 Oct 2005 14:15:11 -0700
From: william@bourbon.usc.edu
Someone wrote:
> If I start 4 nodes one after the other - with my beacon node starting first
> - my beacon obviously autoshuts down before the other nodes. Then those
> nodes get a notify and they send out checks - if check fails, then go down
> delete init_neighbor_list and try to send join to the beacon. But the beacon
> is already dead. So join fails and they come out with no init_neighbor_list
> file. Is this behavious correct. Or something else is expected when a
> neighbor autoshuts down?
Sounds right!
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Oct 27 14:03:49 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9RL3niK010408
for ; Thu, 27 Oct 2005 14:03:49 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RL0rXc006578
for ; Thu, 27 Oct 2005 14:00:53 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9RL0rpT006577
for cs551@merlot.usc.edu; Thu, 27 Oct 2005 14:00:53 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RL0rLK006574
for ; Thu, 27 Oct 2005 14:00:53 -0700
Message-Id: <200510272100.j9RL0rLK006574@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: resetf1
Date: Thu, 27 Oct 2005 14:00:53 -0700
From: william@bourbon.usc.edu
Someone wrote:
> Is the node not supposed to shutdown for ctr-c in part one too? I am
> handling ctr-c to safely shutdown the node.
Since the server can take keyboard input and c during
normal operation, you should not kill the server when c
is entered.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Oct 27 12:35:53 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9RJZqh7008230
for ; Thu, 27 Oct 2005 12:35:53 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RJWuBM006315
for ; Thu, 27 Oct 2005 12:32:56 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9RJWuCf006314
for cs551@merlot.usc.edu; Thu, 27 Oct 2005 12:32:56 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RJWu6q006311
for ; Thu, 27 Oct 2005 12:32:56 -0700
Message-Id: <200510271932.j9RJWu6q006311@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: resetf1
Date: Thu, 27 Oct 2005 12:32:56 -0700
From: william@bourbon.usc.edu
Someone wrote:
> What does the ~/bin/resetf1 command do? Its saying command not found for me.
Oops! Please do:
mkdir ~/bin
cp ~csci551b/bin/resetf1 ~/bin
Here's the content of this file:
#!/usr/bin/csh -f
/bin/rm -rf ~/tmp/final1
mkdir ~/tmp/final1
foreach f (0 1 2 3 4 5 6 7 8 9)
mkdir ~/tmp/final1/n0$f
end
It resets your ~/tmp/final1 directory. As you can see, it
creates all the HomeDirs.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Oct 27 11:10:37 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9RIAbde006162
for ; Thu, 27 Oct 2005 11:10:37 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RI7fSk005325
for ; Thu, 27 Oct 2005 11:07:41 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9RI7fXP005324
for cs551@merlot.usc.edu; Thu, 27 Oct 2005 11:07:41 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9RI7f4Z005321
for ; Thu, 27 Oct 2005 11:07:41 -0700
Message-Id: <200510271807.j9RI7f4Z005321@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Regarding Home Directory in Final project
Date: Thu, 27 Oct 2005 11:07:41 -0700
From: william@bourbon.usc.edu
Someone wrote:
> I am making the homedir if it does not exists. Is that an error?
That would be fine. From the grading guidelines, you can see that
all the HomeDirs are created.
In general, I don't think programatically creating a "top-level"
directory is a good idea and would rather report a missing top-level
directory as a configuration error.
> Also in grading guidelines you have given the distance that we will see in
> join reply. But our port numbers are different. Wudnt the distance be
> different too?
If you implement the calculation of distances correctly, the
numbers will be the same when we use our ports.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Thu Oct 27 07:57:54 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9REvst6001289
for ; Thu, 27 Oct 2005 07:57:54 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9REsw36002935
for ; Thu, 27 Oct 2005 07:54:58 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9REswWP002934
for cs551@merlot.usc.edu; Thu, 27 Oct 2005 07:54:58 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9REswpi002931
for ; Thu, 27 Oct 2005 07:54:58 -0700
Message-Id: <200510271454.j9REswpi002931@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Regarding Home Directory in Final project
Date: Thu, 27 Oct 2005 07:54:58 -0700
From: william@bourbon.usc.edu
Someone wrote:
> Do we need to dyanmically create the directory defined in
> homepath beacuse each node is having different folders to store
> their logfile?
> OR the directory already exists and we just need to create
> logfile in the directory.
I think it's reasonable to assume that if HomeDir does not
exist, it's an error in the startup configure file. So, you
can assume that HomeDir exists. If it doesn't exist, please
make sure you print out an error message before your program
exits.
If you need to create directories inside HomeDir (for part 2),
you can call mkdir() or equivalent.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Oct 26 16:47:23 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9QNlNCv011966
for ; Wed, 26 Oct 2005 16:47:23 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9QNiUIg031075
for ; Wed, 26 Oct 2005 16:44:30 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9QNiUmP031074
for cs551@merlot.usc.edu; Wed, 26 Oct 2005 16:44:30 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9QNiTlH031071
for ; Wed, 26 Oct 2005 16:44:29 -0700
Message-Id: <200510262344.j9QNiTlH031071@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Timout for waiting Status Responses
Date: Wed, 26 Oct 2005 16:44:29 -0700
From: william@bourbon.usc.edu
Someone wrote:
> Which timeout field (i.e JoinTimeout or etc.) should be used for waiting
> status response messages from neighbors?
JoinTimeout should only be used for joins. For status response
messages, you should base it on MsgLifetime because after a
small multiple of MsgLifetime, you can assume that response
messages will not be forward and there would be no point waiting.
--
Bill Cheng // bill.cheng@usc.edu
Return-Path: cs551@bourbon.usc.edu
Delivery-Date: Wed Oct 26 09:52:15 2005
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
by merlot.usc.edu (8.13.1/8.13.1) with ESMTP id j9QGqFjq002209
for ; Wed, 26 Oct 2005 09:52:15 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9QGnN9i026755
for ; Wed, 26 Oct 2005 09:49:23 -0700
Received: (from cs551@localhost)
by bourbon.usc.edu (8.13.1/8.13.1/Submit) id j9QGnNHM026754
for cs551@merlot.usc.edu; Wed, 26 Oct 2005 09:49:23 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
by bourbon.usc.edu (8.13.1/8.13.1) with ESMTP id j9QGnNYU026751
for ; Wed, 26 Oct 2005 09:49:23 -0700
Message-Id: <200510261649.j9QGnNYU026751@bourbon.usc.edu>
To: cs551@bourbon.usc.edu
Subject: Re: Problem with Connect()
Date: Wed, 26 Oct 2005 09:49:23 -0700
From: william@bourbon.usc.edu
Someone wrote:
> i have passed 3 arguments in connect().First one is socket file
> descriptor,secound one is address of variable of type struct
> sockaddr_in and third one is sizeof(that structure variable).So
> its like
>
> struct sockaddr_in server;
> conncet(sockfd,&server,sizeof(server));
That looks right (although I would typecast the 2nd argument
to (struct sockaddr*) so that I won't get a compiler warning).
Well, I would use the same code on a very very small program
(such as warmup #1) and see if the same thing happen. If not,
then you can do the binary search and find out where your
have corrupted memory.
--
Bill Cheng // bill.cheng@usc.edu