Return-Path: william@bourbon.usc.edu Delivery-Date: Fri Aug 12 23:10:17 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j7D6AH3e023078 for ; Fri, 12 Aug 2005 23:10:17 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7D6GfPp005301 for ; Fri, 12 Aug 2005 23:16:41 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j7D6Gf0M005299 for cs551@merlot; Fri, 12 Aug 2005 23:16:41 -0700 Date: Fri, 12 Aug 2005 23:16:41 -0700 From: william@bourbon.usc.edu Message-Id: <200508130616.j7D6Gf0M005299@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: keep a copy of the project specs... Hi, I often got requests for putting a project spec back on the web because someone forgot to make a copy of it and needed it for his/her interviews. I will be deleting the project specs on 8/19/05 (next Fri) and I will not put them back on. If you ask me for it in the future, I will only let you access the current project specs. So, if it's important to you to have a copy of it in the future, please make a copy now. Put it on a CD-R and put it in a safe so you won't ever lose it! Hope you all have a nice break before school starts! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Aug 7 17:09:20 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j7809K3e023741 for ; Sun, 7 Aug 2005 17:09:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j780FuPp026494 for ; Sun, 7 Aug 2005 17:15:56 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j780Fu9c026492 for cs551@merlot.usc.edu; Sun, 7 Aug 2005 17:15:56 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j780FuPp026489 for ; Sun, 7 Aug 2005 17:15:56 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j780FuBD026485 for ; Sun, 7 Aug 2005 17:15:56 -0700 Message-Id: <200508080015.j780FuBD026485@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: confusion regarding guaranteed service Date: Sun, 07 Aug 2005 17:15:56 -0700 From: william@bourbon.usc.edu Someone wrote: > 1. I have a question regarding the guaranteed service. According > to clark's paper, the scheduling algorithm (WFQ in this case) > doesn't have anything to do with packet filtering ( or token > buckets doesn't effect WFQ), yet, guaranteed service can be > happened since we know the upper bound dellay of each flow is > b/r, thus, if an application doesn't aggree with the amount of > delay, it can adjust the rate r. > What I am missing here is no matter how fast the bucket got > filled up, a flow still has to wait for its turn to get serve, > but, how can we just concerning about the rate of token bucket. > How about if you have many guaranteed streams, don't we still > have to wait for the others? (I think I am missing something > here...) If adding a guaranteed flow/stream at a router will make the router not able to give that flow the guarantee it needs, the flow will not be added! > 2. I am curious with mobile ip vs vpn issue. The mobile IP has so > called "triangle" problem, but vpn doesn't really have it, is > this correct? is this because vpn basically is just a tunneling > system that encapsulate our packet in another packet with the new > ip?( I am totally not sure how vpn works though ....) Correct! (And the correct terminology is "triangular routing". -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Aug 5 18:36:44 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j761ai3e012954 for ; Fri, 5 Aug 2005 18:36:44 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j761hQPp007321 for ; Fri, 5 Aug 2005 18:43:26 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j761hQlj007319 for cs551@merlot.usc.edu; Fri, 5 Aug 2005 18:43:26 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j761hPPp007316 for ; Fri, 5 Aug 2005 18:43:25 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j761hP8b007312 for ; Fri, 5 Aug 2005 18:43:25 -0700 Message-Id: <200508060143.j761hP8b007312@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: couple of questions Date: Fri, 05 Aug 2005 18:43:25 -0700 From: william@bourbon.usc.edu Someone wrote: | > > 2. In Dec, you make decision every 2 RTT that means after 2 RTT | > > you will consider the packet filtering scheme (like 50% of | > > packets are marked -> have to drop or whatever ), is this | > > correct? | > | >Have you read the paper? It seems pretty clear that it's | > not about RTT. | | Hmm maybe I am not using the right terminology, I meant | the decision frequence comes after 2RTT(changing window size | not on every ACK but every W+W. That's what I understood | from the lecture and paper..... I am not sure about this, | that's why I am asking you whether I got the correct | understanding or not...... Yes, effectively, it's 2 RTT. But the actual algorithm waits for Wp+Wc packets to be acknowledged. | > > FreeNet question | > > 4. How does store works in freenet system? just like our project | > > does? broadcasting to all the neighbors? I am asking this is | > > because the way search works is by hashing the query and looking | > > at the most adjacent entry with the query's hashing result and | > > foward that packet to that neighbor that occupied that particular | > > entry. In order to make this search feasible, I think when a node | > > want to store a file, it has to broadcast to everyone that it | > > just stored a file with hash result = x. is this correct? | > | > In FreeNet, store is *very similar* to search. So, it | > doesn't use flooding like our final project. (And again, | > flooding is different from broadcasting. Please use the | > correct terminology.) | | But how does a node know that it is at the top of the | "mountain". It doesn't! During store, if enough copies are dropped, then it should not be able to find them during search. | Unlike CHORD, FREENET doesn't seem to hash the | node ip address , so how does it know that it is the right | node to store the file? (did I skip some important part in | the paper ? ) A copy of the file is stored on *every node* during store! Please see slide 20 of lecture 15. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Aug 5 13:53:27 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j75KrR3e032317 for ; Fri, 5 Aug 2005 13:53:27 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75L09Pp005796 for ; Fri, 5 Aug 2005 14:00:09 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j75L09vO005794 for cs551@merlot.usc.edu; Fri, 5 Aug 2005 14:00:09 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75L09Pp005791 for ; Fri, 5 Aug 2005 14:00:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j75L09dv005787 for ; Fri, 5 Aug 2005 14:00:09 -0700 Message-Id: <200508052100.j75L09dv005787@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Final Exam Date and Time Date: Fri, 05 Aug 2005 14:00:09 -0700 From: william@bourbon.usc.edu Someone wrote: > What is the date and time of the final exam? Time time is not posted > on the site. I've mentioned this during the lectures. The last class would be the final exam. So, it will take up the whole class on Monday. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Aug 5 13:50:18 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j75KoI3e032218 for ; Fri, 5 Aug 2005 13:50:18 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75Kv0Pp005669 for ; Fri, 5 Aug 2005 13:57:00 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j75Kv0rv005667 for cs551@merlot.usc.edu; Fri, 5 Aug 2005 13:57:00 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75KuxPp005664 for ; Fri, 5 Aug 2005 13:56:59 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j75KuxaA005660 for ; Fri, 5 Aug 2005 13:56:59 -0700 Message-Id: <200508052056.j75KuxaA005660@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Internet base on peer2peer system Date: Fri, 05 Aug 2005 13:56:59 -0700 From: william@bourbon.usc.edu Someone wrote: > I am curious when you said the peer2peer system might be the > future model of internet, Some people see p2p as a new model for providing new Internet services. > so internet is just delivering > messages, and the application layers will do the rest. Does it > really differ in how internet works nowadays? If you know the IP address, you will still use the Internet to deliver packets. So, there is no difference there. But if all you want is a specific type of service where you don't know the IP address to begin with, then things will be very different. > for example when > you need to request an address of www.usc.edu, you have to go to > the dns server to get the ip address, thus, internet's job is > just relaying packets to destination. Well, maybe the only > difference is just on peer2peer system, we just broadcast a > message to the network who has the ip address of www.usc,edu and > a "dns" node will responds.....is this correct? For DNS service, the major difference would be that you will no longer need to figure out the IP address of your DNS servers. You will just ask the p2p system (in a way that has not been specified yet) to do a lookup for the IP address for www.usc.edu. May be you just need to create a string "DNS:www.usc.edu", take SHA1 hash, and do a p2p lookup. The result you will get would be the IP address(es) of www.usc.edu. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Aug 5 13:39:20 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j75KdK3e031635 for ; Fri, 5 Aug 2005 13:39:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75Kk2Pp005546 for ; Fri, 5 Aug 2005 13:46:02 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j75Kk2iE005544 for cs551@merlot.usc.edu; Fri, 5 Aug 2005 13:46:02 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j75Kk2Pp005541 for ; Fri, 5 Aug 2005 13:46:02 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j75Kk2Uf005537 for ; Fri, 5 Aug 2005 13:46:02 -0700 Message-Id: <200508052046.j75Kk2Uf005537@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: couple of questions Date: Fri, 05 Aug 2005 13:46:02 -0700 From: william@bourbon.usc.edu Someone wrote: > There are couple of questions that I need you to justify them for > me. > DEC & RED questions It's called "DEC-bit". Please remember that in the exams, I can only grade based on what you put down. If your say "DEC" instead of "DEC-bit", I *must not* assume you meant DEC-bit, to be fair to others who may have given correct answers. > 1. unlike fairqueing DEC and RED doesn't really allocate one > buffer per flow. is this right? Right. That's one of their advantages. > 2. In Dec, you make decision every 2 RTT that means after 2 RTT > you will consider the packet filtering scheme (like 50% of > packets are marked -> have to drop or whatever ), is this > correct? Have you read the paper? It seems pretty clear that it's not about RTT. > FreeNet question > 4. How does store works in freenet system? just like our project > does? broadcasting to all the neighbors? I am asking this is > because the way search works is by hashing the query and looking > at the most adjacent entry with the query's hashing result and > foward that packet to that neighbor that occupied that particular > entry. In order to make this search feasible, I think when a node > want to store a file, it has to broadcast to everyone that it > just stored a file with hash result = x. is this correct? In FreeNet, store is *very similar* to search. So, it doesn't use flooding like our final project. (And again, flooding is different from broadcasting. Please use the correct terminology.) Since they are similar, the idea of Hill Climbing should direct both store and search to the right place (hopefully). > 5. This following question is regarding lecture slide # 38 on > freenet. In evicting an entry from fowarding table, when new key > U > v, why do we still want to keep U and evicting v with > probability since it is clear that v is closer to the seed. Because of the Small-world Model. Without long jumps, you will end up with only islands (a disconnected world). > 6. I am confused with the term "playback point" on integrated > service lecture. Is that some kind of point where you want to > start to play the video? Like after 3 seconds you received the > first byte or after 3 first bytes etc? Something like that, but not exactly. Once you start playing the stream, every packet will have a "playback point" which is the time you have to send this packet to hardward (such as an audio or video device). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Aug 4 13:59:31 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j74KxV3e030604 for ; Thu, 4 Aug 2005 13:59:31 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j74L6GPp000839 for ; Thu, 4 Aug 2005 14:06:16 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j74L6G6i000837 for cs551@merlot.usc.edu; Thu, 4 Aug 2005 14:06:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j74L6FPp000834 for ; Thu, 4 Aug 2005 14:06:15 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j74L6Fkj000830 for ; Thu, 4 Aug 2005 14:06:15 -0700 Message-Id: <200508042106.j74L6Fkj000830@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: internet Date: Thu, 04 Aug 2005 14:06:15 -0700 From: william@bourbon.usc.edu Someone wrote: > As we know, internet is just bunch of computers communicating to > each others and providing services and there are routers that > relaying the messages to the end point. I always wondering how do > we connect to the european and asian continent? By satellite or > still by cables? Both. I am pretty sure that there are underwater trans-Atlantic cables. Also, if you go north, some of the continents are not too far apart! > I asked this because internet has been around since 90s..... Well, depend on what you call the Internet. One definition of Internet is the network reachable via IP (Internet Protocol). I think this is the right definition. This has been around since the old DARPANET days (late 60s, early 70s). The old Internet went commercial in 1994/1995. (This means that any one can own and operate part of the Internet.) Some people call the commercialized Internet the Internet. But I think this is a silly definition. Before someone sold the first piece of Operating System, did application software run on top of something else? -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 21:25:39 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j744Pd3e010369 for ; Wed, 3 Aug 2005 21:25:39 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j744WPPp024471 for ; Wed, 3 Aug 2005 21:32:25 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j744WP0C024469 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 21:32:25 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j744WPPp024466 for ; Wed, 3 Aug 2005 21:32:25 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j744WPti024462 for ; Wed, 3 Aug 2005 21:32:25 -0700 Message-Id: <200508040432.j744WPti024462@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: delete Date: Wed, 03 Aug 2005 21:32:25 -0700 From: william@bourbon.usc.edu Someone wrote: > I am a little bit confuse on how verify works. If we called popen > to execute verify -noverify ... , will we get a file if the > verification unsuccessfull? or a nullpointer? > Because it kept return me not null when the file existed (the > file that we want to verify ), even though I used different > key.... Have you tried the code in the Notes on Invoking popen() section of the project spec? You are suppose to look for the "Verification Successful" string when you read the pipe returned by popen(). Of course the sample code there doesn't have all the right stuff, but you are suppose to figure out what to do from there. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 21:23:06 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j744N63e010270 for ; Wed, 3 Aug 2005 21:23:06 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j744TqPp024430 for ; Wed, 3 Aug 2005 21:29:52 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j744TqrW024428 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 21:29:52 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j744TqPp024425 for ; Wed, 3 Aug 2005 21:29:52 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j744Tqls024421 for ; Wed, 3 Aug 2005 21:29:52 -0700 Message-Id: <200508040429.j744Tqls024421@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: UOID Space Date: Wed, 03 Aug 2005 21:29:52 -0700 From: william@bourbon.usc.edu Someone wrote: > The TA said that we should have the whole metadata in our log > file (in case for status response). Hmm... I don't remember seeing this message from the TA. I probably missed it. > I re-read the updated specs > and browse your archive messaages regarding the new updates on > file status response, but I couldn't find the specific section > that said we have to give metadata in our log file... > Please confirm.. The spec is very clear about this. If you look at the Logging section of the spec, it says that for STRS, the only thing that goes into the portion of the log record is the UOID of the corresponding STRQ. The file metadata was suppose to go to . -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 18:00:58 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j7410w3e000660 for ; Wed, 3 Aug 2005 18:00:58 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7417iPp023801 for ; Wed, 3 Aug 2005 18:07:44 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j7417irQ023799 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 18:07:44 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7417iPp023796 for ; Wed, 3 Aug 2005 18:07:44 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j7417ij7023792 for ; Wed, 3 Aug 2005 18:07:44 -0700 Message-Id: <200508040107.j7417ij7023792@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: UOID Space Date: Wed, 03 Aug 2005 18:07:44 -0700 From: william@bourbon.usc.edu Someone wrote: > I have been running a 2 beacon 4 non-beacon network. > A problem I face is that duplicate UOID "00000000" is seen in the log file(2 > diff messages with the same UOID showing all zeros). This confuses the nodes > leading to incorrect behavior. > > Could there be something wrong with my implementation, or is the UOID > regeneration normal? If you implement the GetUOID() function correctly, the probability that the last 4 bytes of an UOID are all zero should be 2 to the power of -32, extremely unlikely. You should go into the debugger and debug your GetUOID() function. If it's doing the right thing, you must have lost those bytes somewhere when you copy the UOID. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 17:57:31 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j740vV3e000448 for ; Wed, 3 Aug 2005 17:57:31 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7414IPp023765 for ; Wed, 3 Aug 2005 18:04:18 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j7414IgI023763 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 18:04:18 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7414HPp023760 for ; Wed, 3 Aug 2005 18:04:17 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j7414HXf023756 for ; Wed, 3 Aug 2005 18:04:17 -0700 Message-Id: <200508040104.j7414HXf023756@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Certificate and Store Message Date: Wed, 03 Aug 2005 18:04:17 -0700 From: william@bourbon.usc.edu Someone wrote: > Just to clarify, it's not the first 3 lines since it has the signed > header, right? I'm not sure. You should be able to figure this out. I think it's like I said, "first 3 lines that has a equal sign in them". -- Bill Cheng // bill.cheng@usc.edu On 8/3/05, william@bourbon.usc.edu wrote: > Someone wrote: > > > When a digitally signed spec in a delete message is sent to a node, > > that node must parse the file spec for the FileName, SHA1, and Nonce > > in the signed file spec to detemine which certificate to use to verify > > it, right? > > Yes. But it's trivial "parsing". Just read the first 3 > lines of the Digitally Signed File Spec that has a equal > sign in them. > -- > Bill Cheng // bill.cheng@usc.edu > > > > > On 8/3/05, william@bourbon.usc.edu wrote: > > Someone wrote: > > > > > When a store message is sent, the certificate of the sending node is > > > sent along with the message. Where do we keep this certificate on the > > > receiving node since it's not part of the meta data? When a node goes > > > down, don't we have to reassociate the file with the certificate of > > > the owner node? > > > > If your node will save the file data as "37.dat" and file > > metadata as "37.meta", one simple solution is to save the > > certificate as "37.cert". > > -- > > Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 14:22:45 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j73LMj3e022949 for ; Wed, 3 Aug 2005 14:22:45 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73LTWPp022705 for ; Wed, 3 Aug 2005 14:29:32 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j73LTWc6022703 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 14:29:32 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73LTWPp022700 for ; Wed, 3 Aug 2005 14:29:32 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j73LTW6A022696 for ; Wed, 3 Aug 2005 14:29:32 -0700 Message-Id: <200508032129.j73LTW6A022696@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Odd Error Date: Wed, 03 Aug 2005 14:29:32 -0700 From: william@bourbon.usc.edu Someone wrote: > It is on warm restart... but when number of beacons are > 1 there is no > error... that's why I am confused as to where the problem arises... also I > am unable to write to files as well... > > Is there anyway that I can reset STDIO so that I can write to files / stdout > again? Memory corruption bugs manifest themselves in various ways. This is certainly a possibility. Unfortunately, the only solution I know of is to do a binary search. First, you comment out enough code so that your code would work. Then you start the binary search by uncommenting half of your code at a time until you find your bug. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu] Sent: Wednesday, August 03, 2005 11:52 AM To: cs551@bourbon.usc.edu Subject: Re: Odd Error Someone wrote: > I am stuck at this odd error: Heres the situation: > > For 2 or more beacons, the check message and restart works file. > > For 1 beacon network with init neighbors=1: > After Restart: > Messages are sent to and from the restarted node but there is no logging at > the restarted node (But messages to and from this node are logged correctly > at other nodes). > Also the stdout fails to display anything. > > In short I loose the ability to write to any output devices (screen or > logs). > > And oddly enough this is not the case when init neighbors>1 > > Any idea as to what may be wrong? When you said "restart", do you mean "warm start" or "cold start"? "Cold start" means you actually exit your program and restart it manually. "Warm start" means that you just go to the beginning of main() without exiting your program. If it's warm start, I would again think it's the good old problem of memory corruption (just like a memory allocation bug). If it's cold start, then it's just a really weird bug! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 14:20:17 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j73LKH3e022845 for ; Wed, 3 Aug 2005 14:20:17 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73LR4Pp022684 for ; Wed, 3 Aug 2005 14:27:04 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j73LR448022682 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 14:27:04 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73LR4Pp022679 for ; Wed, 3 Aug 2005 14:27:04 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j73LR4In022675 for ; Wed, 3 Aug 2005 14:27:04 -0700 Message-Id: <200508032127.j73LR4In022675@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Certificate and Store Message Date: Wed, 03 Aug 2005 14:27:04 -0700 From: william@bourbon.usc.edu Someone wrote: > When a digitally signed spec in a delete message is sent to a node, > that node must parse the file spec for the FileName, SHA1, and Nonce > in the signed file spec to detemine which certificate to use to verify > it, right? Yes. But it's trivial "parsing". Just read the first 3 lines of the Digitally Signed File Spec that has a equal sign in them. -- Bill Cheng // bill.cheng@usc.edu On 8/3/05, william@bourbon.usc.edu wrote: > Someone wrote: > > > When a store message is sent, the certificate of the sending node is > > sent along with the message. Where do we keep this certificate on the > > receiving node since it's not part of the meta data? When a node goes > > down, don't we have to reassociate the file with the certificate of > > the owner node? > > If your node will save the file data as "37.dat" and file > metadata as "37.meta", one simple solution is to save the > certificate as "37.cert". > -- > Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 12:14:21 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j73JEL3e016974 for ; Wed, 3 Aug 2005 12:14:21 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73JL8Pp021596 for ; Wed, 3 Aug 2005 12:21:08 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j73JL8Ze021594 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 12:21:08 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73JL8Pp021591 for ; Wed, 3 Aug 2005 12:21:08 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j73JL8QE021587 for ; Wed, 3 Aug 2005 12:21:08 -0700 Message-Id: <200508031921.j73JL8QE021587@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Certificate and Store Message Date: Wed, 03 Aug 2005 12:21:08 -0700 From: william@bourbon.usc.edu Someone wrote: > When a store message is sent, the certificate of the sending node is > sent along with the message. Where do we keep this certificate on the > receiving node since it's not part of the meta data? When a node goes > down, don't we have to reassociate the file with the certificate of > the owner node? If your node will save the file data as "37.dat" and file metadata as "37.meta", one simple solution is to save the certificate as "37.cert". -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Aug 3 11:50:44 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j73Ioi3e015338 for ; Wed, 3 Aug 2005 11:50:44 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73IqAPp021379 for ; Wed, 3 Aug 2005 11:52:10 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j73Iq9TD021377 for cs551@merlot.usc.edu; Wed, 3 Aug 2005 11:52:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j73Iq9Pp021374 for ; Wed, 3 Aug 2005 11:52:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j73Iq9n6021370 for ; Wed, 3 Aug 2005 11:52:09 -0700 Message-Id: <200508031852.j73Iq9n6021370@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Odd Error Date: Wed, 03 Aug 2005 11:52:09 -0700 From: william@bourbon.usc.edu Someone wrote: > I am stuck at this odd error: Heres the situation: > > For 2 or more beacons, the check message and restart works file. > > For 1 beacon network with init neighbors=1: > After Restart: > Messages are sent to and from the restarted node but there is no logging at > the restarted node (But messages to and from this node are logged correctly > at other nodes). > Also the stdout fails to display anything. > > In short I loose the ability to write to any output devices (screen or > logs). > > And oddly enough this is not the case when init neighbors>1 > > Any idea as to what may be wrong? When you said "restart", do you mean "warm start" or "cold start"? "Cold start" means you actually exit your program and restart it manually. "Warm start" means that you just go to the beginning of main() without exiting your program. If it's warm start, I would again think it's the good old problem of memory corruption (just like a memory allocation bug). If it's cold start, then it's just a really weird bug! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Aug 2 21:09:42 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j7349g3e005843 for ; Tue, 2 Aug 2005 21:09:42 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j734B9Pp017866 for ; Tue, 2 Aug 2005 21:11:09 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j734B9js017864 for cs551@merlot.usc.edu; Tue, 2 Aug 2005 21:11:09 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j734B9Pp017861 for ; Tue, 2 Aug 2005 21:11:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j734B9oD017857 for ; Tue, 2 Aug 2005 21:11:09 -0700 Message-Id: <200508030411.j734B9oD017857@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: uoid of flooing message Date: Tue, 02 Aug 2005 21:11:09 -0700 From: william@bourbon.usc.edu Someone wrote: > Let's assume the following: > > Node A, node B and node C are fully connected. > Node A sends(floods) status reqeust message to node B and node C. > > When the node A sends(floods) status request message to node B and node C, > are the uoid of messages same or different? Same. Because they are the *same message*. Node A creates a single message and this message is duplicated in all out-going links from A. > If they are different, each message would be forwarded to its neighbor node > and each node would reply two times. > For example, node B would forward the received message, which is come from > node A, to the node C. > And, node C would forward the received message, which is come from node A, > to the node B. > Since each message's uoid is different, each node would send the status > response message twice. > > If they are same, each node would reply only once. However, the spce says > the uoid of a message is unique. There is only one request message; therefore, there is only one UOID for the message. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Aug 2 11:23:29 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j72INT3e011102 for ; Tue, 2 Aug 2005 11:23:29 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j72IOvPp014289 for ; Tue, 2 Aug 2005 11:24:57 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j72IOvFb014287 for cs551@merlot.usc.edu; Tue, 2 Aug 2005 11:24:57 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j72IOvPp014284 for ; Tue, 2 Aug 2005 11:24:57 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j72IOvp3014280 for ; Tue, 2 Aug 2005 11:24:57 -0700 Message-Id: <200508021824.j72IOvp3014280@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: FileID / Nonce Date: Tue, 02 Aug 2005 11:24:57 -0700 From: william@bourbon.usc.edu Someone wrote: > I see. And a nonce is used to distinguish identical files which > happen to be on different nodes before it gets inserted into the > Servant network? Yes. The reason for a nonce is to mitigate "replay attacks". Here is the scenario. File X is stored by the user at node A. Then X is deleted by the user at node A. Then X is again stored by the user at node A. Now anyone who has a copy of the delete message and flood it back to the network and delete all copies of X. -- Bill Cheng // bill.cheng@usc.edu On 8/2/05, william@bourbon.usc.edu wrote: > Someone wrote: > > > I'm still unclear as how to use the FileID / Nonce value. Just some > > yes/no clarifications with some elaborations on "no" will do. > > > > So everytime a store is sent, the receiving node will generate a new > > Nonce value for that file, and replace the nonce sent by the > > originating node, right? > > No. A nonce is part of file metadata. It is created when a > file is first introduced into the SERVANT network via a > "store" user command. It never changes. > > > When a search response is generated, you send the nonce that you have > > for that file (which can be different for the same file on different > > nodes) and record it in an index table so that some can "GET" a > > particular file by that Nonce, right? > > No. That's what a FileID is for. > > Let's put it this way... In the servant network, file Y is > a copy of file X if X and Y have identical FileName, SHA1, > and Nonce (everything else about X and Y should also be the > same). How does Y comes to existance? Well, when X was > first introduced into the SERVANT network via a "store" user > command, copies of X got probabilistically flooded into the > rest of the SERVANT network. So copies of X can be created. > Later on, when some node retrieves X or a copy of X, another > copy of X gets probabilistically flooded into the network, > so more copies of X can get created. So, if X is a very > popular search target, there can be many many copies of X > in the entire network. Now, if you search of X and get > many responses, and you only want one copy of X to be sent > to you, how do you only ask for one copy of X to be sent to > you? (This is kind of like the "anycast" I've mentioned in > class.) This is where FileID comes in. > > A FileID distinguishes one copy of X from another copy of X. > -- > Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Aug 2 10:57:27 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j72HvR3e009763 for ; Tue, 2 Aug 2005 10:57:27 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j72HwuPp014129 for ; Tue, 2 Aug 2005 10:58:56 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j72HwuZo014127 for cs551@merlot.usc.edu; Tue, 2 Aug 2005 10:58:56 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j72HwtPp014124 for ; Tue, 2 Aug 2005 10:58:55 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j72HwtX7014120 for ; Tue, 2 Aug 2005 10:58:55 -0700 Message-Id: <200508021758.j72HwtX7014120@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: FileID / Nonce Date: Tue, 02 Aug 2005 10:58:55 -0700 From: william@bourbon.usc.edu Someone wrote: > I'm still unclear as how to use the FileID / Nonce value. Just some > yes/no clarifications with some elaborations on "no" will do. > > So everytime a store is sent, the receiving node will generate a new > Nonce value for that file, and replace the nonce sent by the > originating node, right? No. A nonce is part of file metadata. It is created when a file is first introduced into the SERVANT network via a "store" user command. It never changes. > When a search response is generated, you send the nonce that you have > for that file (which can be different for the same file on different > nodes) and record it in an index table so that some can "GET" a > particular file by that Nonce, right? No. That's what a FileID is for. Let's put it this way... In the servant network, file Y is a copy of file X if X and Y have identical FileName, SHA1, and Nonce (everything else about X and Y should also be the same). How does Y comes to existance? Well, when X was first introduced into the SERVANT network via a "store" user command, copies of X got probabilistically flooded into the rest of the SERVANT network. So copies of X can be created. Later on, when some node retrieves X or a copy of X, another copy of X gets probabilistically flooded into the network, so more copies of X can get created. So, if X is a very popular search target, there can be many many copies of X in the entire network. Now, if you search of X and get many responses, and you only want one copy of X to be sent to you, how do you only ask for one copy of X to be sent to you? (This is kind of like the "anycast" I've mentioned in class.) This is where FileID comes in. A FileID distinguishes one copy of X from another copy of X. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Aug 1 12:40:00 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j71Je03e009058 for ; Mon, 1 Aug 2005 12:40:00 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71JfVPp005955 for ; Mon, 1 Aug 2005 12:41:31 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j71JfVCL005953 for cs551@merlot.usc.edu; Mon, 1 Aug 2005 12:41:31 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71JfUPp005950 for ; Mon, 1 Aug 2005 12:41:30 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j71JfUMH005946 for ; Mon, 1 Aug 2005 12:41:30 -0700 Message-Id: <200508011941.j71JfUMH005946@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get command Date: Mon, 01 Aug 2005 12:41:30 -0700 From: william@bourbon.usc.edu Someone wrote: > So are you saying that if a user does a 'get' command for abc.pdf, the > program should store it as *.data in the [HomeDir]/files directory as well > as storing it as abc.pdf in the current directory? And if the program is > running from a write-protected directory like /usr/bin, it should ask the > user where to store the file? No. Just store it in the current working directory. If the current working directory is not writable or the file system is full, you just need to tell you that you cannot create "abc.pdf" in the current working directory. > One quick question, it is the user's responsibility to specify a HomeDir > that is write-enabled right? or does the program have to do checking for > this as well? If HomeDir is not writable by your program, it's not very useful. And you should always check return code from all system calls anyways. So, if HomeDir is not writable, you code should still work properly (although not very useful). Also, HomeDir can have a lot of files! If you don't copy the get target to the current working directory, the user may not know which file to view. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Aug 1 12:28:19 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j71JSJ3e008554 for ; Mon, 1 Aug 2005 12:28:19 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71JToPp005893 for ; Mon, 1 Aug 2005 12:29:50 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j71JTodM005891 for cs551@merlot.usc.edu; Mon, 1 Aug 2005 12:29:50 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71JToPp005888 for ; Mon, 1 Aug 2005 12:29:50 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j71JToEJ005884 for ; Mon, 1 Aug 2005 12:29:50 -0700 Message-Id: <200508011929.j71JToEJ005884@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get command Date: Mon, 01 Aug 2005 12:29:50 -0700 From: william@bourbon.usc.edu Someone wrote: > So If I understand correctly: > > When we make a "get request" for x.pdf, we store two copies.... > 1. In the file system as say 8.data / 8.meta / 8.cert > 2. in the cwd as x.pdf Correct. > My question is does x.pdf count as a part of permanent memory? It does not count as any storage because it's outside HomeDir! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Aug 1 09:48:39 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j71Gmd3e001047 for ; Mon, 1 Aug 2005 09:48:39 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71GoAPp004804 for ; Mon, 1 Aug 2005 09:50:10 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j71GoAKs004802 for cs551@merlot.usc.edu; Mon, 1 Aug 2005 09:50:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71Go9Pp004799 for ; Mon, 1 Aug 2005 09:50:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j71Go9VB004795 for ; Mon, 1 Aug 2005 09:50:09 -0700 Message-Id: <200508011650.j71Go9VB004795@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get command Date: Mon, 01 Aug 2005 09:50:09 -0700 From: william@bourbon.usc.edu Someone wrote: | I didn't quite understand what you meant by this comment... | | > You also need to "download" the file to the current working | > directory and save it using the FileName of the file. This | > is just like the case when you use google. (Alternatively, | > you can ask the user what name to use.) You should do the | > usual thing such as if the named file already exists in the | > current directory, you should ask the user if he/she wants | > to replace the existing file. | | I thought the only *writing* of data we do is into *.data files. | Why would we need to "download" the file into the current working | directory (which may not be the HomeDir) using the FileName? | | As far as if a file already exists in the permanent memory and a | get request is made on that file, then it is ok to just leave the | file as it is and do nothing, right? it's not necessary to ask | the user if he/she wants to replace the existing file, right? >From the perspective of your user, who has just entered a "get" command, say to retrieve a PDF file, you need to provide easy access to the file just gotten. Also consider the case where your node is installed in /usr/bin by root and the mini-filesystem is protected from a regular user. How would your user use your system? -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Aug 1 08:01:10 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j71F1A3e028570 for ; Mon, 1 Aug 2005 08:01:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71F2fPp004360 for ; Mon, 1 Aug 2005 08:02:41 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j71F2fcl004358 for cs551@merlot.usc.edu; Mon, 1 Aug 2005 08:02:41 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71F2fPp004355 for ; Mon, 1 Aug 2005 08:02:41 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j71F2frS004351 for ; Mon, 1 Aug 2005 08:02:41 -0700 Message-Id: <200508011502.j71F2frS004351@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: search command Date: Mon, 01 Aug 2005 08:02:41 -0700 From: william@bourbon.usc.edu Someone wrote: > When a user inputs search command, the local node also runs search command? Of course! Think about the case where this is deployed and you have a user sitting in front of the commandline interface and entered a search. Even this is the only user that has ever used this node, it's unlikely that the user would remember every file he/she has ever stored and retrieved. > As you mentioned before, it seems that the result for local search also > should be displayed. Yes. > However, if a user inputs get command for the local file, what should we do? > If the file is in the cache area, the node can move it to the permanant > area. Yes. > But, if the file is already in the permanant area, does a node make a > duplicate file? It would be fine although it's not necessary. You also need to "download" the file to the current working directory and save it using the FileName of the file. This is just like the case when you use google. (Alternatively, you can ask the user what name to use.) You should do the usual thing such as if the named file already exists in the current directory, you should ask the user if he/she wants to replace the existing file. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Aug 1 07:53:12 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j71ErC3e028181 for ; Mon, 1 Aug 2005 07:53:12 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71EshPp004322 for ; Mon, 1 Aug 2005 07:54:43 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j71EshuT004320 for cs551@merlot.usc.edu; Mon, 1 Aug 2005 07:54:43 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j71EshPp004317 for ; Mon, 1 Aug 2005 07:54:43 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j71EshIT004312 for ; Mon, 1 Aug 2005 07:54:43 -0700 Message-Id: <200508011454.j71EshIT004312@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: ignore my prev email regarding delete Date: Mon, 01 Aug 2005 07:54:43 -0700 From: william@bourbon.usc.edu Someone wrote: > In the specs it said , we have to convert binary file to ascii > when we want to use openssl. > > 1. what will happened if we encode textfile to ASCII? will it > generate error since a text file already written in ASCII? Since the File Spec is already in ASCII, there is no need to convert it. (The comment in the Certification section of the spec was meant for general information.) If you try to base64 encode it, openssl will not complain because it would be a legitimate operation. But this would violate the spec and break interoperability. > 2. is there anytime that we really need to concern about this > binary file matter? I asked this because, cert.pem and > private.pem, doesn't really have anything to do with any of the > data/meta files ( we just generate once when a node comes up if > those file didn't exist). For digitally signed file, we signed > the specs. So there is no concert about binary files ,isn't > right? This only thing we need to sign in this project is the File Spec. Since File Spec is already in ASCII, we never need to encode. In general, if you want to sign a piece of binary data, and you want to use the "openssl smime -sign ..." command shown in the spec, you *must* convert the binary data to ASCII. This is simply because the above command only works for ASCII input. I think you can run openssl in some other ways to sign binary data, but I don't know the syntax. If someone has found out how, please let me know. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 31 23:21:11 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j716LB3e004205 for ; Sun, 31 Jul 2005 23:21:11 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j716MhPp002410 for ; Sun, 31 Jul 2005 23:22:43 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j716MhXN002408 for cs551@merlot.usc.edu; Sun, 31 Jul 2005 23:22:43 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j716MhPp002405 for ; Sun, 31 Jul 2005 23:22:43 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j716Mh2t002401 for ; Sun, 31 Jul 2005 23:22:43 -0700 Message-Id: <200508010622.j716Mh2t002401@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: ignore my prev email regarding delete Date: Sun, 31 Jul 2005 23:22:43 -0700 From: william@bourbon.usc.edu Someone wrote: > I think I know how to do delete now. But there's still some > problems. > > 1. if we have 4 certificate in our filesystem, do we map one by > one until we find the correct one? I am trying to store an > information like a node identifier and its certificate, but I > don't think this is supported in our specs. For instance, in > store message (this is the first time we see the certificate), we > don't really know from whom is the message, all we know it came > from our immidiate neighbor......any hints?? But you should have the certificate for the file when you store the file. Let's say you want to delete file X. You create the File Spec in /tmp, digitally signs it, and include the Digitally Signed File Spec in your delete message an flood it throughout the network. The Digitally Signed File Spec has two parts. First is the File Spec, which gives detailed information about file X. The 2nd part is the digital signature, which looks like a bunch of random data (but of course it's not). Both parts are ASCII, so your code should be able to parse a Digitally Signed File Spec easily. WHen a node receives a delete message for file X, first it should read the first part of the Digitally Signed File Spec, search the mini-filesystem using either the filename or SHA1 hash for file X to see if it has such a file. If it does, it should be able to easily locate the certificate for the file (if the file is 5.data, the certificate is 5.cert). Then it can feed the *whole Digitally Signed File Spec*, along with the name of the certificate file, to the verification routine see if the message is signed by the creator of the file. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 31 23:08:06 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j716863e003620 for ; Sun, 31 Jul 2005 23:08:06 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7169cPp002329 for ; Sun, 31 Jul 2005 23:09:38 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j7169cG5002327 for cs551@merlot.usc.edu; Sun, 31 Jul 2005 23:09:38 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j7169cPp002324 for ; Sun, 31 Jul 2005 23:09:38 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j7169cZ7002320 for ; Sun, 31 Jul 2005 23:09:38 -0700 Message-Id: <200508010609.j7169cZ7002320@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: delete Date: Sun, 31 Jul 2005 23:09:38 -0700 From: william@bourbon.usc.edu Someone wrote: > I am confused regarding this delete business. > > 1. which file is suppose to be digitally signed? If you look at the message format, the only thing in a delete message that's not part of the common message header is the Digitally Signed File Spec where a File Spec is 3 lines long and it specifies information about a file to delete. > as I understood from the specs, we have to create another file > called "filespec" and digitally sign this file. Correct. > Then after that > call verify() to verify a digitally signed file. Here's my > interpretation : signed 2 files -> file spec and filedata(n.data > or do we have to sign a metadata here??), say it will generate 2 > digitally signed file namely bar1, bar2. Then verify bar1 with > bar2? You only need to sign the File Spec. For file X, you can create the Digitally Signed File Spec for X when you store X. Or, when the user requests to delete X, you can dynamically create the File Spec (say in /tmp) and then digitally sign it. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 30 21:04:06 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6V4463e017883 for ; Sat, 30 Jul 2005 21:04:06 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6V45fPp019256 for ; Sat, 30 Jul 2005 21:05:41 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6V45f0g019254 for cs551@merlot.usc.edu; Sat, 30 Jul 2005 21:05:41 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6V45fPp019251 for ; Sat, 30 Jul 2005 21:05:41 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6V45fsZ019247 for ; Sat, 30 Jul 2005 21:05:41 -0700 Message-Id: <200507310405.j6V45fsZ019247@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Last minute questions Date: Sat, 30 Jul 2005 21:05:41 -0700 From: william@bourbon.usc.edu Someone wrote: > Hi, i was writing up the report for the final project, and have a couple > of last minute questions about the 'get' command. > > Say node A has a copy of a file in its cache and node B has the same file > in its permament memory. Now if node A issues a 'search' command, it will > display two options to the user (one for each copy of the file on A and > B). If the user on A does a 'get' on either option, node A will recognize > that the file being requested is a duplicate of the one already present in > its cache. The question is, should node A remove the file from its cache > and place it in its permanent memory? Or should it just do nothing, > leaving the file in the cache and not modifying the permanent memory? It *must* move the file to permanent storage. This is because the spec requires that once you've done a GET, the file should no longer be subject LRU, no matter where this file use to be. If you only use a bit to indicate if a file is in the cache or permanent storage, then all you have to do is to flip the bit. -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Sat Jul 30 21:01:33 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6V41X3e017698 for ; Sat, 30 Jul 2005 21:01:33 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6V437Pp019238 for ; Sat, 30 Jul 2005 21:03:07 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6V437iu019236 for cs551@merlot; Sat, 30 Jul 2005 21:03:07 -0700 Date: Sat, 30 Jul 2005 21:03:07 -0700 From: william@bourbon.usc.edu Message-Id: <200507310403.j6V437iu019236@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: reminder... project part (2) deadline extension... Just want to make sure you all realize that the extended deadline for final project part (2) is 11:45pm this coming Wednesday, 8/3/2005. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 30 20:53:25 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6V3rP3e017312 for ; Sat, 30 Jul 2005 20:53:25 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6V3t0Pp019193 for ; Sat, 30 Jul 2005 20:55:00 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6V3t0hk019191 for cs551@merlot.usc.edu; Sat, 30 Jul 2005 20:55:00 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6V3t0Pp019188 for ; Sat, 30 Jul 2005 20:55:00 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6V3t0qW019184 for ; Sat, 30 Jul 2005 20:55:00 -0700 Message-Id: <200507310355.j6V3t0qW019184@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: p2p communication behind NAT Date: Sat, 30 Jul 2005 20:55:00 -0700 From: william@bourbon.usc.edu Someone wrote: > There are many kind of p2p software such as e-donkey. > In our project, if two node are behind NAT and both of them use private IP > address, they cannot communicate each other. > (Of course, if they are in the same network, they can connect.) > > Therefore, at least one node should have public IP address, so the other > node can connect to it and can send data through it. > As you mentioned before, the centralized apporoach has some problem. > I'd like to know whether they can connect to each other in the NAT > environment without central server. There are ways to get around the problem, but they are all kludges. For example, most routers that support NAT allow you to say that if an outsider tries to connect to a paricular part, connect it to a particular machine inside the private network. This works, if the application always use the same port. (For our class project, a node can use any port, so one must manually configure the router if a different port is used.) Another example is to use a proxy (or a reflector) in the public Internet. This proxy can run over port 80, serve many nodes, and there can be many such proxies. So, it's not really a "centralized" approach. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 30 09:14:54 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6UGEs3e017191 for ; Sat, 30 Jul 2005 09:14:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6UGGUPp017551 for ; Sat, 30 Jul 2005 09:16:30 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6UGGUYC017549 for cs551@merlot.usc.edu; Sat, 30 Jul 2005 09:16:30 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6UGGUPp017546 for ; Sat, 30 Jul 2005 09:16:30 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6UGGUJ1017542 for ; Sat, 30 Jul 2005 09:16:30 -0700 Message-Id: <200507301616.j6UGGUJ1017542@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: store command Date: Sat, 30 Jul 2005 09:16:30 -0700 From: william@bourbon.usc.edu Someone wrote: > Thanks Prof, you make my cloudy mind clear now! :) I'm glad! :-) > I am like working in a never ending project...... Well... the point is to have learned something valuable! :-) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 30 00:16:16 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6U7GG3e022090 for ; Sat, 30 Jul 2005 00:16:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U7HrPp015818 for ; Sat, 30 Jul 2005 00:17:53 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6U7HrrE015816 for cs551@merlot.usc.edu; Sat, 30 Jul 2005 00:17:53 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U7HrPp015813 for ; Sat, 30 Jul 2005 00:17:53 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6U7HqrF015809 for ; Sat, 30 Jul 2005 00:17:53 -0700 Message-Id: <200507300717.j6U7HqrF015809@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: store command Date: Sat, 30 Jul 2005 00:17:52 -0700 From: william@bourbon.usc.edu Someone wrote: > I just re-read the specs and noticed that there're quotation > marks in the keywords tag : > tag1="value1" and etc > > When we map the keywords to the bit-vector , do we include > the quotation mark also? for instance "world of computers" > instead of world of computers? It should be clear from the Keywords= example in: http://merlot.usc.edu/cs551-m05/projects/final.html#metadata that you must remove the quotation marks (replace them with space characters first so you can detect work boundaries). -- Bill Cheng // bill.cheng@usc.edu ----- Original Message ----- From: william@bourbon.usc.edu Date: Friday, July 29, 2005 11:11 pm Subject: Re: store command > Someone wrote: > > > In the spec, the store command is the following: > > > > store foo [tag1="value1" tag2="value2" ...]. > > > > Generally, the < > means a required option and the [ ] means > optional > option. > > Does this rule apply for the store command, too? > > That is, the is a required option and the [tag1= ...] is > optional? > Yes. > -- > Bill Cheng // bill.cheng@usc.edu > Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 29 23:15:05 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6F53e018552 for ; Fri, 29 Jul 2005 23:15:05 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6GhPp015519 for ; Fri, 29 Jul 2005 23:16:43 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6U6Ghrm015517 for cs551@merlot.usc.edu; Fri, 29 Jul 2005 23:16:43 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6GgPp015514 for ; Fri, 29 Jul 2005 23:16:42 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6U6Gg5R015510 for ; Fri, 29 Jul 2005 23:16:42 -0700 Message-Id: <200507300616.j6U6Gg5R015510@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: EFence Date: Fri, 29 Jul 2005 23:16:42 -0700 From: william@bourbon.usc.edu Someone wrote: > I was trying to use Efence cause i have time to investigate one or two seg > faults i am getting. Could you make the directory public so that i can > access the efence lib file and readme as well. Hmm... I thought I've done that before but apparently the files are not world-readable. Sorry. I've just changed their permissions. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 29 23:10:15 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6AF3e018367 for ; Fri, 29 Jul 2005 23:10:15 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6BqPp015444 for ; Fri, 29 Jul 2005 23:11:52 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6U6BqA5015442 for cs551@merlot.usc.edu; Fri, 29 Jul 2005 23:11:52 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6U6BqPp015439 for ; Fri, 29 Jul 2005 23:11:52 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6U6Bqaj015435 for ; Fri, 29 Jul 2005 23:11:52 -0700 Message-Id: <200507300611.j6U6Bqaj015435@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: store command Date: Fri, 29 Jul 2005 23:11:52 -0700 From: william@bourbon.usc.edu Someone wrote: > In the spec, the store command is the following: > > store foo [tag1="value1" tag2="value2" ...]. > > Generally, the < > means a required option and the [ ] means optional > option. > Does this rule apply for the store command, too? > That is, the is a required option and the [tag1= ...] is optional? Yes. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 29 16:18:29 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNIT3e031684 for ; Fri, 29 Jul 2005 16:18:29 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNK7Pp014035 for ; Fri, 29 Jul 2005 16:20:07 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6TNK7ji014033 for cs551@merlot.usc.edu; Fri, 29 Jul 2005 16:20:07 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNK7Pp014030 for ; Fri, 29 Jul 2005 16:20:07 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6TNK77s014026 for ; Fri, 29 Jul 2005 16:20:07 -0700 Message-Id: <200507292320.j6TNK77s014026@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Testing on large networks Date: Fri, 29 Jul 2005 16:20:07 -0700 From: william@bourbon.usc.edu Someone wrote: > I tested my program with the test data and with networks of a reasonable > size and it worked fine. Then i tested it on a network with a lot of nodes > (10 or more). All the commands and messages seemed to work fine except for > the delete command. I kept getting an error saying "bash: fork: Resource > temporarily unavailable" on some of the nodes. This in turn led to > segmentation faults on some of the nodes. > > Now i assume it's because the delete command uses popen() to verify the > certificate, and since popen is an expensive operation and there are 10 or > more of these going on simultaneously on nunki under my account, it's too > much to handle. I don't know how to fix this other than to not use popen() > and not fork a new process to verify the certificate. > > Will this be taken into account when grading? Well, *if* this is turns out to be a problem with popen(), then everyone will see the same problem. So, it will be taken into account when grading but the net grading effect would be null. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 29 16:11:51 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNBp3e031327 for ; Fri, 29 Jul 2005 16:11:51 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNDTPp013992 for ; Fri, 29 Jul 2005 16:13:29 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6TNDTHc013990 for cs551@merlot.usc.edu; Fri, 29 Jul 2005 16:13:29 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNDSPp013987 for ; Fri, 29 Jul 2005 16:13:29 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6TNDSD2013983 for ; Fri, 29 Jul 2005 16:13:28 -0700 Message-Id: <200507292313.j6TNDSD2013983@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: status files Date: Fri, 29 Jul 2005 16:13:28 -0700 From: william@bourbon.usc.edu Someone wrote: > I am a little bit confuse about the status files. > It said on the specs : > > status files > > if it does not begin with a / character , it is relative to cwd. Yes. Just like most UNIX commands/programs. > It seems that status files only check files in a node local file > system,not like status neighbors where it sends to all neighbors > to know the status of the current network. > > Please verify.... No. "status files" command should be flooded to the whole servant network just like "status neighbors". It's also about the status of the whole network. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 29 16:08:32 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6TN8W3e031201 for ; Fri, 29 Jul 2005 16:08:32 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNAAPp013940 for ; Fri, 29 Jul 2005 16:10:10 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6TNAAuP013938 for cs551@merlot.usc.edu; Fri, 29 Jul 2005 16:10:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6TNAAPp013935 for ; Fri, 29 Jul 2005 16:10:10 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6TNAAok013931 for ; Fri, 29 Jul 2005 16:10:10 -0700 Message-Id: <200507292310.j6TNAAok013931@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Error on restart Date: Fri, 29 Jul 2005 16:10:10 -0700 From: william@bourbon.usc.edu Someone wrote: > I have this odd problem when I reset a node upon disconnection > from the core network. > > Everything else works fine... but I cannot read from the keyboard. > That is cin / scanf / fscanf(stdin... don't seem to work. I cannot > take any user input and my program is stuck there... > > Do you have any clue as to what could be the problem? Well, there is always the possibility that you have trashed the memory chain (since anything can happen after that). One quick way to see if this is memory related is to do something like: #define free(x) so that a call to free() would be a no-op. (I'm not sure how to do this for delete in C++.) But this won't help if you have written on memory that you are not suppose to. But if you have freed some object twice, this should make your code work. Also, have you accidentically done a close(stdin)? I'm not sure even if you have done that it would cause problem reading stdin. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 28 14:54:54 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLss3e015699 for ; Thu, 28 Jul 2005 14:54:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLuYPp029013 for ; Thu, 28 Jul 2005 14:56:34 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6SLuYuh029011 for cs551@merlot.usc.edu; Thu, 28 Jul 2005 14:56:34 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLuYPp029008 for ; Thu, 28 Jul 2005 14:56:34 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6SLuYjL029004 for ; Thu, 28 Jul 2005 14:56:34 -0700 Message-Id: <200507282156.j6SLuYjL029004@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get message Date: Thu, 28 Jul 2005 14:56:34 -0700 From: william@bourbon.usc.edu Someone wrote: > Is it ok to have implemented the search command so that the situation > described below will work fine? I have implemented it such that the > results of a previous search request are only cleared from memory when a > new search is performed. So a get command will work as long as a search > command had been issued sometime in the past. Is this ok? Wouldn't it be very easy to add code to your parser so that if you see a command which is not a "get", you call a function to clear out the search results? -- Bill Cheng // bill.cheng@usc.edu On Thu, 28 Jul 2005 william@bourbon.usc.edu wrote: > Someone wrote: > > > Can this following be the scenario? > > > > 1. user issues search command > > > > 2. the result is displayed in the screen > > > > [1] fooo > > [2] foobar > > [3] bar > > > > 3. user issues get 2 > > 4. user issues status message > > 5. user issues get 3 ( so here, user issues another get message > > but it didn't search prior to that.....) > > > > So my question is, is search message has to be issued everytime > > the user want to get something from the network? > > A "get" command can only be issued *immediately* after a "search" > command (or a "get" command). So, after a "search", if you enter > anything other than "get", you can delete the data structure you > used to remember search results. (It's too bad that we don't have > a graphical UI.) > -- > Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 28 14:46:21 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLkL3e015173 for ; Thu, 28 Jul 2005 14:46:21 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLm1Pp028809 for ; Thu, 28 Jul 2005 14:48:01 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6SLm1wb028807 for cs551@merlot.usc.edu; Thu, 28 Jul 2005 14:48:01 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SLm1Pp028804 for ; Thu, 28 Jul 2005 14:48:01 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6SLm1sr028800 for ; Thu, 28 Jul 2005 14:48:01 -0700 Message-Id: <200507282148.j6SLm1sr028800@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get message Date: Thu, 28 Jul 2005 14:48:01 -0700 From: william@bourbon.usc.edu Someone wrote: > Why are you decided to use c/c++ to do this project? so that we > can learn stuff in detailed? I meant if we are using java, we can > have GUI and also the project can be deployed in any machine > (well I guess I don't have to think about what we send to the > network since java already take care of that right?). Can we > actually transport our code to a windows machine? like download > all the necessary library for c++ and etc? The reason Java is not allowed for this course is that there are too much networking stuff implemented in Java already. The result of using Java is that when you go into the real world, where things are implemented in C/C++, most of what you would have done for the projects will not be useful. When it comes to system implementation, I'm a big beliver in learning by doing. I think you will learn very little from doing the projects in Java. But don't get me wrong! Java is a nice language. As a *programming language*, I like it much better than C++ mainly because it got rid of things I hate most in C++: operator overloading, multiple inheritance, and templates. But Java is a still controlled by a single vendor, namely, Sun Microsystems, which, in my opinion, is not too far from going out of business. Also, the hype about write once run everywhere is just not true. If Sun Micro goes down, this write once run everywhere will most likely go to pieces. I'm really not sure about the fate of Java. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 28 12:45:01 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJj13e009553 for ; Thu, 28 Jul 2005 12:45:01 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJkfPp028207 for ; Thu, 28 Jul 2005 12:46:41 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6SJkfmX028205 for cs551@merlot.usc.edu; Thu, 28 Jul 2005 12:46:41 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJkfPp028202 for ; Thu, 28 Jul 2005 12:46:41 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6SJkfIp028198 for ; Thu, 28 Jul 2005 12:46:41 -0700 Message-Id: <200507281946.j6SJkfIp028198@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: get message Date: Thu, 28 Jul 2005 12:46:41 -0700 From: william@bourbon.usc.edu Someone wrote: > Can this following be the scenario? > > 1. user issues search command > > 2. the result is displayed in the screen > > [1] fooo > [2] foobar > [3] bar > > 3. user issues get 2 > 4. user issues status message > 5. user issues get 3 ( so here, user issues another get message > but it didn't search prior to that.....) > > So my question is, is search message has to be issued everytime > the user want to get something from the network? A "get" command can only be issued *immediately* after a "search" command (or a "get" command). So, after a "search", if you enter anything other than "get", you can delete the data structure you used to remember search results. (It's too bad that we don't have a graphical UI.) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 28 12:21:34 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJLY3e008449 for ; Thu, 28 Jul 2005 12:21:34 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJNFPp028080 for ; Thu, 28 Jul 2005 12:23:15 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6SJNFj2028078 for cs551@merlot.usc.edu; Thu, 28 Jul 2005 12:23:15 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJNEPp028075 for ; Thu, 28 Jul 2005 12:23:14 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6SJNE0i028071 for ; Thu, 28 Jul 2005 12:23:14 -0700 Message-Id: <200507281923.j6SJNE0i028071@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Search Response? Date: Thu, 28 Jul 2005 12:23:14 -0700 From: william@bourbon.usc.edu Someone wrote: > I am a bit confused about the fileID... can't it simply be the SHA1 Hash of > the file. It cannot. If use the SHA1 hash of the file and if the file is popular, when you do a GET, you can get a lot of responses. This can get really bad if the file size is large. > And if it can be the SHA1, why do we need a separate FileID field as it is > there in the MetaData > > If it is not the SHA1 hash - i.e. if it is randomly generated using GetUOID, > then there would be the additional overhead of keeping track of the > generated UOID and its corresponding file... > > Could you please explain? Yes. This is why I mentioned before that once you send out a search response, you need to add the FileID into a BST (indexed by FileID) so that when you eventually get a GET request message, you can search only this BST. If this is till not clear, please let me know. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 28 12:15:35 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJFZ3e008151 for ; Thu, 28 Jul 2005 12:15:35 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJHGPp028027 for ; Thu, 28 Jul 2005 12:17:16 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6SJHGFn028025 for cs551@merlot.usc.edu; Thu, 28 Jul 2005 12:17:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6SJHFPp028022 for ; Thu, 28 Jul 2005 12:17:16 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6SJHFl0028018 for ; Thu, 28 Jul 2005 12:17:15 -0700 Message-Id: <200507281917.j6SJHFl0028018@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: search and delete message Date: Thu, 28 Jul 2005 12:17:15 -0700 From: william@bourbon.usc.edu Someone wrote: > Simple question... > When a node sends a search message to the network, the results of the > search are printed on the screen. If the file being searched for is > present in the files directory of the node sending the search msg, should > it be included along with the other search results? Yes. > Also, to make sure, when a user issues the delete command, the node should > first delete any copies of the file it has in its files directory before > flooding the delete msg to the network, right? The timing here (before vs. after) is not important. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 27 21:18:36 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6S4Ia3e025179 for ; Wed, 27 Jul 2005 21:18:36 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6S4KIPp018705 for ; Wed, 27 Jul 2005 21:20:18 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6S4KIZW018703 for cs551@merlot.usc.edu; Wed, 27 Jul 2005 21:20:18 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6S4KIPp018700 for ; Wed, 27 Jul 2005 21:20:18 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6S4KIhi018696 for ; Wed, 27 Jul 2005 21:20:18 -0700 Message-Id: <200507280420.j6S4KIhi018696@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: DiffServ Date: Wed, 27 Jul 2005 21:20:18 -0700 From: william@bourbon.usc.edu Someone wrote: > Suppose AS1 and AS2 agree to use DiffServ at their exchange points. > AS1 sends P packets in-profile according to the agreement. > AS2 secretly treats them as normal best effort packets and > blames "network congestion" if AS1 complains. > Does anything in DiffServ address this issue? > Is there any explicit feedback to AS1? I think the concern you described above is also present in the Internet today (so this is not a DiffServ specific problem). AS2 can simply drop most packets from AS1 if AS1 and AS2 are peers. If AS1 buys transit service from AS2, there is really no reason AS2 would do what you described unless they want to lose customers. > Then again, maybe this is why most consider DiffServ a dead > issue as you said. I think the biggest problem with DiffServ is that it does not guarantee QoS. Therefore, you cannot deploy major applications such as TV on top of it. Then the question is, who would really want to pay for it? -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 27 16:43:24 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6RNhO3e012512 for ; Wed, 27 Jul 2005 16:43:24 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6RNj7Pp017394 for ; Wed, 27 Jul 2005 16:45:07 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6RNj7Qh017392 for cs551@merlot.usc.edu; Wed, 27 Jul 2005 16:45:07 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6RNj7Pp017389 for ; Wed, 27 Jul 2005 16:45:07 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6RNj7rv017385 for ; Wed, 27 Jul 2005 16:45:07 -0700 Message-Id: <200507272345.j6RNj7rv017385@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Index files Date: Wed, 27 Jul 2005 16:45:07 -0700 From: william@bourbon.usc.edu Someone wrote: > I'm still a little confused about the "structure" of the index > files (name_index and sha1_index). I'm using the libavl BST in my > program. Right now, i simply read from the index file (one file > at a time) and insert it into the corresponding BST when the node > starts up. And this is O(n log n) as is mentioned on the website. Exactly! > I don't get how i can preserve the "structure" of the BST in the > index file and how this will make the entire insertion process > O(n). > Any help? Off the top of my head, I cannot write down an algorithm. But I think if you can output your BST in a postfix notation, when you read it back you should be able to reconstruct the BST using recursion. If this is going to take too much time to figure out precisely, I would suggest you use the O(n log n) algorithm first and make sure your code is modular enough so that when you have time to do it, you can replace it with an O(n) algorithm. -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Tue Jul 26 22:55:56 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5tu3e024324 for ; Tue, 26 Jul 2005 22:55:56 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5vfPp004970 for ; Tue, 26 Jul 2005 22:57:41 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6R5vf16004968 for cs551@merlot; Tue, 26 Jul 2005 22:57:41 -0700 Date: Tue, 26 Jul 2005 22:57:41 -0700 From: william@bourbon.usc.edu Message-Id: <200507270557.j6R5vf16004968@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: part (2) testdata available... Hi, I've made some testdata for part (2) available. Please see: http://merlot.usc.edu/cs551-m05/projects/final.html#testdata -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 22:52:45 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5qj3e024176 for ; Tue, 26 Jul 2005 22:52:45 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5sUPp004952 for ; Tue, 26 Jul 2005 22:54:30 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6R5sUTX004950 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 22:54:30 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5sUPp004947 for ; Tue, 26 Jul 2005 22:54:30 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6R5sUG0004943 for ; Tue, 26 Jul 2005 22:54:30 -0700 Message-Id: <200507270554.j6R5sUG0004943@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: format of name_index and sha1_index Date: Tue, 26 Jul 2005 22:54:30 -0700 From: william@bourbon.usc.edu Someone wrote: | > > However, if our tree has the map of the filename to metafile, it | > > could quicken the search to total time of 1 + log(n). The reason | > > why we need to store pair in our name_index and sha1_index is | > > because when a node goes out, and goes back again, we need to | > > repopulate the tree. | > | > You don't need to store "1.meta". Just "1" would be enough | > (or an integer with a value of 1). You can simply do a | > strcat() or sprintf() to create "1.meta" from "1". | | Yes, I meant foo=1 not foo=1.meta.....So we are allowed to | store additional information like the sequence number here? You are allowed to store *anything* in the index files. | Because I thought we are only allowed to store foo inside the | name_index , for instance : | (in name_index file) | foo | foo1 | foo2 | foobar | But according to what you said we can do something like | foo=1 | foo1=2 | foobar=9 | | and etc I don't know how you got that impression! The spec says that you are required to build the memory data structure in O(n). Since we are all familiar with the space/time tradeoff, in order to achieve this O(n) construction time, you must put in the *strucutre* of your BST into the index files. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 22:31:52 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5Vq3e022674 for ; Tue, 26 Jul 2005 22:31:52 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5XbPp004700 for ; Tue, 26 Jul 2005 22:33:37 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6R5XbAo004698 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 22:33:37 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5XbPp004695 for ; Tue, 26 Jul 2005 22:33:37 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6R5Xb84004691 for ; Tue, 26 Jul 2005 22:33:37 -0700 Message-Id: <200507270533.j6R5Xb84004691@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: format of name_index and sha1_index Date: Tue, 26 Jul 2005 22:33:37 -0700 From: william@bourbon.usc.edu Someone wrote: > In the specs it said that name_index and sha1_index contains > filename and sha1 value respectively, so in case a node goes > down, we still have some backup of keywords, filenames and sha1 > value. These are not "backup". These are index files -- to speed up lookups. > For name_index, instead of just storing filenames, can we > also storing its corresponding meta file name in our > minifilisystem? for example : foo=1.meta. The same question goes > with sha_index. I'm not sure why you want ".meta" in it. Also, these index files should be a de-serialized BST. I'm not sure what's your intent when you said "foo=1". Are you creating a text file? If you start with a BST in memory and you don't store the *structure* of the BST in an index file, when you read it back, it will take you O(n log n) to create the memory structure. The spec says that you should create the memory structure in O(n). > The reason I am asking you this is because if we don't have this > "pairing" format, the search could be long. > For example , we want to find the filename=foo. > 1.We search in our tree for foo -> O(log n) and assume we have > the file. > 2.Search the whole meta file for filename=foo, then extract that > metadatafile. -> O(n) > > Total time : n + log n > > However, if our tree has the map of the filename to metafile, it > could quicken the search to total time of 1 + log(n). The reason > why we need to store pair in our name_index and sha1_index is > because when a node goes out, and goes back again, we need to > repopulate the tree. You don't need to store "1.meta". Just "1" would be enough (or an integer with a value of 1). You can simply do a strcat() or sprintf() to create "1.meta" from "1". -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 22:23:32 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5NW3e022287 for ; Tue, 26 Jul 2005 22:23:32 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5PHPp004615 for ; Tue, 26 Jul 2005 22:25:17 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6R5PH7l004613 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 22:25:17 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6R5PGPp004610 for ; Tue, 26 Jul 2005 22:25:16 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6R5PGCX004606 for ; Tue, 26 Jul 2005 22:25:16 -0700 Message-Id: <200507270525.j6R5PGCX004606@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: search and store file Date: Tue, 26 Jul 2005 22:25:16 -0700 From: william@bourbon.usc.edu Someone wrote: > Recall that the way we use store message is the following : > > store externalfile ttl [keywords] > > the specs said that the externalfile can be in absolute path or > not. If it's not in absolute path, then it means we have to put > it in cwd. When somebody gave an absolute path with the filename, > do we store just the file name in the metadata or the full path? > for example : > store csci551/foo 8 keywords=categories > If we store as the fullpath, that means, when we want to do > search for filename it has to be: search filename=(full path of > the filename) . The filename is just the last part of the full path. So, if you have "csci551/foo", the filename is "foo" (and "csci551" is a subdirectory namd and "/" is just a separator). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 14:26:52 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6QLQq3e032541 for ; Tue, 26 Jul 2005 14:26:52 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QLSadl003013 for ; Tue, 26 Jul 2005 14:28:37 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6QLSZLt002989 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 14:28:35 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QLSZdl002986 for ; Tue, 26 Jul 2005 14:28:35 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6QLSZjn002982 for ; Tue, 26 Jul 2005 14:28:35 -0700 Message-Id: <200507262128.j6QLSZjn002982@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Get request Date: Tue, 26 Jul 2005 14:28:35 -0700 From: william@bourbon.usc.edu Someone wrote: > Just like the flooding of a check request stops when it reaches a beacon, > should the flooding of a get request stop when it reaches the node that > has the requested file? It doesn't make sense to keep flooding the get > request once the file has been found. Because we want anonymity, it should not stop flooding. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 10:21:39 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6QHLd3e021236 for ; Tue, 26 Jul 2005 10:21:39 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QHNOdl024361 for ; Tue, 26 Jul 2005 10:23:24 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6QHNNTX024352 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 10:23:23 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QHNMdl024346 for ; Tue, 26 Jul 2005 10:23:22 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6QHNM7a024339 for ; Tue, 26 Jul 2005 10:23:22 -0700 Message-Id: <200507261723.j6QHNM7a024339@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Size Date: Tue, 26 Jul 2005 10:23:22 -0700 From: william@bourbon.usc.edu Someone wrote: > Are these assumptions correct? > > Perm Size > Certificates > Indexes > Files originating at this node > > Cache Size > Files Cached in the "store" / "get" process The purpose here is not about doing accounting. So, for PermSize, you just need to add up the file sizes for files that belongs to permanent storage. For CacheSize, you just need to add up the file sizes for cached files. Please remember that when node X do a "get", the file retrieved must go into permanent storage. Nodes along the return path for the get response that probabilistically accepted a copy of this file must store the file copy in cache storage. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 07:40:43 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEeh3e013786 for ; Tue, 26 Jul 2005 07:40:43 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEgSdl008555 for ; Tue, 26 Jul 2005 07:42:28 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6QEgSAL008553 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 07:42:28 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEgSdl008550 for ; Tue, 26 Jul 2005 07:42:28 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6QEgS8I008546 for ; Tue, 26 Jul 2005 07:42:28 -0700 Message-Id: <200507261442.j6QEgS8I008546@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Search response Date: Tue, 26 Jul 2005 07:42:28 -0700 From: william@bourbon.usc.edu Someone wrote: > If a node receives search responses from 2 different nodes, and say > both these nodes have the same file that is being searched for, then > should the node print two identical options for the user to perform a > 'get' or should it just present one option to the user (since both search > responses from the 2 different nodes contain metadata of the same file)? You should display all responses, even though they look identical visually. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 26 07:37:29 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEbT3e013574 for ; Tue, 26 Jul 2005 07:37:29 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEdEdl005880 for ; Tue, 26 Jul 2005 07:39:14 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6QEdEnB005878 for cs551@merlot.usc.edu; Tue, 26 Jul 2005 07:39:14 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6QEdEdl005875 for ; Tue, 26 Jul 2005 07:39:14 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6QEdEFn005865 for ; Tue, 26 Jul 2005 07:39:14 -0700 Message-Id: <200507261439.j6QEdEFn005865@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: STL & binary search Date: Tue, 26 Jul 2005 07:39:14 -0700 From: william@bourbon.usc.edu Someone wrote: > I just want to confirm that we are allowed to use implementation > of binary search tree other than libval. For instance, stl have > binary search that also run in logarithmic, I assumed we can use > this one right? Yes! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 23:43:34 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6hY3e023744 for ; Mon, 25 Jul 2005 23:43:34 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6jKdl008192 for ; Mon, 25 Jul 2005 23:45:20 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q6jKVH008190 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 23:45:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6jKdl008187 for ; Mon, 25 Jul 2005 23:45:20 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q6jKvu008183 for ; Mon, 25 Jul 2005 23:45:20 -0700 Message-Id: <200507260645.j6Q6jKvu008183@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Certificates and Files Date: Mon, 25 Jul 2005 23:45:20 -0700 From: william@bourbon.usc.edu Someone wrote: > For every file, we need to keep track of the public key (the owner of > the file), right? Yes. > Do we just store the certificate with the metadata? The certificate contains the public key. But I would keep the certificate in a separate file as suggested becuase it's not part of the file metadata. The spec said explicitly what's "metadata". -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 23:40:54 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6es3e023641 for ; Mon, 25 Jul 2005 23:40:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6gedl005976 for ; Mon, 25 Jul 2005 23:42:40 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q6geTj005974 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 23:42:40 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6gedl005970 for ; Mon, 25 Jul 2005 23:42:40 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q6geBO005966 for ; Mon, 25 Jul 2005 23:42:40 -0700 Message-Id: <200507260642.j6Q6geBO005966@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Search response Date: Mon, 25 Jul 2005 23:42:40 -0700 From: william@bourbon.usc.edu Someone wrote: > Understood. I do have another question though. You said the format does > not support a case where no record is returned. However, this message > format is very similar to the status response format of type 'files'. And, > in the status response, if a node does not have any files, doesn't it > respond with a status response with no records (i.e. the last field in the > response message being sent is the Hostname field). This can be > implemented without any errors (both on the sending and receiving side), > and this is what my program does. > > I implemented it this way so that the node making the status request > will learn the file status of all nodes (including ones without any > files) and this will be printed to the file specified by the user. > > If however, a 'files' status response should not be sent when no files are > present in the 'files' directory, please let me know and i will change it. You are correct that the message formats between status files response and search response messages are similar. But your interpretation for the case where a node has zero files to report was incorrect. Every field in the Message Format section of the spec is *required*, unless it's explicitly stated that the field is optional. Therefor, you cannot omit the Record Length and Data field for a status files response message, according to the spec. So, although your solution was a reasonable one, it violates the spec! The intent for having status files responses was to have *all* nodes reporting what files they have. So, even if a node has no files, it should respond. But it seems that the message format does not support this. So, what should you do? Well, you should have reported this as a bug in the spec! I've just changed the spec and added the following text to the Record Length and Data fields: [BC: Added 7/25/2005] This field should be omitted if the request type is *files* and no file is stored at the sender node. For this bug in the spec, I'm extending the deadline by another day. So, final project part (2) is due at 11:45pm on 8/3/2005. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- Date: Mon, 25 Jul 2005 21:32:19 PDT To: cs551@bourbon.usc.edu From: william@bourbon.usc.edu Subject: Re: Search response Someone wrote: >If a node receives a search message, and doesn't find any files that meet >the search criteria, should it reply with a search response message that >contains no records or should it not send a search response at all? The node should not respond. Actually, the message format for search response cannot support the case where no match is returned. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 23:14:04 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6E43e022380 for ; Mon, 25 Jul 2005 23:14:04 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6Fodl016350 for ; Mon, 25 Jul 2005 23:15:50 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q6Fof7016348 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 23:15:50 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q6Fodl016344 for ; Mon, 25 Jul 2005 23:15:50 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q6Foao016335 for ; Mon, 25 Jul 2005 23:15:50 -0700 Message-Id: <200507260615.j6Q6Foao016335@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: certificate Date: Mon, 25 Jul 2005 23:15:50 -0700 From: william@bourbon.usc.edu Someone wrote: > Do we have to store each certificate in the store message that we > received (and assume store prob said that we can store the data)? Yes! > I think the best way is to specify it with the same sequence > number that we use for the corresponding metadata and filedata? > for instance, 1.meta, 1.data, 1.certificate?? As suggested on slide 12 of lecture 14, you can use something like "N.cert". > In miscellaneous section, it said that we are limited to memory > size of 8192 bytes, what is it corresponding to? to all the files > that we have in home directory??? It says "memory buffer". Files are stored on disks. When you read/write a file, you cannot use a memory buffer larger than 8192 bytes. When you create a memory buffer for sending/receiving data, it cannot be larger than 8192 bytes. You also cannot create any memory buffer larger than 8192 bytes for any other purpose. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 21:30:33 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4UX3e017483 for ; Mon, 25 Jul 2005 21:30:33 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4WJdl028777 for ; Mon, 25 Jul 2005 21:32:19 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q4WJf2028775 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 21:32:19 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4WJdl028772 for ; Mon, 25 Jul 2005 21:32:19 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q4WJds028768 for ; Mon, 25 Jul 2005 21:32:19 -0700 Message-Id: <200507260432.j6Q4WJds028768@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Search response Date: Mon, 25 Jul 2005 21:32:19 -0700 From: william@bourbon.usc.edu Someone wrote: >If a node receives a search message, and doesn't find any files that meet >the search criteria, should it reply with a search response message that >contains no records or should it not send a search response at all? The node should not respond. Actually, the message format for search response cannot support the case where no match is returned. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 21:23:46 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4Nk3e017097 for ; Mon, 25 Jul 2005 21:23:46 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4PXdl023171 for ; Mon, 25 Jul 2005 21:25:33 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q4PXNZ023166 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 21:25:33 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4PXdl023163 for ; Mon, 25 Jul 2005 21:25:33 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q4PWTM023159 for ; Mon, 25 Jul 2005 21:25:33 -0700 Message-Id: <200507260425.j6Q4PWTM023159@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Regarding search keywords command Date: Mon, 25 Jul 2005 21:25:32 -0700 From: william@bourbon.usc.edu Someone wrote: > In case user enters multiple key's in search keywords command > (search keywords="key1 key2 key3") > - do the responses should include metadata's which have all these > matching keywords or either/any number of these matching keywords? All these matching keywords. > From the spec it seems that the responses should > include all the matching keywords, is this right? Exactly! It's in the Commandline Interface section of the spec. The "and" was highlighted in boldface. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 25 21:21:39 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4Ld3e016995 for ; Mon, 25 Jul 2005 21:21:39 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4NQdl021380 for ; Mon, 25 Jul 2005 21:23:26 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6Q4NQnk021378 for cs551@merlot.usc.edu; Mon, 25 Jul 2005 21:23:26 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6Q4NQdl021375 for ; Mon, 25 Jul 2005 21:23:26 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6Q4NQZt021371 for ; Mon, 25 Jul 2005 21:23:26 -0700 Message-Id: <200507260423.j6Q4NQZt021371@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: search command Date: Mon, 25 Jul 2005 21:23:26 -0700 From: william@bourbon.usc.edu Someone wrote: > When we implement search command, it supports multiple keywords in keyword > search. (i.e, search keywords="key1 key2 key3") > Does the found files include all terms (key1, key2, key3) or either of > terms? > (Here, a term means each word in the query.) > > If you think about web search(i.e, google), you will understand what I ask > for. When you do a google search, if you just enter search keywords "key1 key2 key3", you will find articles with only "key1" in it. You will also find articles with "key1" and "key2" in it. You will also find articles with "key1", "key2", and "key3" in it, etc. Also, when you do a google search, if you enter search keywords "key1 AND key2 AND key3", you will find only articles with "key1", "key2", and "key3" in it. Partial matched articles will not be returned. For part (2) of our project, the spec is very clear that we are doing the 2nd type of searches shown above (with implied AND). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 22 13:19:49 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6MKJn3e008887 for ; Fri, 22 Jul 2005 13:19:49 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MKLhQi013076 for ; Fri, 22 Jul 2005 13:21:43 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6MKLhhD013074 for cs551@merlot.usc.edu; Fri, 22 Jul 2005 13:21:43 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MKLhQi013071 for ; Fri, 22 Jul 2005 13:21:43 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6MKLhah013067 for ; Fri, 22 Jul 2005 13:21:43 -0700 Message-Id: <200507222021.j6MKLhah013067@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: UOID and Nonce of file Date: Fri, 22 Jul 2005 13:21:43 -0700 From: william@bourbon.usc.edu One confusion here is with the terminology. When you said "UOID of a file", I assume you meant "FileID". Leslie is correct in describing the FileID. But as it turns out, you really only need a FileID in a search response and a subsequent get request. (Well, you also need it in a response to a "status files" request. But let's forget that for now.) If you only need a FileID in a search response and a subsquent get request, then you can generate these FileID's when you generate a search response and keep these FileID's in memory waiting for a get request that has a matching FileID. So, even if you store 100,000 files, you only need to generate a few FileID's for only the ones that matched a search query. When your node restarts, you free up this memory, and you don't remember what research responses you have generated and that's okay. Now back to "status files". Since there is really no need to generate these FileIDs permanently, it doesn't make sense to keep them as part of the responses to "status files" requests. I will modify the spec in the next few minutes to delete FileID from "status files" responses. I will also extend the deadline by one day for this change. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- Date: Thu, 21 Jul 2005 20:03:41 -0700 From: Leslie Cheung To: cs551@merlot.usc.edu Subject: Re: UOID and Nonce of file Someone wrote: >If nonce is not the same as uoid, then how and where in the store message >is the uoid of a file sent to other nodes? When the originating node >sends >a store message to other nodes, the message has the uoid of the message >in its header, but where in the message can we store the uoid of the >file? >The only place i can see is in the file metadata section. But in the >specs, there is no UOID field in the file metadata. There is only a Nonce >field. So it would make sense for Nonce to be the same as the uoid of a >file. Unless there is another way... I am sorry; I should have made it clear in my last message. When a node, say node A, stores a file, it first generates a Nonce, bit vector and other metadata for this file. Then A generates a UOID of this file, and stores it in its permanent storage. After that, A floods a "store" message to all other nodes. Now let's say node B got this message and decides to store this file. B generates a UOID of this file (which is different from that of the same file on A), and store it in its permanent storage. The metadata (including Nonce) is unchanged. Both A and B have the file with the same Nonce (and other metadata), but different UOIDs. So the answer to your question is, you do not need to put a UOID of a file in the store message; it's the node who decides to store the file generate a UOID for it. And the same thing applies to "cache files". Leslie Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 22 13:05:55 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6MK5t3e007766 for ; Fri, 22 Jul 2005 13:05:55 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MK7nQi012550 for ; Fri, 22 Jul 2005 13:07:49 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6MK7nWj012548 for cs551@merlot.usc.edu; Fri, 22 Jul 2005 13:07:49 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MK7nQi012545 for ; Fri, 22 Jul 2005 13:07:49 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6MK7nlP012541 for ; Fri, 22 Jul 2005 13:07:49 -0700 Message-Id: <200507222007.j6MK7nlP012541@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: beaconthread and check Date: Fri, 22 Jul 2005 13:07:49 -0700 From: william@bourbon.usc.edu Regarding Q3, since you have minneighbors=2 and initneighbors=1, after join, you create a init_neighbor_list file with only one neighbor. At this point, you should restart your node. Therefore, you should immediately realize that you don't have enough neighbors because MinNeighbors is 2. So, you should delete init_neighbor_list and restart. When you restart, you don't see init_neighbor_list, therefore, you need to do a join. So, this configuration will lead to looping without doing anything useful. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- Date: Thu, 21 Jul 2005 16:01:50 -0700 From: Leslie Cheung To: "'alvin djunaedi'" Cc: william@bourbon.usc.edu Subject: RE: beaconthread and check >Got couple of qs : >Is the following assumption correct? > >Q1 : A beacon node should wait forever, there is no JOINTIMEOUT or >whatsoever? Not sure what you mean by "wait forever". Do you mean when it's waiting for certain messages? But if you are saying when a beacon node is idle, it should shut itself down after "AutoShutdown" amount of time since it starts up. >Q2: A beacon node does not have to send CHECK incase its neighbors >disconnect Correct, because a beacon is certainly in the core of the network. >Q3:Examine this scenario : >let minneighbors =2 , initneighbors =1 > >First step : joining network, got neighbors list, pick 1. >Second Step: send hello to all the neighbors > >When that node shutdown and then next time gets on again with >minneighbors = 2 >and initneighborslist has neighbor of 1, it will delete initneighborlist >again and try to >joining the network again? >So we only look at minneighbors only when a node starts with >initneighbors list, >please confirm this (also refer to messages from Bill with subject I think you are correct. Bill: please confirm this. This is a part 1 question. You should be focusing on part 2 of the project now. For part 2, as long as we can form a network with some number of beacons and non-beacons, that's fine. Leslie Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 22 12:58:34 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6MJwY3e007465 for ; Fri, 22 Jul 2005 12:58:34 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MK0SQi012506 for ; Fri, 22 Jul 2005 13:00:28 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6MK0SfR012504 for cs551@merlot.usc.edu; Fri, 22 Jul 2005 13:00:28 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6MK0SQi012501 for ; Fri, 22 Jul 2005 13:00:28 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6MK0SKc012497 for ; Fri, 22 Jul 2005 13:00:28 -0700 Message-Id: <200507222000.j6MK0SKc012497@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Final project questions Date: Fri, 22 Jul 2005 13:00:28 -0700 From: william@bourbon.usc.edu Hi, I have a minor correction to (3) below. When you start your node with "-reset", you should delete private/public files and generate a new pair. When you restart a node, you should check if they exist. If they don't, generate them. The reason why you should not regenerate them every time you start your node is that you won't be abel to delete any files you have stored once you have rebooted. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- Date: Wed, 20 Jul 2005 18:28:19 -0700 From: Leslie Cheung To: cs551@merlot.usc.edu Subject: Re: Final project questions Someone wrote: >1) When entering a STORE command, can the user enter duplicate tag names >for keywords. For eg, is > store abc.mp3 30 type="audio" type="mp3" artist="xyz" >a valid command? It's up to you. If you allow duplicate keys, I don't think it affects the bit-vector and search results. >2) When attempting to store a file (using the store command), if a node >discovers that the permanent memory is full, then it won't store and >serve >the file. But should it still probabilistically flood the store message >to >the network so that other nodes with cache space can store the file? It should not flood the message. Just tell the user the storage is full. >3) When are the private.pem and cert.pem files ever re-created? When the >-reset option is used? Or, does the node simply never re-create them if >they already exist in the HomeDir? You should create public/private keys when you starts your node and do not see these in the home directory. Even when your node start with "-reset", I don't think it changes these keys.If you choose to generate them every time you start a node, I think it's ok too. The bottom line is you should have already generated public/private keys before you use them. Leslie Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 19 21:23:13 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6K4ND3e024472 for ; Tue, 19 Jul 2005 21:23:13 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K4PEQi000984 for ; Tue, 19 Jul 2005 21:25:14 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6K4PEtt000982 for cs551@merlot.usc.edu; Tue, 19 Jul 2005 21:25:14 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K4PEQi000979 for ; Tue, 19 Jul 2005 21:25:14 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6K4PEUt000975 for ; Tue, 19 Jul 2005 21:25:14 -0700 Message-Id: <200507200425.j6K4PEUt000975@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: certificate Date: Tue, 19 Jul 2005 21:25:14 -0700 From: william@bourbon.usc.edu Someone wrote: > To digitally sign/verify a file, we need private key and public key > certificate. > As the spec says, we can generate private.pem and cert.pem by running > openssl. > If a node starts and it cannot find its private key and public key > certificate, should the node generate these files? Yes. > And, these file should be in the $(HOMEDIR). Right? You can store them anywhere you want in HomeDir or in a subdirectory of HomeDir. As long as it functions properly, there is no "interoperability" requirement. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 19 21:02:55 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6K42t3e023539 for ; Tue, 19 Jul 2005 21:02:55 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K44tQi000892 for ; Tue, 19 Jul 2005 21:04:55 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6K44tC1000890 for cs551@merlot.usc.edu; Tue, 19 Jul 2005 21:04:55 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K44tQi000887 for ; Tue, 19 Jul 2005 21:04:55 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6K44t31000883 for ; Tue, 19 Jul 2005 21:04:55 -0700 Message-Id: <200507200404.j6K44t31000883@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Mini File System naming Date: Tue, 19 Jul 2005 21:04:55 -0700 From: william@bourbon.usc.edu Someone wrote: > The spec says that a file name such as "1.meta" must never be reused > unless a node is reset. This means that the "-reset" commandline option is used. > So does that mean that every time the "-reset" > option is used or every time a node is disconnected from the network > (because of failure to receive CKRS) and is forced to re-join the network > by sending JNRQ, the permament and cached files are deleted and file names > such as "1.meta" can be reused? Basically, is there ever a time (other > than when a delete message is flooded) that files from the permament > memory are deleted? When a node shutdown/failed/restarted, it does not re-join the network unless the condition to delete init_neighbor_list is met (and init_neighbor_list file is deleted and the node restarts). The permanent files and cached files are not deleted *unless* the "-reset" commandline option is used. So, even if a node rejoins the network, the permanent files and the cached files are not deleted. Think about your web browser... If you are at home and you cannot connect to the Internet because your ISP has trouble, does your web browser deletes all the files it has cached? Of course not! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 19 18:01:49 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6K11n3e015168 for ; Tue, 19 Jul 2005 18:01:49 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K13oQi000453 for ; Tue, 19 Jul 2005 18:03:50 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6K13oiP000451 for cs551@merlot.usc.edu; Tue, 19 Jul 2005 18:03:50 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K13oQi000448 for ; Tue, 19 Jul 2005 18:03:50 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6K13oLC000444 for ; Tue, 19 Jul 2005 18:03:50 -0700 Message-Id: <200507200103.j6K13oLC000444@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: neighbors Date: Tue, 19 Jul 2005 18:03:50 -0700 From: william@bourbon.usc.edu Someone wrote: > Up until now I am confused with these two notions : minneighbors > and initneighbors, what's the different between them?? InitNeighbors is only used during JOIN. It's the number of entries a joining node writes into the init_neighbor_list file. MinNeighbors is used every time a node comes up (and only at the time a node *comes up*). If it has less than this number of neighbors, it deletes its init_neighbor_list file and restarts. > question 2 : > > If a node did not receive a check response in a fashioned time, > does that node have to shutdown or delete its initneighborlist > and try to rejoin the network?? Yes. It must delete its init_neighbor_list file and restart. > I have the same question for KEEPALIVE, as I implemented before, > if the neighbors = 0 or neighbors < initneighbors (for non > beacon) I just shut down the node instead rejoining the network; > should I rejoin the network instead?? No. If you don't receive a keepalive from a neighbor, you close out the connection, do CHECK, and that will determine if you need to delete init_neighbor_list or not. You don't need to look at MinNeighbors because MinNeighbors is only used when a node *comes up* (either when you start the node or when it restarts). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 19 17:56:22 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6K0uM3e014954 for ; Tue, 19 Jul 2005 17:56:22 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K0wNQi000398 for ; Tue, 19 Jul 2005 17:58:23 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6K0wNME000396 for cs551@merlot.usc.edu; Tue, 19 Jul 2005 17:58:23 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6K0wNQi000393 for ; Tue, 19 Jul 2005 17:58:23 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6K0wNPJ000389 for ; Tue, 19 Jul 2005 17:58:23 -0700 Message-Id: <200507200058.j6K0wNPJ000389@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Midterm Grades? Date: Tue, 19 Jul 2005 17:58:23 -0700 From: william@bourbon.usc.edu Someone wrote: > By when can we expect the midterm grades? Sorry about the delay. I should be abel to finish grading early next week. So, probably by next Wednesday I should be able to send your grades to you. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 19 11:27:11 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6JIRB3e029030 for ; Tue, 19 Jul 2005 11:27:11 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6JITDQi029790 for ; Tue, 19 Jul 2005 11:29:13 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6JITDPo029788 for cs551@merlot.usc.edu; Tue, 19 Jul 2005 11:29:13 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6JITDQi029785 for ; Tue, 19 Jul 2005 11:29:13 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6JITDJv029781 for ; Tue, 19 Jul 2005 11:29:13 -0700 Message-Id: <200507191829.j6JITDJv029781@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: cetificate in get reponse and store message Date: Tue, 19 Jul 2005 11:29:12 -0700 From: william@bourbon.usc.edu Someone wrote: | > Someone wrote: | > | > > The get response message contains certificate of the | > > originating node. | > > I don't know why this certificate is needed. According to | > > spec, the certificate is needed for delete message only. | > | > In the "Summary of Basic Message Types" section of the spec, | > it describes why a digital signature is needed for a delete | > message. If you follow the "digital signature" link, you | > will see that in order to produce a digital signature, you | > need a certificate file. | > | > If any node in the network is allowed to delete a file, then | > a malicious can just sit there and delete all files! In this | > project, we've made a restriction that only the creator of a | > file is allowed to delete it. But since we have anonymity, | > we really don't know who created the file. Therefore, we use | > this scheme of digitally signing a delete message to make | > sure that only the right party can delete the file. | > | | The point of my question is not necessity of certificate but why the | certificate is needed in the get response message. | I think there is no reason for the certificate to be in the get response | message. The reason is that any node that would end up storing a copy of the file will need to honor a DELETE request for that file. In order to check if the DELETE message is valid, the node needs to verify the digital signature. In order to verify the digital signature, you need the public-key certificate. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 18 23:04:15 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6J64F3e026922 for ; Mon, 18 Jul 2005 23:04:15 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6J66IQi027237 for ; Mon, 18 Jul 2005 23:06:18 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6J66IVf027235 for cs551@merlot.usc.edu; Mon, 18 Jul 2005 23:06:18 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6J66IQi027232 for ; Mon, 18 Jul 2005 23:06:18 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6J66IiQ027228 for ; Mon, 18 Jul 2005 23:06:18 -0700 Message-Id: <200507190606.j6J66IiQ027228@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: cetificate in get reponse and store message Date: Mon, 18 Jul 2005 23:06:18 -0700 From: william@bourbon.usc.edu Someone wrote: > The get response message contains certificate of the originating node. > I don't know why this certificate is needed. According to spec, the > certificate is needed for delete message only. In the "Summary of Basic Message Types" section of the spec, it describes why a digital signature is needed for a delete message. If you follow the "digital signature" link, you will see that in order to produce a digital signature, you need a certificate file. If any node in the network is allowed to delete a file, then a malicious can just sit there and delete all files! In this project, we've made a restriction that only the creator of a file is allowed to delete it. But since we have anonymity, we really don't know who created the file. Therefore, we use this scheme of digitally signing a delete message to make sure that only the right party can delete the file. > When a node receives store message and it decides to store a file, it should > store certificate as well as data file and meta file. > May we store the certificate with the file name extension of "cert" in the > $(HOMEDIR)/files directory? According to the bottom of slide 12 of lecture 14, that's the recommended way of doing it. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 18 21:13:22 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6J4DM3e021510 for ; Mon, 18 Jul 2005 21:13:22 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6J4FPQi026463 for ; Mon, 18 Jul 2005 21:15:25 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6J4FPYw026461 for cs551@merlot.usc.edu; Mon, 18 Jul 2005 21:15:25 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6J4FPQi026458 for ; Mon, 18 Jul 2005 21:15:25 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6J4FPWH026454 for ; Mon, 18 Jul 2005 21:15:25 -0700 Message-Id: <200507190415.j6J4FPWH026454@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: check message Date: Mon, 18 Jul 2005 21:15:25 -0700 From: william@bourbon.usc.edu Someone wrote: > When a beacon node receive check request, does it have to > flood the check request to its neighbor or just send a > response back? There is no need for it to continue flooding because this CHECK message has already found a beacon node (recall the purpose of CHECK). So, it should just send a check reply. -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Mon Jul 18 12:40:08 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6IJe83e030437 for ; Mon, 18 Jul 2005 12:40:08 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6IJgCQi024487 for ; Mon, 18 Jul 2005 12:42:12 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6IJgC8v024485 for cs551@merlot; Mon, 18 Jul 2005 12:42:12 -0700 Date: Mon, 18 Jul 2005 12:42:12 -0700 From: william@bourbon.usc.edu Message-Id: <200507181942.j6IJgC8v024485@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: no in-class lecture on 7/20/2005 Hi, I will be out of town between this Wednesday and Sunday. So, there will be no in-class lecture on 7/20/2005. A pre-taped lecture will be played on DEN on 7/20/2005. I will have limited (if any at all) Internet connection during my travel. Please make sure you send all your project related questions to both the TA and myself. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 18 07:57:02 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6IEv23e017076 for ; Mon, 18 Jul 2005 07:57:02 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6IEx7Qi022686 for ; Mon, 18 Jul 2005 07:59:07 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6IEx7NT022684 for cs551@merlot.usc.edu; Mon, 18 Jul 2005 07:59:07 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6IEx7Qi022681 for ; Mon, 18 Jul 2005 07:59:07 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6IEx7q4022677 for ; Mon, 18 Jul 2005 07:59:07 -0700 Message-Id: <200507181459.j6IEx7q4022677@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: index file format Date: Mon, 18 Jul 2005 07:59:07 -0700 From: william@bourbon.usc.edu Someone wrote: > There are three index files (i.e, keyword index, name index, and > sha1 index). > The spec says, > Each node in a index structure references a data file by file name. The "data file" mentioned here is described in the previous paragraph. So, the file name of these data files are simply "1", "2", "3", etc. > However, when I think of keyword index file, a meta file > seems to be better than a data file as a reference. In case of > name index and sha1 index, we can find the exact matching file > from the file name or sha1 hash value. But, we cannot guarantee > whether the matching file from searching with keyword is the file > that we want to find, so we have to refer meta file. Of course, > we can know the meta file from the data file name but this needs > string parsing process. To avoid needless overhead and improve > performance, can we use meta file name instead of data file name > in the keyword index file? The "data file name" and "meta data file name" are identical (if you think of the file extension as something else). So, all you have to store are the numeric names of the data/metadata files. You can easily add the filename extension when you want to open access the data or the metadata (or anything else) file. > Another question... > There can be some files, which have the same file name, let say > 'abc.mp3'. Since the binary search tree cannot have duplicated > keys, we have only one index for 'abc.mp3' in name index file. I > have no idea how to solve this problem. A node in the BST usually stores an object, which could be an integer, a string, an C++ object, or anything you want. You You can even have this object be another BST tree! (That's probably an overkill.) You can also have this object be a sequential list of objects to resolve conflicts. So, when you get a conflict, you need to search through the conflict resolution list sequentially. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 17 22:31:46 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5Vk3e022889 for ; Sun, 17 Jul 2005 22:31:46 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5XpQi020555 for ; Sun, 17 Jul 2005 22:33:51 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6I5XoEg020553 for cs551@merlot.usc.edu; Sun, 17 Jul 2005 22:33:50 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5XoQi020550 for ; Sun, 17 Jul 2005 22:33:50 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6I5XnM1020546 for ; Sun, 17 Jul 2005 22:33:50 -0700 Message-Id: <200507180533.j6I5XnM1020546@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: simultaneous connections Date: Sun, 17 Jul 2005 22:33:49 -0700 From: william@bourbon.usc.edu Someone wrote: > After all this time I am still having problems with simultaneous > connections between 2 peers. First if the client side of Node A connects > to the server side of node B, it knows the node ids of each peer and can > perform the calculation. But when the client side of node B connects to > the server side of Node A, node A will not know the node_id of B from > this connection. Node A will only know the hostname and ephemeral port > of B (by looking at accept_addr.sin_port, where accept_addr is of type > sockaddr_in). Therefore how can Node A tell that its server side > connection is to the same peer as the client side connection, and close > one of the connections? Since the first message on a connection must be a HELLO message, node A will have to wait for the HELLO message (and node B's node ID will be in the HELLO message). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 17 22:27:23 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5RN3e022677 for ; Sun, 17 Jul 2005 22:27:23 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5TSQi020448 for ; Sun, 17 Jul 2005 22:29:28 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6I5TRkG020445 for cs551@merlot.usc.edu; Sun, 17 Jul 2005 22:29:27 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5TQQi020442 for ; Sun, 17 Jul 2005 22:29:27 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6I5TQ3t020438 for ; Sun, 17 Jul 2005 22:29:26 -0700 Message-Id: <200507180529.j6I5TQ3t020438@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: final Date: Sun, 17 Jul 2005 22:29:26 -0700 From: william@bourbon.usc.edu Someone wrote: > I am just wondering whether the final exam cover only the > second half of the semester ( after the midterm material) or > from the beginning of the class? There will be no overlap between what the midterm covered and what the final will cover. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 17 22:22:11 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5MB3e022490 for ; Sun, 17 Jul 2005 22:22:11 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5OGQi020312 for ; Sun, 17 Jul 2005 22:24:16 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6I5OFBv020307 for cs551@merlot.usc.edu; Sun, 17 Jul 2005 22:24:15 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5OEQi020304 for ; Sun, 17 Jul 2005 22:24:15 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6I5OEV9020300 for ; Sun, 17 Jul 2005 22:24:14 -0700 Message-Id: <200507180524.j6I5OEV9020300@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: reading binary files Date: Sun, 17 Jul 2005 22:24:14 -0700 From: william@bourbon.usc.edu To answer the question about why your comparison of EOF did not do what you expect... As always, you need to read the man pages carefully! fgetc() returns an int. You immediately typecasted it to a char and then you compare the char with EOF. I think EOF is defined to be (-1). So, if you read 0x00ff from your data file, you will see that the way you are doing it will cause it to be equal to EOF! So, what you must do is to read the int, compare with EOF, if it's not EOF, then you can typecast it to char. If you do this right, you don't need to call fstat() to get the file size because fgetc() should work as advertised. -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- Date: Sun, 17 Jul 2005 13:31:27 -0700 From: Leslie Cheung To: cs551@merlot.usc.edu Subject: Re: reading binary files Someone wrote: >I'm having trouble when reading large binary files (like .mp3's). >The following code is what I'm doing to calculate file size and also >calculate SHA1 hash for the file. >fgetc is returning EOF well before the end of the file. > >-------------------- >char c1 = '\0'; >fp = fopen(filename, "rb"); > >for (i = 0; ( (c1 = fgetc(fp)) != EOF); i++) >{ > SHA1_Update... >} >--------------------- > >Is there some other method I should use to iterate over a binary file? >I'm stuck. You might want to use "fstat" (man -s 2 fstat) to get the size of the file. I believe this function read the i-node (metadata) of the file. I am not sure why fgetc returns EOF well before the end of file, but if you know the size of the file without opening it, I think that would help? Leslie Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 17 22:17:54 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5Hs3e022192 for ; Sun, 17 Jul 2005 22:17:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5JxQi020188 for ; Sun, 17 Jul 2005 22:20:00 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6I5JwXs020186 for cs551@merlot.usc.edu; Sun, 17 Jul 2005 22:19:59 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6I5JwQi020183 for ; Sun, 17 Jul 2005 22:19:58 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6I5JwuK020179 for ; Sun, 17 Jul 2005 22:19:58 -0700 Message-Id: <200507180519.j6I5JwuK020179@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Cache questions Date: Sun, 17 Jul 2005 22:19:58 -0700 From: william@bourbon.usc.edu Someone wrote: > Hi, i have a few questions, all relating to the cache in the final > project. > > 1) Is it okay to create a directory (eg. cachefiles) inside the HomeDir > where all the cached files will stored? If not, where do we store the > cached files? The only difference between cached files and permanent files is that permanent files are not subject to LRU. So, you can put them in the same directory and just use a bit per file (and store this information *somrewhere*) to indicate if a file belongs to the cache or permanent storage. You can also use a separate directory if you like. It's up to you. > 2) When a node receives a search message, does it respond with a search > response if the file is found only in it's cache memory and not in it's > permanent memory? In order to do this, won't the linear list of > bit-vectors contain the bit-vectors for all the files in the cache as well > as all the files in the permanent memory? Again, the only difference between cached files and permanent files is that permanent files are not subject to LRU. So, you must search both cached files and permanent files. This is why I think it's easier to put them all in the same directory. > 3) When a node receives a get message, does it look for the file in the > cahce memory after it is done looking in the permanent memory, and if the > file is found only in the cache, does it still send a get response? Again, the only difference between cached files and permanent files is that permanent files are not subject to LRU. So, get applies to both types of files. > 4) Just want to make sure that the cache is deleted upon shutdown or when > a node crashes. In the even of a crash, however, only the permanent memory > is preserved. Am i right? No. When you shutdown you web browser, none of the cached files are deleted. Same idea here. > This last question is about redirecting stderr... > > 5) When the private and public key files are generated using openssl, a > lot of text is output to stderr. Is there any way to prevent this output > from appearing on the screen and instead redirect to some temp file or > /dev/null? I know we can do this with stdout but what about stderr? Did you read the section on "Note on Invoking popen()" in the spec? http://merlot.usc.edu/cs551-m05/projects/final.html#popen Part of this is related to what you are asking. Also, if you read the commands carefully, some commands use "-out /dev/null" to force the output to /dev/null if you don't want to see the output. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 16 21:28:57 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4Sv3e006865 for ; Sat, 16 Jul 2005 21:28:57 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4V5Qi005217 for ; Sat, 16 Jul 2005 21:31:06 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6H4V4tM005214 for cs551@merlot.usc.edu; Sat, 16 Jul 2005 21:31:04 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4V4Qi005211 for ; Sat, 16 Jul 2005 21:31:04 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6H4V4TL005207 for ; Sat, 16 Jul 2005 21:31:04 -0700 Message-Id: <200507170431.j6H4V4TL005207@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: store command Date: Sat, 16 Jul 2005 21:31:04 -0700 From: william@bourbon.usc.edu Someone wrote: > When a node receives store request message, it sends (floods) store request > messages to its neighbor nodes. > Unlike other messages (join, check request), the store request message is > sent to ONLY selected neighbors based on NeighborStoreProb. > Is this right? Yes. > It seems to be probablistic that a file is stored in the servant network, so > the file store command may fail. > That is, if a node receives store request message, it flips a coin with > probability StoreProb and decides whether the file is stored. > I think that the node may not store the file if the coin shows tail. > Also, if the NeighborStoreProb key is small, a node may not forward store > request message to its neighbor nodes. > Even if the node forward the store request message, the neighbor node may > not store the file. > How can we gurantee the file is safely stored in the servant network? The node initiated the store *must* store a copy of the file. It then floods the store command probabilistically. You are correct that it's possible that everything comes up tails and none of its neighbors will get the store command. But that's okay because that's what probabilistic this and that is all about! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sat Jul 16 21:25:20 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4PK3e006675 for ; Sat, 16 Jul 2005 21:25:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4RSQi005185 for ; Sat, 16 Jul 2005 21:27:28 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6H4RR2Y005182 for cs551@merlot.usc.edu; Sat, 16 Jul 2005 21:27:27 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6H4RRQi005179 for ; Sat, 16 Jul 2005 21:27:27 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6H4RRlU005175 for ; Sat, 16 Jul 2005 21:27:27 -0700 Message-Id: <200507170427.j6H4RRlU005175@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: GNU Libavl Date: Sat, 16 Jul 2005 21:27:27 -0700 From: william@bourbon.usc.edu Someone wrote: > The Binary Search Tree Library is made for C, where as my > program is in C++. I tried to compile them seperately using > gcc/g++ and linking the object files, but it gives me "symbol > referencing errors" > > Is there an alternative to it? Code on the class web page is not using a library. So, if you use, you shouldn't have the "symbol reference" errors. If you really want to link to libavl.a (or libavl.so), then you need to make sure your C++ compiler knows when not to mangle function names. The way you can tell all C++ compiler not to mangle the name of a function is to surround the function declaration with: extern "C" For example, if your C header file contains: char *strcpy(char *dest, const char *src); char *strncpy(char *dest, const char *src, size_t n); you should do: extern "C" { char *strcpy(char *dest, const char *src); char *strncpy(char *dest, const char *src, size_t n); } This way, your C++ code will think the actual names of these functions are _strcpy and _strncpy. If you don't have the extern "C", your C++ code will think the actual names of these functions are a lot longer (and compiler dependent). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 12 21:30:36 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6D4Ua3e027225 for ; Tue, 12 Jul 2005 21:30:36 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6D4WsQi010229 for ; Tue, 12 Jul 2005 21:32:54 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6D4Wshu010227 for cs551@merlot.usc.edu; Tue, 12 Jul 2005 21:32:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6D4WsQi010224 for ; Tue, 12 Jul 2005 21:32:54 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6D4WsCe010220 for ; Tue, 12 Jul 2005 21:32:54 -0700 Message-Id: <200507130432.j6D4WsCe010220@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: tcp queue lockout Date: Tue, 12 Jul 2005 21:32:54 -0700 From: william@bourbon.usc.edu Someone wrote: > I am still having difficulty understanding why tcp lockout occurs with > droptail queue implementations. I can see that if packets from a tcp > flow are already in the queue they will not be dropped and will detect > congestion later. Is the reason for the lockout that the congestion is > already cleared up by the time those flows can detect it, and hence they > keep sending packets? If not, when they detect congestion won't they > back off, and thus other flows may get into the queue? The flows that end up monopolizing the buffers do back off. But they capture the buffers much quicker than the flows that got locked out. Not all flows are created equal. The ones with short TTL can build up cwnd very quickly relative to the ones with long TTL. Another thing that can be a factor is that once a timeout occur in TCP, the sender doubles it's RTO. So, for streams with long TTL, once they got a timeout, they can get more timeouts. This exponential backoff will stop if RTO reaches 30 seconds. Those flows whose RTO reached 30 seconds are basically locked out completely. -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Mon Jul 11 07:53:22 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6BErMja010571 for ; Mon, 11 Jul 2005 07:53:22 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6BEuTSB010424 for ; Mon, 11 Jul 2005 07:56:29 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6BEuTIR010420 for ; Mon, 11 Jul 2005 07:56:29 -0700 Message-Id: <200507111456.j6BEuTIR010420@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: fair queueing Date: Mon, 11 Jul 2005 07:56:29 -0700 From: william@bourbon.usc.edu Someone wrote: > In your fair queueing lecture on slide # 25, when x3 comes > in, aren't the slope suppose to be degraded to 1/4 ( since > x1, Y2, Z1 are still in the system) ? On slide 25 of lecture 12, the reason that the slope is 1/3 is that only a maximum of 3 streams can be active concurrently (since we only have 3 queues and their weights are all 1). X3 has to wait for X1 to finish. Therefore the slope stays at 1/3. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 11 07:47:41 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6BElfja010268 for ; Mon, 11 Jul 2005 07:47:41 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6BEolSB010370 for ; Mon, 11 Jul 2005 07:50:47 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6BEolS0010368 for cs551@merlot.usc.edu; Mon, 11 Jul 2005 07:50:47 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6BEolSB010365 for ; Mon, 11 Jul 2005 07:50:47 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6BEolat010361 for ; Mon, 11 Jul 2005 07:50:47 -0700 Message-Id: <200507111450.j6BEolat010361@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Congestion Avoidance Date: Mon, 11 Jul 2005 07:50:47 -0700 From: william@bourbon.usc.edu Someone wrote: > It said in the lecture that when a packet loss occured during > congestion avoidance stage, we set cwnd = 0.5 W (lecture slides # > 16). But then on lecture slides # 19, it always go back to slow > start where cwnd = 1. The only time we resume from congestion > avoidance stage when a packet loss occured is on Fast Recovery > (resume transmit at cwnd = sstresh = 0.5 W )..... Correct. The explanation for slide 16 of lecture 11 is that it's about "high level concept". We often say that for TCP, if there is a lost, cwnd=cwnd/2. What we actually mean is that ssthresh=cwnd/2. What does cwnd really become? Well, it depends on the implementation and the condition (as you've mentioned above). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 8 20:58:38 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j693wcja028305 for ; Fri, 8 Jul 2005 20:58:38 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6941qSB019399 for ; Fri, 8 Jul 2005 21:01:52 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6941q60019397 for cs551@merlot.usc.edu; Fri, 8 Jul 2005 21:01:52 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6941qSB019394 for ; Fri, 8 Jul 2005 21:01:52 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6941qK0019390 for ; Fri, 8 Jul 2005 21:01:52 -0700 Message-Id: <200507090401.j6941qK0019390@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: TCP Congestion Control Date: Fri, 08 Jul 2005 21:01:52 -0700 From: william@bourbon.usc.edu Someone wrote: > I had a doubt in the TCP congestion control mechanism: > > After TimeOut occus, why do we go back into slow start when > our eventual target is ssthresh=cwnd/2. > What would be the problem if we go into congestion avoidance > directly after 1st TO. > That is... > 1. Start with slow start > => Multiplicative increase > --->TO occurs > 2. ssthresh = cwnd/2 > 3. cwnd=ssthresh > => Go into congestion avoidance mode > => Additive increase (/Multiplicative decrease) > > This would achieve much better throughput - as our idea is > that the optimum is between cwnd and cwnd/2 If the right window size is between cwnd and cwnd/2, then skipping slowstart would be the right thing to do. But we really don't know for sure and we prefer to be conservative (and nice to everyone else). Let's say that we skip slow start, then we are basically doing a reverse doubling search for the right window size. Every time we are wrong, it costs us a lot since we have injected so many packets into the network. So, if we take this approach, congestion will tend to stay a lot longer. By the way, some aggressive TCP implementations are already doing what you suggested. If more and more people start using the aggressive stuff, I think we will start to see longer and longer congestions in the Internet. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 8 20:43:16 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j693hGja027557 for ; Fri, 8 Jul 2005 20:43:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j693kUSB019313 for ; Fri, 8 Jul 2005 20:46:30 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j693kUbg019311 for cs551@merlot.usc.edu; Fri, 8 Jul 2005 20:46:30 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j693kUSB019308 for ; Fri, 8 Jul 2005 20:46:30 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j693kUKQ019304 for ; Fri, 8 Jul 2005 20:46:30 -0700 Message-Id: <200507090346.j693kUKQ019304@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: WFQ problem from HW2 Date: Fri, 08 Jul 2005 20:46:30 -0700 From: william@bourbon.usc.edu Someone wrote: > Can we get the solution for HW2 - problem 3 on Weighted Fair Queuing? The solution is at: http://merlot.usc.edu/cs551-m05/homeworks/sol-wfq.html Thanks for reminding me about this! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 8 16:19:06 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68NJ6ja015251 for ; Fri, 8 Jul 2005 16:19:06 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68NMJSB018686 for ; Fri, 8 Jul 2005 16:22:19 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j68NMJDM018684 for cs551@merlot.usc.edu; Fri, 8 Jul 2005 16:22:19 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68NMJSB018681 for ; Fri, 8 Jul 2005 16:22:19 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j68NMJ7N018677 for ; Fri, 8 Jul 2005 16:22:19 -0700 Message-Id: <200507082322.j68NMJ7N018677@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: KeepAlive msg Date: Fri, 08 Jul 2005 16:22:19 -0700 From: william@bourbon.usc.edu Someone wrote: > When should a keepalive msg be sent? The JoinTimeout parameter > specifies when a connection should be shut down if no msgs are > received. So which parameter tells us how often the keepalive should > be sent? Please see my message with timestamp "Sat 18 Jun 23:02". -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Fri Jul 8 13:39:16 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68KdGja007239 for ; Fri, 8 Jul 2005 13:39:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68KgVSB017270 for ; Fri, 8 Jul 2005 13:42:31 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j68KgVSY017268 for cs551@merlot; Fri, 8 Jul 2005 13:42:31 -0700 Date: Fri, 8 Jul 2005 13:42:31 -0700 From: william@bourbon.usc.edu Message-Id: <200507082042.j68KgVSY017268@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: class server reboot after midterm... Hi, I will need to reboot merlot.usc.edu soon after the midterm exam next week. It should probably only take about half an hour. The class web pages will not be available during the down time since they are hosted on merlot.usc.edu. -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Fri Jul 8 13:36:10 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68KaAja007134 for ; Fri, 8 Jul 2005 13:36:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68KdNSB017243 for ; Fri, 8 Jul 2005 13:39:23 -0700 Received: (from william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j68KdNCD017241 for cs551@merlot; Fri, 8 Jul 2005 13:39:23 -0700 Date: Fri, 8 Jul 2005 13:39:23 -0700 From: william@bourbon.usc.edu Message-Id: <200507082039.j68KdNCD017241@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: final project part (1) reminder... Hi, Final project part (1) is due late night tonight. Just want to remind everyone to submit on time. It would also be a good idea to make at least one submission a couple of hours before the deadline. Please remember that I must stick to the rules laid out on the projects page and cannot make an exception. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 8 13:21:58 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68KLwja006375 for ; Fri, 8 Jul 2005 13:21:58 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68KPCSB017136 for ; Fri, 8 Jul 2005 13:25:12 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j68KPC4u017134 for cs551@merlot.usc.edu; Fri, 8 Jul 2005 13:25:12 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68KPCSB017131 for ; Fri, 8 Jul 2005 13:25:12 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j68KPC3j017127 for ; Fri, 8 Jul 2005 13:25:12 -0700 Message-Id: <200507082025.j68KPC3j017127@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Test Case Question Date: Fri, 08 Jul 2005 13:25:12 -0700 From: william@bourbon.usc.edu Someone wrote: > What are the three options here: > Test Case 3: > "Status command (with all three options)" It's a typo. I've just fixed it. Thanks for catching it! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Fri Jul 8 12:56:59 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68Juxja005162 for ; Fri, 8 Jul 2005 12:56:59 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68K0DSB016795 for ; Fri, 8 Jul 2005 13:00:13 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j68K0Dw8016793 for cs551@merlot.usc.edu; Fri, 8 Jul 2005 13:00:13 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j68K0DSB016790 for ; Fri, 8 Jul 2005 13:00:13 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j68K0DfW016786 for ; Fri, 8 Jul 2005 13:00:13 -0700 Message-Id: <200507082000.j68K0DfW016786@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: msgid Date: Fri, 08 Jul 2005 13:00:13 -0700 From: william@bourbon.usc.edu Someone wrote: > What is msgid in the logfile?? Is it the UOID of the message? > The one that we have in byte pos 1 - 20 in our message header?? Yes. In the common message header. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 22:41:04 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j685f4ja029769 for ; Thu, 7 Jul 2005 22:41:04 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j685iKSB013981 for ; Thu, 7 Jul 2005 22:44:20 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j685iKTi013979 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 22:44:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j685iKSB013976 for ; Thu, 7 Jul 2005 22:44:20 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j685iKmw013972 for ; Thu, 7 Jul 2005 22:44:20 -0700 Message-Id: <200507080544.j685iKmw013972@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Message Routing Table Date: Thu, 07 Jul 2005 22:44:20 -0700 From: william@bourbon.usc.edu Someone wrote: > Regarding the message routing table that we used to check if we have > received a duplicate message during forwarding, when should (or how > often) should the table be cleared? This is part of the design that you need to figure out. One thing you can do is that when a message arrives, you attach an expiration time to it (based on MsgLifeTime) before you add it to the data structure for message lookup (which is the probably some sort of a BST). Then you need to figure out when to remove this node after the expiration time. One possibility is to have a timer that goes off once every second (I've mentioned this in class) and have it deposit a token to the event queue. When the scheduler sees this token, it will replicate this token so that some maintenance jobs can do what they need to do. One of the maintenance jobs would be to scrub the BST and delete messages that have expired. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 21:40:54 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j684esja026806 for ; Thu, 7 Jul 2005 21:40:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j684iASB013410 for ; Thu, 7 Jul 2005 21:44:10 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j684iAY8013408 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 21:44:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j684i9SB013405 for ; Thu, 7 Jul 2005 21:44:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j684i9iP013401 for ; Thu, 7 Jul 2005 21:44:09 -0700 Message-Id: <200507080444.j684i9iP013401@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Choosing Minimum Distance Date: Thu, 07 Jul 2005 21:44:09 -0700 From: william@bourbon.usc.edu Someone wrote: > When a node receives a JOIN replies, how does it know which lowest > distance values to choose? Does it just choose the (n) number of > lowest ones? It should sort the responses based on the distance values and then pick the lowest ones. > If so, how many lowest ones should it choose? The > minumim number to start up? InitNeighbors in the startup configuration file. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 18:09:07 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j68197ja016986 for ; Thu, 7 Jul 2005 18:09:07 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j681CNSB012337 for ; Thu, 7 Jul 2005 18:12:23 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j681CNC8012335 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 18:12:23 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j681CNSB012332 for ; Thu, 7 Jul 2005 18:12:23 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j681CNYT012328 for ; Thu, 7 Jul 2005 18:12:23 -0700 Message-Id: <200507080112.j681CNYT012328@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: routing Date: Thu, 07 Jul 2005 18:12:23 -0700 From: william@bourbon.usc.edu Someone wrote: > In the spec regarding routing, you mention [UOID x]. What is x? Are > you supposed to look up UOID with respect to x? Is x a node ID in > this case? x is the UOID if the message created in step (1). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 18:00:10 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6810Aja016625 for ; Thu, 7 Jul 2005 18:00:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6813QSB012201 for ; Thu, 7 Jul 2005 18:03:26 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6813Qvi012199 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 18:03:26 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6813QSB012196 for ; Thu, 7 Jul 2005 18:03:26 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6813QOF012192 for ; Thu, 7 Jul 2005 18:03:26 -0700 Message-Id: <200507080103.j6813QOF012192@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: size in log file Date: Thu, 07 Jul 2005 18:03:26 -0700 From: william@bourbon.usc.edu Someone wrote: > It said in the specs that the size (in log file) should account > fo the message header size. Does this mean that every line of our > log file has the same value which is 27 bytes? No. It means that it should be the size of the entire message (and not just the value in the DataLength field). -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 12:59:38 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j67Jxcja002665 for ; Thu, 7 Jul 2005 12:59:38 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j67K2tSB011268 for ; Thu, 7 Jul 2005 13:02:55 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j67K2tVH011266 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 13:02:55 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j67K2tSB011263 for ; Thu, 7 Jul 2005 13:02:55 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j67K2thB011259 for ; Thu, 7 Jul 2005 13:02:55 -0700 Message-Id: <200507072002.j67K2thB011259@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Neighbor Disconnection Date: Thu, 07 Jul 2005 13:02:55 -0700 From: william@bourbon.usc.edu Someone wrote: > What action is to be taken for part 1 if a neighbor > disconnects and say the total neighbors connected goes below > the minimum required? Nothing! (I guess if the number neighbors is zero and this is a non-beacon node, it should probably restart.) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Thu Jul 7 12:57:11 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j67JvBja002562 for ; Thu, 7 Jul 2005 12:57:11 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j67K0SSB011233 for ; Thu, 7 Jul 2005 13:00:28 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j67K0S3f011231 for cs551@merlot.usc.edu; Thu, 7 Jul 2005 13:00:28 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j67K0RSB011228 for ; Thu, 7 Jul 2005 13:00:27 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j67K0RAH011224 for ; Thu, 7 Jul 2005 13:00:27 -0700 Message-Id: <200507072000.j67K0RAH011224@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Prob with gdb Date: Thu, 07 Jul 2005 13:00:27 -0700 From: william@bourbon.usc.edu Someone wrote: > I am getting this odd problem with gdb > > every time the thread 11 exits, the debugger is suspended..... > Any idea as to why? I tried looking up online, they had > simillar problems .. but no solution was posted. Heres what I > get > > [New LWP 10] > [New LWP 11] > [New LWP 12] > .... > [LWP 9 exited] > [New LWP 9] > [LWP 10 exited] > [New LWP 10] > [LWP 11 exited] > > Suspended (tty output) > > Any solutions? It's possible that it's a bug in gdb (gdb is not known to be perfect). Another possibility is that you have a bug in your code and it's trashing some system memory that gdb or threads use. By the way, when you said "debugger is suspended", you mean that you don't get a prompt and there's nothing you can do? I guess if you get a gdb prompt and all you have to do is to type "cont", then it's not so bad. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Sun Jul 24 22:21:42 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j6P5Lg3e016873 for ; Sun, 24 Jul 2005 22:21:42 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6P5NUQi032323 for ; Sun, 24 Jul 2005 22:23:31 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6P5NUre032321 for cs551@merlot.usc.edu; Sun, 24 Jul 2005 22:23:30 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6P5NUQi032318 for ; Sun, 24 Jul 2005 22:23:30 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j6P5NUYb032314 for ; Sun, 24 Jul 2005 22:23:30 -0700 Message-Id: <200507250523.j6P5NUYb032314@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Bash and popen Date: Sun, 24 Jul 2005 22:23:30 -0700 From: william@bourbon.usc.edu Someone wrote: > I have question regarding certificate stuff. It said in the specs > that we should invoke popen under bash shell so that we can > combine stdout and stderr. Is this because we want to display the > message "verification successful" ? so that we need to do it in > bash shell? For creating public key and private key, we don't > really need to do it in bash right? because we don't really want > any feedback?? The problem we are trying to solve is that when you run a command with popen(), how do you know if it ran successfully? If the command that is run inside popen() outputs to stderr, your code may not be able to capture it by reading the pipe created by popen(). THerefore, we suggest this way of running the command (under bash) so you can see "verification successful" in the pipe created by popen(). To create public key and private key, you can easily verify if your command was successful by testing if the key files got created. So, you don't need to read the pipe. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 22:42:49 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j675gnja027636 for ; Wed, 6 Jul 2005 22:42:49 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j675k8SB007982 for ; Wed, 6 Jul 2005 22:46:08 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j675k8PW007980 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 22:46:08 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j675k7SB007977 for ; Wed, 6 Jul 2005 22:46:07 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j675k78S007973 for ; Wed, 6 Jul 2005 22:46:07 -0700 Message-Id: <200507070546.j675k78S007973@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: converting the last 4 bytes of sha1 value in the distance computation Date: Wed, 06 Jul 2005 22:46:07 -0700 From: william@bourbon.usc.edu Someone wrote: | > Your code asked printf() to display the variable a in | > long and that's exactly what you get! (I don't think | > printf() knows about signed or unsigned.) | | For the record... | Actually printf does know since you tell it - %d is for | signed decimal notation. %u is for unsigned decimal notation. | Just use %lu in the above rather than %ld. Correct! (I forgot about %u. It's clearly in the man pages, right next to %x.) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 19:32:20 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j672WKja018751 for ; Wed, 6 Jul 2005 19:32:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j672ZdSB007130 for ; Wed, 6 Jul 2005 19:35:39 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j672ZcJd007128 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 19:35:38 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j672ZcSB007125 for ; Wed, 6 Jul 2005 19:35:38 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j672ZcdY007121 for ; Wed, 6 Jul 2005 19:35:38 -0700 Message-Id: <200507070235.j672ZcdY007121@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: converting the last 4 bytes of sha1 value in the distance computation Date: Wed, 06 Jul 2005 19:35:38 -0700 From: william@bourbon.usc.edu Someone wrote: > When I tested the following source code, it showed minus value. I have no > idea why this prints out -2. > > #include > #include > > int main(int argc, char** argv) > { > unsigned char x[] = { 0xff, 0xff, 0xff, 0xfe }; > uint32_t a; > > a = (x[0]<<24)|(x[1]<<16)|(x[2]<<8)|x[3]; > > printf("%ld\n", a); > return 1; > } Your code asked printf() to display the variable a in long and that's exactly what you get! (I don't think printf() knows about signed or unsigned.) Also, wouldn't you get a compiler warning with your printf() statement? (Points were taken off because of compiler warnings for the warmup projects.) The problem you see here is that you are calling printf() without fully understand what printf() is doing for you! I'm not sure why you *have to* print the value out in decimal. Personally, I would just print out the value in hex if I just want to visually compare two unsigned values: printf("0x%08lx", (unsigned long)a); -- Bill Cheng // bill.cheng@usc.edu -----Original Message----- From: william@bourbon.usc.edu [mailto:william@bourbon.usc.edu] Sent: Wednesday, July 06, 2005 10:04 AM To: cs551@bourbon.usc.edu Subject: Re: converting the last 4 bytes of sha1 value in the distance computation Someone wrote: > In order to compute distance between two nodes, we get sha1 hash value and > take the last 4 bytes of it. > When I try to convert this 4 bytes to numerical value, the integer overflow > happens. > > The converting mechanism is, > > uint32_t a; > char sha1[20]; > > a = sha1[16] * 256 * 256 * 256 + sha1[17] *256*256 + sha1[18]*256 + > sha1[19]; > > Since the uint32_t type is the unsigned long type (strictly speaking, the > upper bound is the same), > the uint32_t cannot hold more than 256*256*256*127 (=2130706432). > I think that since the sha hash value can be any value between 0 and 255 in > each digit, > the overflow is inevitable. The max value for uint32_t is (256*256*256*256)-1. I'm not sure why you are doing multiplying and adding. I would do shifts and ANDs and ORs. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 10:00:56 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j66H0uja024582 for ; Wed, 6 Jul 2005 10:00:56 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66H4GSB004332 for ; Wed, 6 Jul 2005 10:04:16 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j66H4Gwa004330 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 10:04:16 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66H4GSB004327 for ; Wed, 6 Jul 2005 10:04:16 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j66H4Gt2004323 for ; Wed, 6 Jul 2005 10:04:16 -0700 Message-Id: <200507061704.j66H4Gt2004323@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: converting the last 4 bytes of sha1 value in the distance computation Date: Wed, 06 Jul 2005 10:04:16 -0700 From: william@bourbon.usc.edu Someone wrote: > In order to compute distance between two nodes, we get sha1 hash value and > take the last 4 bytes of it. > When I try to convert this 4 bytes to numerical value, the integer overflow > happens. > > The converting mechanism is, > > uint32_t a; > char sha1[20]; > > a = sha1[16] * 256 * 256 * 256 + sha1[17] *256*256 + sha1[18]*256 + > sha1[19]; > > Since the uint32_t type is the unsigned long type (strictly speaking, the > upper bound is the same), > the uint32_t cannot hold more than 256*256*256*127 (=2130706432). > I think that since the sha hash value can be any value between 0 and 255 in > each digit, > the overflow is inevitable. The max value for uint32_t is (256*256*256*256)-1. I'm not sure why you are doing multiplying and adding. I would do shifts and ANDs and ORs. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 09:57:17 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j66GvHja024370 for ; Wed, 6 Jul 2005 09:57:17 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66H0bSB004276 for ; Wed, 6 Jul 2005 10:00:37 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j66H0bQV004274 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 10:00:37 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66H0bSB004271 for ; Wed, 6 Jul 2005 10:00:37 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j66H0bYE004267 for ; Wed, 6 Jul 2005 10:00:37 -0700 Message-Id: <200507061700.j66H0bYE004267@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: about the first entry in the log file format Date: Wed, 06 Jul 2005 10:00:37 -0700 From: william@bourbon.usc.edu Someone wrote: > I am confused with 'f (forward)' in the log file format. > I'd like to clarify the following situation. > > (1) The node A sends join message to the node B. > (2) Then, node B floods join message to the node C and D. > (3) After that, node B receives join response messages from node C and D. > (4) The node B sends (forwards) the received join response messages to the > node A. > > In step (2), node B writes two log messages starting with the 'f (forward)' > In step (4), node B writes two log messages starting with the 's (send)', > not 'f (forward)' Forwarding is what a router do. Sending is about generating something. So, in your example, (2) and (4) are all forwarding because node B did not generating anything. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 09:54:10 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j66GsAja024271 for ; Wed, 6 Jul 2005 09:54:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66GvTSB004234 for ; Wed, 6 Jul 2005 09:57:29 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j66GvTlr004232 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 09:57:29 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66GvTSB004229 for ; Wed, 6 Jul 2005 09:57:29 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j66GvTP9004225 for ; Wed, 6 Jul 2005 09:57:29 -0700 Message-Id: <200507061657.j66GvTP9004225@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: redundancy in .out file Date: Wed, 06 Jul 2005 09:57:29 -0700 From: william@bourbon.usc.edu Someone wrote: > Are we allowed to have dupilcates in our status.out file > ( nam will take care of this though....) It's not as good as not having duplicates. (Isn't this very easy to do?) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Wed Jul 6 09:51:53 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j66Gprja024084 for ; Wed, 6 Jul 2005 09:51:53 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66GtCSB004189 for ; Wed, 6 Jul 2005 09:55:12 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j66GtCfR004187 for cs551@merlot.usc.edu; Wed, 6 Jul 2005 09:55:12 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66GtCSB004184 for ; Wed, 6 Jul 2005 09:55:12 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j66GtChK004180 for ; Wed, 6 Jul 2005 09:55:12 -0700 Message-Id: <200507061655.j66GtChK004180@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: configuration file and homedirectory Date: Wed, 06 Jul 2005 09:55:12 -0700 From: william@bourbon.usc.edu Someone wrote: | > > For other files like init_neighbor_list, cache files, and | > > permanent files, it can be in other directory which is specified | > > in homedir? | > | > It *must* be in the directory specified by HomeDir. | | In command line, if you enter 'status neighbors 10 node.out', is the file, | node.out, saved under the HomeDir, too? node.out must be saved in the current working directory. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 5 23:46:50 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j666koja027498 for ; Tue, 5 Jul 2005 23:46:50 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j666oBSB000761 for ; Tue, 5 Jul 2005 23:50:11 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j666oBUq000759 for cs551@merlot.usc.edu; Tue, 5 Jul 2005 23:50:11 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j666oBSB000756 for ; Tue, 5 Jul 2005 23:50:11 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j666oBO7000752 for ; Tue, 5 Jul 2005 23:50:11 -0700 Message-Id: <200507060650.j666oBO7000752@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Segmentation fault!! Date: Tue, 05 Jul 2005 23:50:11 -0700 From: william@bourbon.usc.edu Someone wrote: > I know you cannot debug code... but I am at my wits end > figuring this out.... > > I get segmentation fault at: > > char* xx=new char[25]; > > could you tell me possible reasons? Please read the following *carefully*: http://merlot.usc.edu/cs551-m05/projects.html#segfault -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 5 20:10:05 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j663A5ja017455 for ; Tue, 5 Jul 2005 20:10:05 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j663DQSB032474 for ; Tue, 5 Jul 2005 20:13:26 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j663DQMp032472 for cs551@merlot.usc.edu; Tue, 5 Jul 2005 20:13:26 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j663DQSB032469 for ; Tue, 5 Jul 2005 20:13:26 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j663DQWv032465 for ; Tue, 5 Jul 2005 20:13:26 -0700 Message-Id: <200507060313.j663DQWv032465@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: hex string format in log file Date: Tue, 05 Jul 2005 20:13:26 -0700 From: william@bourbon.usc.edu Someone wrote: > The spec says we should write the last 4 bytes in hex string format in the > field. Here, what's the exact meaning of hex string format? A N bytes array of octats starting at location X is displayed by writing out X[0], X[1], X[2], ..., X[N-1], where X[i] is displayed as 2 ASCII characters, the first character is the hex representation of the most significant 4 bits of X[i] and the 2nd character is the hex representation of the least significant 4 bits of X[i]. If Z is a 4-bit number, the hex representation of Z is: switch (Z) { case 0x00: return '0'; case 0x01: return '1'; case 0x02: return '2'; case 0x03: return '3'; case 0x04: return '4'; case 0x05: return '5'; case 0x06: return '6'; case 0x07: return '7'; case 0x08: return '8'; case 0x09: return '9'; case 0x0a: return 'a'; case 0x0b: return 'b'; case 0x0c: return 'c'; case 0x0d: return 'd'; case 0x0e: return 'e'; case 0x0f: return 'f'; } > If the last 4 bytes are 0xab, 0x30, 0x10, and 0x11, then which is correct > the following: > (1) ab301011 > (2) 0xab301011 > (3) 0xab 0x30 0x10 0x11 (1) would be correct. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 5 19:57:49 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j662vnja016771 for ; Tue, 5 Jul 2005 19:57:49 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j6631ASB032421 for ; Tue, 5 Jul 2005 20:01:10 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j6631Aq7032419 for cs551@merlot.usc.edu; Tue, 5 Jul 2005 20:01:10 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j66319SB032416 for ; Tue, 5 Jul 2005 20:01:09 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j663199G032412 for ; Tue, 5 Jul 2005 20:01:09 -0700 Message-Id: <200507060301.j663199G032412@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Is the case important in INI file? Date: Tue, 05 Jul 2005 20:01:09 -0700 From: william@bourbon.usc.edu Someone wrote: > You said that the case for the command was ignored. (i.e, 'status neighbors' > is equal to 'STATUS NEIGHBORS'.) Hmm... I don't think I've ever said that. It was intended that the commands are all lowercase. This is done in all examples in the spec. > How about the keys in the INI file? > For example, is the 'port' acceptable as well as the 'Port'? Yes. Everything in INI files are case-insensitive. (The INI file format was from Windows and this is the way Windows has been since the beginning.) > The reason why I ask is there are port and homedir, not Port and HomeDir, in > the test cases. I cannot find these test cases. For grading, I will use what's in the spec. So, I will use "Port" and "HomeDir". -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 5 17:26:20 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j660QKja009858 for ; Tue, 5 Jul 2005 17:26:20 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j660TfSB031926 for ; Tue, 5 Jul 2005 17:29:41 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j660Tf6U031924 for cs551@merlot.usc.edu; Tue, 5 Jul 2005 17:29:41 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j660TfSB031921 for ; Tue, 5 Jul 2005 17:29:41 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j660Tf4Q031917 for ; Tue, 5 Jul 2005 17:29:41 -0700 Message-Id: <200507060029.j660Tf4Q031917@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: review & Question on lecture 10 Date: Tue, 05 Jul 2005 17:29:41 -0700 From: william@bourbon.usc.edu Someone wrote: > Although you said in the last lecture that you are not planning > to give out a midterm review session, I just want to know whether > this is still the case (so tomorrow won't be a review session, > although I think it is better to have one :) ). What I did for reviews was to basically run through the list of topics in the News section of the class web page. It was short and I don't think it was very useful. That's why I decided not to do it. > Question on Lecture 10 (PDF) (6-up PDF) (Jun 22, 2005) - landmark > routing [Tsuchiya88a], review of TCP, TCP congestion control, > slide # 5. > > There are 3 level at that picture, LM0 - LM2. I just want to know > whether is it possible to have 3 LM1 nodes instead of 2 LM1 and 1 > LM2 nodes. Actually, there are 3 LM1 nodes and one LM2 node in slide 5. d.d.d is both LM1 and LM2 (and also LM0). > For example, assume d.d.d is LM1 not LM2 and it wants > to send out packet to d.n.p, it can just send to either d.i.i or > d.n.n and let them do the routing right? so if this is the case > we don't really need LM2 in this case? If you only have 3 LM1 nodes (d, i, and n), then you don't have any global landmark (and it's required to have global landmark). Then the name of all nodes will be LM1.LM0. So, d.d.d will be just d.d and d.n.n will just be n.n (and d.n.p will be just n.p). Although d.d can still send a message to n.p, it's not possible to send a message from n.p to d.d because d is not in n.p's routing table! -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Tue Jul 5 07:55:05 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j65Et4ja015901 for ; Tue, 5 Jul 2005 07:55:04 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j65EwRSB028109 for ; Tue, 5 Jul 2005 07:58:27 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j65EwR1W028107 for cs551@merlot.usc.edu; Tue, 5 Jul 2005 07:58:27 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j65EwRSB028104 for ; Tue, 5 Jul 2005 07:58:27 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j65EwRBX028100 for ; Tue, 5 Jul 2005 07:58:27 -0700 Message-Id: <200507051458.j65EwRBX028100@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Data Length field of header Date: Tue, 05 Jul 2005 07:58:27 -0700 From: william@bourbon.usc.edu Someone wrote: > Does the Data Length field include the size of the header (27 bytes + > data) or just the message data? The spec says: Data Length: The length of the function-dependent data. So, it does not include the header. (The smallest value of this field is zero.) -- Bill Cheng // bill.cheng@usc.edu Return-Path: william@bourbon.usc.edu Delivery-Date: Tue Jul 5 07:52:51 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j65Eqpja015757 for ; Tue, 5 Jul 2005 07:52:51 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j65EuDSB028016 for ; Tue, 5 Jul 2005 07:56:13 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j65EuDUW028012 for ; Tue, 5 Jul 2005 07:56:13 -0700 Message-Id: <200507051456.j65EuDUW028012@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: What to do? Date: Tue, 05 Jul 2005 07:56:13 -0700 From: william@bourbon.usc.edu Someone wrote: > I haven't implemented the following yet: > > 1) Join Message [I have only tested "beacon-only" networks > with Hello, Status/Status Resp and keepalive Messages] > > 2) Converting the status responses in NAM output > > 3) I am currently storing UOIDs in a liner list.... Binary Search > not implemented. > > What should I be doing next. Logically it should be Join > message.... but is it more imp to get the NAM output for > status responses. I still have to learn NAM. I dont think > I ll have time to implement binary search... > > Please advise. I would do (2) first because without it, your status responses will be hard to grade and will receive little credit. Also, this should be very easy because there's really nothing much to learn about NAM. It's not clear to me whether to do (1) or (3) next. Not doing (1) will probably cost your more points for part (1). But you will need BST for part (2), so you will have to learn to use it sooner or later. -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 4 21:20:15 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j654KFja016705 for ; Mon, 4 Jul 2005 21:20:15 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j654NcSB025813 for ; Mon, 4 Jul 2005 21:23:38 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j654NcwV025811 for cs551@merlot.usc.edu; Mon, 4 Jul 2005 21:23:38 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j654NcSB025808 for ; Mon, 4 Jul 2005 21:23:38 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j654NcXF025804 for ; Mon, 4 Jul 2005 21:23:38 -0700 Message-Id: <200507050423.j654NcXF025804@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: Status Message Date: Mon, 04 Jul 2005 21:23:38 -0700 From: william@bourbon.usc.edu Someone wrote: > What should be the TTL of status response? There is only one value for the initial TTL and that comes from the startup configuration file. > Are we supposed to send info about nodes of which current node is > a Neighbor > For Example. Node A is in Node B's init neighbor list but not > vice versa. Should the status response from A include information > about B? Yes. It gives information about connected neighbors. > If Not so…. > What if a node (Single Beacon) has no neighbors (By definition – > a Beacon's neighbors are other Beacons) - Would the status > response message be empty after “Record Length”=0; Exactly. (In this case, this is also the node where the user sits. So, if the user sits at node X and enter the "status neighbors" command, node X must also respond!) -- Bill Cheng // bill.cheng@usc.edu Return-Path: cs551@bourbon.usc.edu Delivery-Date: Mon Jul 4 07:37:37 2005 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.12.8/8.12.8) with ESMTP id j64Ebbja010808 for ; Mon, 4 Jul 2005 07:37:37 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j64Ef2SB023739 for ; Mon, 4 Jul 2005 07:41:02 -0700 Received: (from cs551@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) id j64Ef2xl023737 for cs551@merlot.usc.edu; Mon, 4 Jul 2005 07:41:02 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.12.8/8.12.8) with ESMTP id j64Ef2SB023734 for ; Mon, 4 Jul 2005 07:41:02 -0700 Received: from bourbon.usc.edu (william@localhost) by bourbon.usc.edu (8.12.8/8.12.8/Submit) with ESMTP id j64Ef2Wl023730 for ; Mon, 4 Jul 2005 07:41:02 -0700 Message-Id: <200507041441.j64Ef2Wl023730@bourbon.usc.edu> To: cs551@bourbon.usc.edu Subject: Re: log file format Date: Mon, 04 Jul 2005 07:41:02 -0700 From: william@bourbon.usc.edu Someone wrote: > The log file format for a message sent is > s