From asyed at usc.edu Sun Apr 3 07:37:34 2005 From: asyed at usc.edu (Affan, Syed) Date: Sun Apr 3 07:39:51 2005 Subject: [Csci551-talk] TA office hours canceled Message-ID: <000201c5385a$b0cf39b0$0300a8c0@A2D> Hello everyone, This weeks TA office hours are being cancelled. To compensate I will hold an extra hour next Tuesday. Thank you. Best Regards, Affan, Syed. From johnh at ISI.EDU Sat Apr 9 10:43:52 2005 From: johnh at ISI.EDU (John Heidemann) Date: Sat Apr 9 10:45:33 2005 Subject: [Csci551-talk] syllabus change Message-ID: <200504091743.j39Hhqk5011764@dash.isi.edu> For next week, please consider paper [Kuzmanovic03b] moved to supplemental. -John Heidemann From johnh at ISI.EDU Mon Apr 11 10:12:48 2005 From: johnh at ISI.EDU (John Heidemann) Date: Mon Apr 11 10:14:42 2005 Subject: [Csci551-talk] project b Message-ID: <200504111712.j3BHCmZN003165@dash.isi.edu> Project B has been posted to the class web site. For folks considering using the class implementation of Project A, code will be released later this week. -John Heidemann From srubin at flash.net Mon Apr 11 13:30:41 2005 From: srubin at flash.net (S. Rubin) Date: Mon Apr 11 13:32:48 2005 Subject: [Csci551-talk] clarifications request Message-ID: <20050411203041.16090.qmail@web81304.mail.yahoo.com> Please clarify 3 areas: 1. What is meant by [id] in the formula for algorithm T? It is not a peer number, right, since we don't select a peer unitl we decide on the segment number? 2. What is meant by "levels of freeloaders" in section 4, just above the sample config file? Is it how many freeloaders are specified in config file? 3. Are "Queston for README" references in parts A and B is what will end up in the Expected result, Observed result, etc. of the README file? Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050411/53fdc1dd/attachment.html From rmchandr at usc.edu Mon Apr 11 14:25:10 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Mon Apr 11 14:27:17 2005 Subject: [Csci551-talk] Random segment selection in Project A ? Message-ID: <43308c031fa9e.425a88c6@usc.edu> As can be seen from the below mails during discussions for Project A, we had concluded that segments need not be selected randomly but only peers need to be selected randomly for Project A. But the spec for Project B, on page 2 says we were supposed to have selected the segment and the peer randomly. I hope students who didnt follow random segment selection after reading this mail, will not be penalized. Please clarify. Regards, Rashmi. -------------- next part -------------- An embedded message was scrubbed... From: "Affan, Syed" Subject: RE: [Csci551-talk] Random peer selection and/or segment selection? Date: Tue, 22 Mar 2005 23:18:48 -0800 Size: 3217 Url: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050411/58c5825d/attachment.mht From nikhilbh at usc.edu Mon Apr 11 16:50:40 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Mon Apr 11 16:51:53 2005 Subject: [Csci551-talk] Proj B Message-ID: In the Project B Doc, Phase 7 sample config file does include the algorithm selection configuration . Are we supoosed to have diffrent configuration files for Phases in Proj B or is it a Typo ? -Nikhil Bhatia From srubin at flash.net Mon Apr 11 22:29:23 2005 From: srubin at flash.net (S. Rubin) Date: Mon Apr 11 22:30:43 2005 Subject: [Csci551-talk] packet drop question Message-ID: <20050412052923.7682.qmail@web81305.mail.yahoo.com> Is it correct to assume that we should still be able to handle packet drop probability, so our condition for dropping should be either probability criteria is met or the guy is a freeloader? If yes, then the number of packets dropped will be the sum of those? Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050411/0e6cf7e4/attachment.html From asyed at usc.edu Mon Apr 11 22:38:50 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 11 22:40:34 2005 Subject: [Csci551-talk] packet drop question In-Reply-To: <20050412052923.7682.qmail@web81305.mail.yahoo.com> Message-ID: <000301c53f21$ebdc9660$0300a8c0@A2D> Yes you should be able to. note that the drop probability is at the sender, while the freelloader decides on receiving the packet that it should be dropped. However, from the log files the senders log file would not be different! Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of S. Rubin Sent: Monday, April 11, 2005 10:29 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] packet drop question Is it correct to assume that we should still be able to handle packet drop probability, so our condition for dropping should be either probability criteria is met or the guy is a freeloader? If yes, then the number of packets dropped will be the sum of those? Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050411/19b39d88/attachment.html From cychung at gmail.com Mon Apr 11 23:17:35 2005 From: cychung at gmail.com (Clarence Chung) Date: Mon Apr 11 23:18:33 2005 Subject: [Csci551-talk] Project 2 bandwidth limit question Message-ID: <430859e405041123171ebb6753@mail.gmail.com> I believe in Project A, the simulation of transmission delay is applied ONLY to "REPLY" message, but not "REQUEST" messages. Now in Project B, from looking at the example given at the end of section 2, it seems like the delay applies to all the outgoing message, including "REQUEST" and "REPLY" messages, in the addition of the new bandwidth requirment. Is this a correct interpretation of the spec? Clarence From nikhilbh at usc.edu Tue Apr 12 01:03:07 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Tue Apr 12 01:03:36 2005 Subject: [Csci551-talk] Re:packet drop question Message-ID: I dont think ALL the packets should be dropped by the freeloader. Packets of type seg_reply and info reply should be accepted. Also the message have to be logged by the freeloader as *REFUSED* for info request. I hope it helps . -Nikhil Bhatia Reply To:- Yes you should be able to. note that the drop probability is at the sender, while the freelloader decides on receiving the packet that it should be dropped. However, from the log files the senders log file would not be different! Best Regards, Affan, Syed. S. Rubin srubin at flash.net Mon Apr 11 22:29:23 PDT 2005 Is it correct to assume that we should still be able to handle packet drop probability, so our condition for dropping should be either probability criteria is met or the guy is a freeloader? If yes, then the number of packets dropped will be the sum of those? Sophia From nikhilbh at usc.edu Tue Apr 12 01:08:15 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Tue Apr 12 01:08:34 2005 Subject: [Csci551-talk] Proj B Message-ID: I misssed out the NOT (as crrected below) in my earlier post. In the Project B Doc, Phase 7 sample config file does NOT include the algorithm selection configuration . Are we supoosed to have diffrent configuration files for Phases in Proj B or is it a Typo ? -Nikhil Bhatia From asyed at usc.edu Tue Apr 12 07:29:51 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 07:31:36 2005 Subject: [Csci551-talk] Extra office hours Message-ID: <000d01c53f6c$1cf8c350$0300a8c0@A2D> I will be holding extra offcie hours from 12:00 to 2:00pm tpday. Best Regards, Affan, Syed. From asyed at usc.edu Tue Apr 12 07:37:11 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 07:38:32 2005 Subject: [Csci551-talk] Proj B In-Reply-To: Message-ID: <000e01c53f6d$217c3320$0300a8c0@A2D> Yes, That seems to be a typo. I will correct it. Thank you for pointing this out. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of nikhil bhatia Sent: Tuesday, April 12, 2005 1:08 AM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Proj B I misssed out the NOT (as crrected below) in my earlier post. In the Project B Doc, Phase 7 sample config file does NOT include the algorithm selection configuration . Are we supoosed to have diffrent configuration files for Phases in Proj B or is it a Typo ? -Nikhil Bhatia From asyed at usc.edu Tue Apr 12 07:39:30 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 07:40:33 2005 Subject: [Csci551-talk] Re:packet drop question In-Reply-To: Message-ID: <001001c53f6d$74609900$0300a8c0@A2D> Very true.. Because the freeloader that doesn't get anything for itself.. Is not even a free loader :). Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of nikhil bhatia Sent: Tuesday, April 12, 2005 1:03 AM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Re:packet drop question I dont think ALL the packets should be dropped by the freeloader. Packets of type seg_reply and info reply should be accepted. Also the message have to be logged by the freeloader as *REFUSED* for info request. I hope it helps . -Nikhil Bhatia Reply To:- Yes you should be able to. note that the drop probability is at the sender, while the freelloader decides on receiving the packet that it should be dropped. However, from the log files the senders log file would not be different! Best Regards, Affan, Syed. S. Rubin srubin at flash.net Mon Apr 11 22:29:23 PDT 2005 Is it correct to assume that we should still be able to handle packet drop probability, so our condition for dropping should be either probability criteria is met or the guy is a freeloader? If yes, then the number of packets dropped will be the sum of those? Sophia From asyed at usc.edu Tue Apr 12 12:24:04 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 12:25:43 2005 Subject: [Csci551-talk] Project 2 bandwidth limit question In-Reply-To: <430859e405041123171ebb6753@mail.gmail.com> Message-ID: <000901c53f95$346e2d80$aa867d80@A2D> Hi, You are right. Request and both reply need to be delayed in projb. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Clarence Chung Sent: Monday, April 11, 2005 11:18 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Project 2 bandwidth limit question I believe in Project A, the simulation of transmission delay is applied ONLY to "REPLY" message, but not "REQUEST" messages. Now in Project B, from looking at the example given at the end of section 2, it seems like the delay applies to all the outgoing message, including "REQUEST" and "REPLY" messages, in the addition of the new bandwidth requirment. Is this a correct interpretation of the spec? Clarence From asyed at usc.edu Tue Apr 12 13:02:05 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 13:04:45 2005 Subject: [Csci551-talk] Proj A sample code out Message-ID: <000c01c53f9a$84329c70$aa867d80@A2D> Please visit TA website for proj A sample code http://www-scf.usc.edu/~asyed/cs551.html Best Regards, Affan, Syed. From asyed at usc.edu Tue Apr 12 13:09:19 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 13:10:37 2005 Subject: [Csci551-talk] clarifications request In-Reply-To: <20050411203041.16090.qmail@web81304.mail.yahoo.com> Message-ID: <000d01c53f9b$86afdc00$aa867d80@A2D> Please clarify 3 areas: 1. What is meant by [id] in the formula for algorithm T? It is not a peer number, right, since we don't select a peer unitl we decide on the segment number? Its the nodeId. 2. What is meant by "levels of freeloaders" in section 4, just above the sample config file? Is it how many freeloaders are specified in config file? So make it difference percentages of freeloaders. Say in a 20 node network make it 2,5, or 10 freeloaders. 3. Are "Queston for README" references in parts A and B is what will end up in the Expected result, Observed result, etc. of the README file? hmmm... I think the comparisons will be both in what you expect and what you actually see. Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050412/7db23a42/attachment.html From asyed at usc.edu Tue Apr 12 13:10:19 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 12 13:12:35 2005 Subject: [Csci551-talk] Random segment selection in Project A ? In-Reply-To: <43308c031fa9e.425a88c6@usc.edu> Message-ID: <001201c53f9b$aab13c70$aa867d80@A2D> No they will not be! Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of rashmi chandrasekhar Sent: Monday, April 11, 2005 2:25 PM To: csci551-talk@ISI.EDU Subject: [Csci551-talk] Random segment selection in Project A ? As can be seen from the below mails during discussions for Project A, we had concluded that segments need not be selected randomly but only peers need to be selected randomly for Project A. But the spec for Project B, on page 2 says we were supposed to have selected the segment and the peer randomly. I hope students who didnt follow random segment selection after reading this mail, will not be penalized. Please clarify. Regards, Rashmi. From srubin at flash.net Tue Apr 12 22:05:48 2005 From: srubin at flash.net (S. Rubin) Date: Tue Apr 12 22:06:38 2005 Subject: [Csci551-talk] trial algorithm Message-ID: <20050413050548.14252.qmail@web81310.mail.yahoo.com> I am not clear on the trial algorithm. Once we pick the starting segment number according to the algorithm, does it matter which algorithm we use for subsequent segments (random or sequential)? Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050412/463e2ce9/attachment.html From asyed at usc.edu Wed Apr 13 13:39:11 2005 From: asyed at usc.edu (Affan, Syed) Date: Wed Apr 13 13:41:05 2005 Subject: [Csci551-talk] Updated project description Message-ID: <000001c54068$ddb4b070$0300a8c0@A2D> Update avaliable at TA website. Best Regards, Affan, Syed. From xiw at usc.edu Wed Apr 13 18:58:39 2005 From: xiw at usc.edu (Xi Wang) Date: Wed Apr 13 19:01:45 2005 Subject: [Csci551-talk] Re: [Cs551] Doubt regarding Algorithm T In-Reply-To: References: Message-ID: <425DCE4F.5000804@usc.edu> You are free to design your own method for this case. Please document it in README. We think some reasonable approaches are: 1. skip sequentially to the next viable segment 2. timeout and retry when more peers are on-line (since once the seed is online every segment will be covered -Xi Rohith Mark Varghese wrote: > Hi, > > I have a small doubt on how we are supposed to implement Algo T. > > Assume the following scenario: > Node 2 is a seed i.e. it has the entire file > Node 1 has segments 4,5,6,7,8 (he is downloading segments sequentially > from segment 4 onwards) > Node 0 is beginning his life in our system. He is expected to download > segnemts sequentially from segment 1 onwards. He's recieved INFO_REPLY > only from node 1, since node 2 probabilistically dropped his reply packet. > > Now, since node 0 has only node 1as a neighbor, should he request > segments 4 to 8 from node 1 and get segments 1 to 3 later; or should he > simply keep mum for this cycle because he is expected to download > segments sequentially from segment 1 onwards? > > Thanks, > > Mark > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cs551 mailing list > Cs551@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/cs551 From johnh at ISI.EDU Wed Apr 13 21:17:49 2005 From: johnh at ISI.EDU (John Heidemann) Date: Wed Apr 13 21:19:07 2005 Subject: [Csci551-talk] Re: [Cs551] Updated project description In-Reply-To: <000001c54068$ddb4b070$0300a8c0@A2D> Message-ID: <200504140417.j3E4HnRS013702@dash.isi.edu> This is now on my website as well so there should be no confusion. (Note that there it's called projb_r2.pdf.) -John Heidemann On Wed, 13 Apr 2005 13:39:11 PDT, "Affan, Syed" wrote: >Update avaliable at TA website. > >Best Regards, >Affan, Syed. > > > >_______________________________________________ >Cs551 mailing list >Cs551@catarina.usc.edu >http://catarina.usc.edu/mailman/listinfo/cs551 From nikhilbh at usc.edu Thu Apr 14 03:29:37 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Thu Apr 14 03:30:42 2005 Subject: [Csci551-talk] Security in Freebits Message-ID: Please note this feature is NOT IN THE PROJECT REQUIREMENT. Read if you have some spare time. There can be an interesting issue " to get rid of FREELOADERS" However this problem is not as easy(to me :) ) as it looks. One of the ways could be that if a node detects a greedy node it could reject requests from that node. Again how to decide that if the node is greedy . One of the simplest ways could be a handshake or a encrypted message .We could have a secret code embedded in those nodes which are official(manager.conf) So if a new node tries to freeload no one would reply Now another interesting which could be added is that freeloader will try out of a list of codes and try to hack the system. so there would be a fight between the freeloaders and official nodes...n we can have fun ( :) ) any comments ... -Nikhil Bhatia From srubin at flash.net Thu Apr 14 09:35:52 2005 From: srubin at flash.net (S. Rubin) Date: Thu Apr 14 09:37:44 2005 Subject: [Csci551-talk] RE:Security in Freebits Message-ID: <20050414163552.28117.qmail@web81302.mail.yahoo.com> I understand freeloaders to be "official" nodes listed in manager.conf, but who would refuse to share their segments with others. Some bookeepng mechanism could be implemented to simply keep track of %dowloads vs. %shared, and the rating could be done based on these stats. The more he is willing to share the higher his ratings are and vice versa. I am not sure why security would be an issue here; you could do admission control of some sort, if there is a need for access restriction. I might have misunderstood the intent of your message, but it is an interesting subject. Sophia Please note this feature is NOT IN THE PROJECT REQUIREMENT. Read if you have some spare time. There can be an interesting issue " to get rid of FREELOADERS" However this problem is not as easy(to me :) ) as it looks. One of the ways could be that if a node detects a greedy node it could reject requests from that node. Again how to decide that if the node is greedy . One of the simplest ways could be a handshake or a encrypted message .We could have a secret code embedded in those nodes which are official(manager.conf) So if a new node tries to freeload no one would reply Now another interesting which could be added is that freeloader will try out of a list of codes and try to hack the system. so there would be a fight between the freeloaders and official nodes...n we can have fun ( :) ) any comments ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050414/de79e6c6/attachment.html From nikhilbh at usc.edu Thu Apr 14 13:08:45 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Thu Apr 14 13:09:57 2005 Subject: [Csci551-talk] Re:Security in Freebits Message-ID: Sophia, I was not expecting any replies on my quest. Nice to see your reply :) I am reffering to a hypothetical situation. manager.conf if just to simulate the feature we indend to have in our p2p system. We could also have a freeloader spawned separately which somehow knows the tracker ip/port. Well essentially we could have a "freeloader.conf" which would spawn freeloader in the network.These freeloader essentially could be "high energy" nodes more efficient than other nodes. Well another idea, we could have energy as a parameter. Which will reduce every communication/computation iteration (sum of packets->sent, packets->rcvd, we could also ignore computation cost as comm costs form majority of enerfy consuption) As it is just a simulation we need to provide some configuration where we define official nodes as non freeloaders. I hope you understand what I want tp convey. -Nikhil Bhatia From johnh at ISI.EDU Thu Apr 14 15:04:04 2005 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 14 15:04:50 2005 Subject: [Csci551-talk] midterm answers Message-ID: <200504142204.j3EM441h018958@dash.isi.edu> A set of answers to the midterm have been posted to the class web site. -John Heidemann From junghlee at usc.edu Fri Apr 15 22:12:15 2005 From: junghlee at usc.edu (jung lee) Date: Fri Apr 15 22:12:49 2005 Subject: [Csci551-talk] Is the sample code meant to work? Message-ID: Hello, If I use the sample code as it is posted on the web, it doesn't even parse the valid manager.conf file correctly. Am I doing something wrong? Following while statement strlen(buf) <3 will skip to read number of client. int CParser::getgoodlinene(char *buf) { do { if (fgets(buf, BUFFSIZE, fp) == NULL) { return 1; } } while (buf[0] == '#' || buf[0] == 10 || buf[0] == 13 || strlen(buf) <3); return 0; } From srubin at flash.net Fri Apr 15 23:05:02 2005 From: srubin at flash.net (S. Rubin) Date: Fri Apr 15 23:05:55 2005 Subject: [Csci551-talk] RE: Is the sample code meant to work? Message-ID: <20050416060502.72927.qmail@web81304.mail.yahoo.com> Are you using the manager.conf from project A? If not, then you need to modify parser.cpp first to make it recognize additional fields. If yes, make sure that it is formatted as shown in project A requirements paper. Sophia > If I use the sample code as it is posted on the web, it doesn't even parse the valid >manager.conf file correctly. > Am I doing something wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050415/1165fd42/attachment.html From junghlee at usc.edu Fri Apr 15 23:21:30 2005 From: junghlee at usc.edu (jung lee) Date: Fri Apr 15 23:21:54 2005 Subject: [Csci551-talk] RE: Is the sample code meant to work? Message-ID: I'm using manager.conf from project A, and I didn't make any change to the sample code. So, if the sample code is meant to work, it should work without any change with valid manager.conf file as far as project A is concerned. Making parser work correctly is not a big deal but if the sample code has some hard bug in it, then we might spend more time on fixing the bug. Oh well, I couldn't finish project A, so I guess I have to use it anyway =) ----- Original Message ----- From: "S. Rubin" Date: Friday, April 15, 2005 11:05 pm Subject: [Csci551-talk] RE: Is the sample code meant to work? > > Are you using the manager.conf from project A? If not, then you > need to modify > > parser.cpp first to make it recognize additional fields. If yes, > make sure that it > > is formatted as shown in project A requirements paper. > > Sophia > > > If I use the sample code as it is posted on the web, it doesn't > even parse the valid >manager.conf file correctly. > > Am I doing something wrong? > > > From srubin at flash.net Fri Apr 15 23:37:46 2005 From: srubin at flash.net (S. Rubin) Date: Fri Apr 15 23:38:49 2005 Subject: [Csci551-talk] RE: Is the sample code meant to work? Message-ID: <20050416063747.29536.qmail@web81310.mail.yahoo.com> But for project A the FIRST valid line WAS the number of clients. It skips over comment lines and blank lines by design. '#' signifies comment line, buf[0] == 10 (carriage return char), buf[0] == 13 (new line char) I did not test the code myself as mine is written in C, but we all have seen the sample outputs from this code posted on the TA's web site. Sophia >I'm using manager.conf from project A, and I didn't make any change to the sample code. >So, if the sample code is meant to work, it should work without any change with valid >manager.conf file as far as project A is concerned. Making parser work correctly is not a big >deal but if the sample code has some hard bug in it, then we might spend more time on fixing >the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050415/bd3dee00/attachment.html From xiw at usc.edu Sat Apr 16 00:19:24 2005 From: xiw at usc.edu (Xi Wang) Date: Sat Apr 16 00:22:51 2005 Subject: [Csci551-talk] RE: Is the sample code meant to work? In-Reply-To: <20050416063747.29536.qmail@web81310.mail.yahoo.com> References: <20050416063747.29536.qmail@web81310.mail.yahoo.com> Message-ID: <4260BC7C.1000509@usc.edu> Seems an earlier version of parser.cpp is released instead of the final version. You can simply change the following function at the beginning of the file. (Note while loop condition is changed.) -Xi int CParser::getgoodlinene(char *buf) { do { if (fgets(buf, BUFFSIZE, fp) == NULL) { return 1; } } while (buf[0] == '#' || buf[0] == 10 || buf[0] == 13 || buf[0] == 0); return 0; } S. Rubin wrote: > But for project A the FIRST valid line WAS the number of clients. It > skips over > > comment lines and blank lines by design. > > '#' signifies comment line, buf[0] == 10 (carriage return char), > buf[0] == 13 (new line char) > > I did not test the code myself as mine is written in C, but we all have > seen the sample > > outputs from this code posted on the TA's web site. > > Sophia > > >I'm using manager.conf from project A, and I didn't make any change to > the sample code. > >So, if the sample code is meant to work, it should work without any > change with valid >manager.conf file as far as project A is concerned. > Making parser work correctly is not a big >deal but if the sample code > has some hard bug in it, then we might spend more time on fixing >the bug. > From asyed at usc.edu Sat Apr 16 08:41:04 2005 From: asyed at usc.edu (Affan, Syed) Date: Sat Apr 16 08:42:53 2005 Subject: [Csci551-talk] Patched project tarball Message-ID: <000001c5429a$b806fe30$0300a8c0@A2D> The patch that was mentioned by Xi last night has been incorporated on the tarball present at the TA ite. Kildly get this from http://www-scf.usc.edu/~asyed/551prj.tar.gz Best Regards, Affan, Syed. From asyed at usc.edu Sat Apr 16 15:58:30 2005 From: asyed at usc.edu (Affan, Syed) Date: Sat Apr 16 16:00:56 2005 Subject: [Csci551-talk] Project 2 bandwidth limit question In-Reply-To: <430859e405041614383e17538c@mail.gmail.com> Message-ID: <000101c542d7$d3761420$0300a8c0@A2D> Very good question.. Yes, you need to do that, b/c we want to simulate the packet loss on the link - not that the sender doesn't send it at all :). Best Regards, Affan, Syed. -----Original Message----- From: Clarence Chung [mailto:cychung@gmail.com] Sent: Saturday, April 16, 2005 2:38 PM To: Affan, Syed Subject: Re: [Csci551-talk] Project 2 bandwidth limit question If a node is dropping an out going message, should the node wait for the tx delay for that message before sending out the next message? clarence On 4/12/05, Affan, Syed wrote: > Hi, > You are right. Request and both reply need to be delayed in projb. > > Best Regards, > Affan, Syed. > > > -----Original Message----- > From: csci551-talk-bounces@mailman.isi.edu > [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Clarence > Chung > Sent: Monday, April 11, 2005 11:18 PM > To: csci551-talk@mailman.isi.edu > Subject: [Csci551-talk] Project 2 bandwidth limit question > > I believe in Project A, the simulation of transmission delay is > applied ONLY to "REPLY" message, but not "REQUEST" messages. Now in > Project B, from looking at the example given at the end of section 2, > it seems like the delay applies to all the outgoing message, including > "REQUEST" and "REPLY" messages, in the addition of the new bandwidth > requirment. Is this a correct interpretation of the spec? > > Clarence > > From srubin at flash.net Sat Apr 16 16:49:53 2005 From: srubin at flash.net (S. Rubin) Date: Sat Apr 16 16:50:54 2005 Subject: [Csci551-talk] odd time delay values Message-ID: <20050416234953.89702.qmail@web81308.mail.yahoo.com> I am priniting out time stamps in msec (using timeval struct values and converting them to msec) prior to causing delays to occur, and then again in the time expiration routine just before each message is sent. As can be seen from the print statements below my delays are set correctly, but when I print the actual time differences, I do not see the expected delay values (see the result of subtraction). Any explanation? segment: 5, will delay by: 05, current time (msec): 1298317713 segment: 0, will delay by: 10, current time (msec): 1298317714 segment: 4, will delay by: 15, current time (msec): 1298317715 segment: 7, will delay by: 20, current time (msec): 1298317716 segment: 2, will delay by: 25, current time (msec): 1298317717 segment: 3, will delay by: 30, current time (msec): 1298317720 segment: 6, will delay by: 35, current time (msec): 1298317726 segment: 1, will delay by: 40, current time (msec): 1298317732 sending segment: 5, current time 1298317732 - original time 1298317713 = 19 (msec) sending segment: 0, current time 1298317942 - original time 1298317714 = 228 (msec) sending segment: 4, current time 1298318285 - original time 1298317715 = 570 (msec) sending segment: 7, current time 1298318736 - original time 1298317716 = 1020 (msec) sending segment: 2, current time 1298319165 - original time 1298317717 = 1448 (msec) sending segment: 3, current time 1298319607 - original time 1298317720 = 1887 (msec) sending segment: 6, current time 1298320051 - original time 1298317726 = 2325 (msec) sending segment: 1, current time 1298320671 - original time 1298317732 = 2939 (msec) Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050416/78d8c624/attachment.html From asyed at usc.edu Mon Apr 18 06:01:28 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 18 06:02:57 2005 Subject: [Csci551-talk] FW: Re-grading office hour and email requests Message-ID: <003b01c54416$c09867f0$0300a8c0@A2D> The following is from your grader for the proj A ------------------ Dear CS551 class. While setting up an appropriate office for the graders re-grading office hour, the grader will first take online email re-grading requests. Please send your re-grading request to the grader (jpaek@usc.edu) with "[CS551 Regrading Request]" at the head of the subject of your email. Recall that you should carefully read both 'grading policy' and the 'regrading policy' before requesting for regrade. The office hour will be announced soon. Thank you. ------------------ Affan From srubin at flash.net Mon Apr 18 11:19:36 2005 From: srubin at flash.net (S. Rubin) Date: Mon Apr 18 11:20:16 2005 Subject: [Csci551-talk] Re: more info on odd time delay values In-Reply-To: 6667 Message-ID: <20050418181936.36295.qmail@web81305.mail.yahoo.com> Perhaps I could clarify a bit more. I am in a loop for at most 8 segments. Selections of a segment and a seed from which to download, plus misc. steps take about 1 msec (I timed it). Once the selections are done, the timer is added (with the delay value specified - see below) and a callback routine is specifed. The only code between the timer addition and the timer expiration routine where I print the time difference (see below) is the selection of the next segment and a seed (since I am in the for loop), which as I stated above takes about 1 msec. I cannot figure out what is happening in the system that ends up taking so much more extra time. Any input is greatly appreciated. Perhaps someone could time theirs and see what their timing is. I am running on cygwin, but I do not think that it is the reason for the extra delay. Sophia "S. Rubin" wrote: I am priniting out time stamps in msec (using timeval struct values and converting them to msec) prior to causing delays to occur, and then again in the time expiration routine just before each message is sent. As can be seen from the print statements below my delays are set correctly, but when I print the actual time differences, I do not see the expected delay values (see the result of subtraction). Any explanation? segment: 5, will delay by: 05, current time (msec): 1298317713 segment: 0, will delay by: 10, current time (msec): 1298317714 segment: 4, will delay by: 15, current time (msec): 1298317715 segment: 7, will delay by: 20, current time (msec): 1298317716 segment: 2, will delay by: 25, current time (msec): 1298317717 segment: 3, will delay by: 30, current time (msec): 1298317720 segment: 6, will delay by: 35, current time (msec): 1298317726 segment: 1, will delay by: 40, current time (msec): 1298317732 sending segment: 5, current time 1298317732 - original time 1298317713 = 19 (msec) sending segment: 0, current time 1298317942 - original time 1298317714 = 228 (msec) sending segment: 4, current time 1298318285 - original time 1298317715 = 570 (msec) sending segment: 7, current time 1298318736 - original time 1298317716 = 1020 (msec) sending segment: 2, current time 1298319165 - original time 1298317717 = 1448 (msec) sending segment: 3, current time 1298319607 - original time 1298317720 = 1887 (msec) sending segment: 6, current time 1298320051 - original time 1298317726 = 2325 (msec) sending segment: 1, current time 1298320671 - original time 1298317732 = 2939 (msec) Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050418/52a2a8be/attachment.html From asyed at usc.edu Mon Apr 18 11:49:26 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 18 11:52:04 2005 Subject: [Csci551-talk] Hw 2 graded Message-ID: <00fd01c54447$5cc86190$0300a8c0@A2D> I have graded and returned hw 2 to all student. If somebody didn't get it please email me. For any discussion please come to my TA office hours tommorow. Best Regards, Affan, Syed. From asyed at usc.edu Mon Apr 18 13:15:03 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 18 13:17:00 2005 Subject: [Csci551-talk] Hw 2 avg and std deviation Message-ID: <000501c54453$5312ea10$0300a8c0@A2D> Total Marks = 26. Problem 1: a)2, b)3, c)2 Problem 2: already listed Problem 3: a)2, b)4 Class average = 18.45 Std dev: 3.26 Best Regards, Affan, Syed. From asyed at usc.edu Tue Apr 19 08:22:54 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 19 08:25:01 2005 Subject: [Csci551-talk] ProjA graders office hours Message-ID: <001c01c544f3$ace752b0$0300a8c0@A2D> Here is the message by your grader for projA ------------------- Dear CS551 class. Grader's office hour for re-grading project 1: - Wednesday (Apr 20) 3:00pm ~ 5:00pm - SAL 211 Thanks you. Jeongyeup Paek Graduate Student at Electrical Engineering Department University of Southern California / Embedded Networks Laboratory Computer Science Department University of Southern California. ------------- Regards Affan From johnh at ISI.EDU Tue Apr 19 11:46:29 2005 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 19 11:48:14 2005 Subject: [Csci551-talk] hw2 key Message-ID: <200504191846.j3JIkTa7007360@dash.isi.edu> The CSci551 HW2 key has been posted to the class web site. -John Heidemann From rmchandr at usc.edu Tue Apr 19 16:12:37 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Tue Apr 19 16:14:05 2005 Subject: [Csci551-talk] Random selections. Message-ID: For the 'R' algorithm, it has been suggested in the spec to select a random segment that is missing from the file and then randomly choose a peer that has the segment. This means we have to look into all peers' segments and choose the ones that have that segment and then make a random selection among them. Wouldnt it be better in terms of computation time if we choose a random peer first and then choose one of its segments randomly and download it if we still havent downloaded it ? Any suggestions ? -Rashmi. From nikhilbh at usc.edu Wed Apr 20 13:53:00 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Wed Apr 20 13:54:15 2005 Subject: [Csci551-talk] RE:Random selections Message-ID: <64416184124d9.42665ebc@usc.edu> How do you know that the random peer will have the random segment or vice versa. There are two levels of randomness. It will help but not to a very lage extent. However there is one method which is computationally and memory effcient. and It works :) Concept :Make the decision where the information is. Algo Crux:(Client to client protocol) 1> While making request info , each nodes sends the information which segments it has. 2> While sending segment info the other node will only send information about segments the node does not have. 3> So while requesting segments we do not have to maintain the complete client table (not for all segments). Only maintain segments for GRP_DNLD_LMT (8) no of segments which the node has not down loaded. 4> Now select a peer/segment randomly (immaterial)( however i think rashmi is correct is selecting peer first will be better ) untill 8 have been requested or there is a timeout then request the smaller number. Also a check has to be added to verify that not more than 8 segments have been downloaded otherwise timeout. The above protocol is 1>memory efficient : only maintains -GRP_DNLD_LMT * no_nb dynamic arrray ( O(MAX_CLIENTS) in comparison to O(MAX_CLIENTS*MAXSEGMENTS)) 2>time efficient - it is trivial to notice that in the loop statement while selecting a random peer/seg it will have less no of iterations. i hope it helps -Nikhil Bhatia From mmurtaza at usc.edu Wed Apr 20 19:28:48 2005 From: mmurtaza at usc.edu (muhammad murtaza) Date: Wed Apr 20 19:30:09 2005 Subject: [Csci551-talk] Random selections. Message-ID: <7b514c78113e0.4266ad70@usc.edu> Hi, In my view the solution of selecting the random segments first is better cuz , if u select the peers first, and then select random segments, it might turn out that u have that segment. And this situation can happen again n again if nodes need lesser packets to complete their files. So First selecting the segment will make sure that now u dont have to search for a segment but for a node having that segment, which usually is lot less a number than number of segments in a file. So it should be better. AW Zaki ----- Original Message ----- From: csci551-talk-request@mailman.isi.edu Date: Wednesday, April 20, 2005 12:00 pm Subject: Csci551-talk Digest, Vol 9, Issue 13 > Send Csci551-talk mailing list submissions to > csci551-talk@mailman.isi.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.isi.edu/mailman/listinfo/csci551-talk > or, via email, send a message with subject or body 'help' to > csci551-talk-request@mailman.isi.edu > > You can reach the person managing the list at > csci551-talk-owner@mailman.isi.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Csci551-talk digest..." > > > Today's Topics: > > 1. Random selections. (rashmi chandrasekhar) > > > ------------------------------------------------------------------- > --- > > Message: 1 > Date: Tue, 19 Apr 2005 16:12:37 -0700 > From: rashmi chandrasekhar > Subject: [Csci551-talk] Random selections. > To: csci551-talk@ISI.EDU > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > For the 'R' algorithm, it has been suggested in the spec to select > a random segment that is missing from the file and then randomly > choose a peer that has the segment. This means we have to look > into all peers' segments and choose the ones that have that > segment and then make a random selection among them. Wouldnt it be > better in terms of computation time if we choose a random peer > first and then choose one of its segments randomly and download > it if we still havent downloaded it ? Any suggestions ? > > -Rashmi. > > > > ------------------------------ > > _______________________________________________ > Csci551-talk mailing list > Csci551-talk@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/csci551-talk > > > End of Csci551-talk Digest, Vol 9, Issue 13 > ******************************************* > From rmchandr at usc.edu Wed Apr 20 20:13:58 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Wed Apr 20 20:15:21 2005 Subject: [Csci551-talk] Sequential Segment Selection algorithm Message-ID: Suppose I send out 8 segment requests from segment numbers 0 to 7 and I lose segment 4 (say, due to packet loss), how should the sequential segment selection algorithm work in this case ? Next iteration will cause requests from segment numbers 8-15 .. or do you want us to keep track of what segments werent received and request that first (example, segment number 4 first and then 8-15) ? Same thing applies to the T algorithm (the sequential part). Thanks. Rashmi. From asyed at usc.edu Wed Apr 20 20:54:21 2005 From: asyed at usc.edu (Affan, Syed) Date: Wed Apr 20 20:57:14 2005 Subject: [Csci551-talk] Sequential Segment Selection algorithm In-Reply-To: Message-ID: <000b01c54625$cf040a90$0300a8c0@A2D> You should start from 4 and then go to 8. basically you should keep track of what is the earliest packet that you have to send sequentially. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of rashmi chandrasekhar Sent: Wednesday, April 20, 2005 8:14 PM To: csci551-talk@ISI.EDU Subject: [Csci551-talk] Sequential Segment Selection algorithm Suppose I send out 8 segment requests from segment numbers 0 to 7 and I lose segment 4 (say, due to packet loss), how should the sequential segment selection algorithm work in this case ? Next iteration will cause requests from segment numbers 8-15 .. or do you want us to keep track of what segments werent received and request that first (example, segment number 4 first and then 8-15) ? Same thing applies to the T algorithm (the sequential part). Thanks. Rashmi. From srubin at flash.net Wed Apr 20 21:30:59 2005 From: srubin at flash.net (S. Rubin) Date: Wed Apr 20 21:32:08 2005 Subject: [Csci551-talk] test cases Message-ID: <20050421043059.27862.qmail@web81302.mail.yahoo.com> 1. How are you going to test Phase 5? Our time stamps in the log file are not refined enough to see the delays in msecs. Are you going to be looking for the sequence of events? If yes, then we might need to agree to where to place our print statements for some uniformity. Perhaps you already know of a different way and I should not worry about that? ;-) 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). 3. Do you want us to run each of the 5 runs with different values for packet delay and drop prob or all with the same values? For example, if I do 5 runs on random with 2 peers, does each of the runs have different delay and prob values? Sophia From nikhilbh at usc.edu Wed Apr 20 22:34:52 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Wed Apr 20 22:35:09 2005 Subject: [Csci551-talk] Re: Sequential Segment Selection algorithm Message-ID: Hi Your implementation assumes the same search space. To optimize you should remove the seg from the search space. Also note than you can request 8 seg. So you will not request the same seg again. -Nikhil Bhatia Reply to :- In my view the solution of selecting the random segments first is better cuz , if u select the peers first, and then select random segments, it might turn out that u have that segment. And this situation can happen again n again if nodes need lesser packets to complete their files. So First selecting the segment will make sure that now u dont have to search for a segment but for a node having that segment, which usually is lot less a number than number of segments in a file. So it should be better. From asyed at usc.edu Thu Apr 21 13:58:23 2005 From: asyed at usc.edu (Affan, Syed) Date: Thu Apr 21 14:00:19 2005 Subject: [Csci551-talk] test cases In-Reply-To: <20050421043059.27862.qmail@web81302.mail.yahoo.com> Message-ID: <001501c546b4$df5897f0$0300a8c0@A2D> -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of S. Rubin Sent: Wednesday, April 20, 2005 9:31 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] test cases 1. How are you going to test Phase 5? Our time stamps in the log file are not refined enough to see the delays in msecs. Are you going to be looking for the sequence of events? If yes, then we might need to agree to where to place our print statements for some uniformity. Perhaps you already know of a different way and I should not worry about that? ;-) > Well we can check that.. By making the delay extremely large ~ sec! 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). > How do they say that? I have reread the specs but nothing seems to imply that, and really the algorithm is localized, it shouldn't be doen with assumtion of nodes starting at the same time. 3. Do you want us to run each of the 5 runs with different values for packet delay and drop prob or all with the same values? For example, if I do 5 runs on random with 2 peers, does each of the runs have different delay and prob values? > What ever you think will allow you to understadn the algorimth behavior more correctly. Usually you try to change only one aspec, not all at the same time. Sophia From srubin at flash.net Thu Apr 21 14:13:13 2005 From: srubin at flash.net (S. Rubin) Date: Thu Apr 21 14:14:50 2005 Subject: [Csci551-talk] test cases In-Reply-To: 6667 Message-ID: <20050421211313.54464.qmail@web81305.mail.yahoo.com> Specs state the following for Part A: First paragraph, last sentence: "This algorithm should focus all peers on the same part of the file at the same time if they start at the same time." Then, the very next sentnce states: "Question for README: how do you expect Algorithm S to perform compared to Algorithm R assuming all nodes start at exactly the same time? Why does it perform better or worse?" and again for Part B, Question for README states the same thing. Is it meant to be purely theoretical and not to be used for test cases? Sophia "Affan, Syed" wrote: -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of S. Rubin Sent: Wednesday, April 20, 2005 9:31 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] test cases 1. How are you going to test Phase 5? Our time stamps in the log file are not refined enough to see the delays in msecs. Are you going to be looking for the sequence of events? If yes, then we might need to agree to where to place our print statements for some uniformity. Perhaps you already know of a different way and I should not worry about that? ;-) > Well we can check that.. By making the delay extremely large ~ sec! 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). > How do they say that? I have reread the specs but nothing seems to imply that, and really the algorithm is localized, it shouldn't be doen with assumtion of nodes starting at the same time. 3. Do you want us to run each of the 5 runs with different values for packet delay and drop prob or all with the same values? For example, if I do 5 runs on random with 2 peers, does each of the runs have different delay and prob values? > What ever you think will allow you to understadn the algorimth behavior more correctly. Usually you try to change only one aspec, not all at the same time. Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050421/527df29c/attachment.html From asyed at usc.edu Thu Apr 21 14:36:42 2005 From: asyed at usc.edu (Affan, Syed) Date: Thu Apr 21 14:38:14 2005 Subject: [Csci551-talk] test cases In-Reply-To: <20050421211313.54464.qmail@web81305.mail.yahoo.com> Message-ID: <000301c546ba$3a41cf60$0300a8c0@A2D> Well you can use this condition to distill the behavior of the algorith, Your program however should not *use* this as a neccecary condition. In other words, simplify the infput to beter understand the algo, but donot assume that we will (for checking) provide such simple input. Best Regards, Affan, Syed. -----Original Message----- From: S. Rubin [mailto:srubin@flash.net] Sent: Thursday, April 21, 2005 2:13 PM To: Affan, Syed; csci551-talk@mailman.isi.edu Subject: RE: [Csci551-talk] test cases Specs state the following for Part A: First paragraph, last sentence: "This algorithm should focus all peers on the same part of the file at the same time if they start at the same time." Then, the very next sentnce states: "Question for README: how do you expect Algorithm S to perform compared to Algorithm R assuming all nodes start at exactly the same time? Why does it perform better or worse?" and again for Part B, Question for README states the same thing. Is it meant to be purely theoretical and not to be used for test cases? Sophia "Affan, Syed" wrote: -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of S. Rubin Sent: Wednesday, April 20, 2005 9:31 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] test cases 1. How are you going to test Phase 5? Our time stamps in the log file are not refined enough to see the delays in msecs. Are you going to be looking for the sequence of events? If yes, then we might need to agree to where to place our print statements for some uniformity. Perhaps you already know of a different way and I should not worry about that? ;-) > Well we can check that.. By making the delay extremely large ~ sec! 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). > How do they say that? I have reread the specs but nothing seems to imply that, and really the algorithm is localized, it shouldn't be doen with assumtion of nodes starting at the same time. 3. Do you want us to run each of the 5 runs with different values for packet delay and drop prob or all with the same values? For example, if I do 5 runs on random with 2 peers, does each of the runs have different delay and prob values? > What ever you think will allow you to understadn the algorimth behavior more correctly. Usually you try to change only one aspec, not all at the same time. Sophia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050421/e5914492/attachment.html From nikhilbh at usc.edu Fri Apr 22 01:24:25 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Fri Apr 22 01:25:11 2005 Subject: [Csci551-talk] Interesting Test Case for Freeloaders Message-ID: <2812416a178c9.42685249@usc.edu> >>> Following is a sample test case appliicable to all R/S/T . Test this to see some interesting results. # Sample config file for CS551 Project A - Spring 2005 R # Number of clients (nodes) # (Assign node ID sequentially starting from 0) 5 # Request timeout in seconds 20 # Packet delay and drop probability #Node ID Packet delay (in msec) Packet drop probability Freeloader 0 10 0.01 Y 1 10 0.01 Y 2 20 0.8 N 3 10 0.01 N 4 10 0.2 N -1 0 0 #termination of list # Specify which node will have which files initially #NODE ID Filename 3 foo 4 foo -1 --- #End of list # Specify the download tasks # This is specified by download start time (in seconds from the start of simulation) and file name #NODE ID Filename StartTime 0 foo 20 1 foo 30 2 foo 35 -1 --- -1 #End of list From hual at usc.edu Fri Apr 22 12:15:01 2005 From: hual at usc.edu (hua liu) Date: Fri Apr 22 12:15:26 2005 Subject: [Csci551-talk] some thoughts about TA's sample implemenation Message-ID: <971a401c2fb87.4268eac5@usc.edu> Hi, I compared my implementation and TA's sample implmentation of ProjA and had some questions in TA's code. Here are my thoughts: 1. What if node A is in e_SegUpdate or in e_FileXchange and now a new node B joins in. Node B will send tracker a GROUP_SHOW_INTEREST, and tracker will send GROUP_ASSIGN to node A and node B. In TA's code, on reception of GROUP_ASSIGN, node A will generate an error message. But is this actually an error? 2. In TA's code, a node can only start next round of download when the ReqTOTimer expires. That means, even there are no loss in CLNT_SEG_REP, a node must wait timeout to send next GROUP_SHOW_INTEREST. But I think a node should start next round of downloading immediately after it gets all the CLNT_SEG_REP. It should only wait for a timeout if some CLNT_SEG_REPs are lost. Correct me if I am wrong. I am wondering how do we handle the first case. Can we just ignore the GROUP_ASSIGN if we are not in e_TrackerSent? Thanks! Hua From johnh at ISI.EDU Fri Apr 22 12:45:07 2005 From: johnh at ISI.EDU (John Heidemann) Date: Fri Apr 22 12:46:22 2005 Subject: [Csci551-talk] homework 3 has been posted to the class web page Message-ID: <200504221945.j3MJj7qu011616@dash.isi.edu> Homework 3 has been posted to the class web page. -John Heidemann From asyed at usc.edu Fri Apr 22 12:53:41 2005 From: asyed at usc.edu (Affan, Syed) Date: Fri Apr 22 12:55:23 2005 Subject: [Csci551-talk] some thoughts about TA's sample implemenation In-Reply-To: <971a401c2fb87.4268eac5@usc.edu> Message-ID: <000201c54775$028036f0$0300a8c0@A2D> -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of hua liu Sent: Friday, April 22, 2005 12:15 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] some thoughts about TA's sample implemenation Hi, I compared my implementation and TA's sample implmentation of ProjA and had some questions in TA's code. Here are my thoughts: 1. What if node A is in e_SegUpdate or in e_FileXchange and now a new node B joins in. Node B will send tracker a GROUP_SHOW_INTEREST, and tracker will send GROUP_ASSIGN to node A and node B. In TA's code, on reception of GROUP_ASSIGN, node A will generate an error message. But is this actually an error? > I don't get it, why would A receive the GROUP_ASSIGN? The new node B receives that and he should be in e_TrackerSent state. There is no need for tracker to send gratuitous group assignments. 2. In TA's code, a node can only start next round of download when the ReqTOTimer expires. That means, even there are no loss in CLNT_SEG_REP, a node must wait timeout to send next GROUP_SHOW_INTEREST. But I think a node should start next round of downloading immediately after it gets all the CLNT_SEG_REP. It should only wait for a timeout if some CLNT_SEG_REPs are lost. > That might be overlooked but can be easily taken care of, and if oyu want to use it, it would be good that you do implement this. Correct me if I am wrong. I am wondering how do we handle the first case. Can we just ignore the GROUP_ASSIGN if we are not in e_TrackerSent? Thanks! Hua From hual at usc.edu Fri Apr 22 14:10:37 2005 From: hual at usc.edu (hual) Date: Fri Apr 22 14:11:53 2005 Subject: [Csci551-talk] some thoughts about TA's sample implemenation In-Reply-To: <000201c54775$028036f0$0300a8c0@A2D> Message-ID: On Fri, 22 Apr 2005, Affan, Syed wrote: > > > -----Original Message----- > From: csci551-talk-bounces@mailman.isi.edu > [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of hua liu > Sent: Friday, April 22, 2005 12:15 PM > To: csci551-talk@mailman.isi.edu > Subject: [Csci551-talk] some thoughts about TA's sample implemenation > > > Hi, > > I compared my implementation and TA's sample implmentation of ProjA and > had some questions in TA's code. Here are my thoughts: > > 1. What if node A is in e_SegUpdate or in e_FileXchange and now a new > node B joins in. Node B will send tracker a GROUP_SHOW_INTEREST, and > tracker will send GROUP_ASSIGN to node A and node B. In TA's code, on > reception of GROUP_ASSIGN, node A will generate an error message. But is > this actually an error? > > I don't get it, why would A receive the GROUP_ASSIGN? The new node B > receives that and he should be in e_TrackerSent state. There is no need > for tracker to send gratuitous group assignments. > Thanks. I get your point. I made a mistake on the client-track protocl. The tracker should only reply the requesting node. Not all the node in a group. > > 2. In TA's code, a node can only start next round of download when the > ReqTOTimer expires. That means, even there are no loss in CLNT_SEG_REP, > a node must wait timeout to send next GROUP_SHOW_INTEREST. But I think a > node should start next round of downloading immediately after it gets > all the CLNT_SEG_REP. It should only wait for a timeout if some > CLNT_SEG_REPs are lost. > > That might be overlooked but can be easily taken care of, and if oyu > want to use it, it would be good that you do implement this. > Thanks. I think if the loss probability of the network is small, implement this can improve the performance. > Correct me if I am wrong. I am wondering how do we handle the first > case. Can we just ignore the GROUP_ASSIGN if we are not in > e_TrackerSent? > > Thanks! > Hua > > > > > From johnh at ISI.EDU Fri Apr 22 14:58:57 2005 From: johnh at ISI.EDU (John Heidemann) Date: Fri Apr 22 15:01:32 2005 Subject: [Csci551-talk] homework 3 has been posted to the class web page In-Reply-To: <200504221945.j3MJj7qu011616@dash.isi.edu> Message-ID: <200504222158.j3MLwvjX014775@dash.isi.edu> On Fri, 22 Apr 2005 12:45:07 PDT, John Heidemann wrote: > >Homework 3 has been posted to the class web page. > -John Heidemann After two (sigh) errors the hw3 links should now be correct. -John Heidemann From mjbailey at usc.edu Sat Apr 23 14:44:24 2005 From: mjbailey at usc.edu (Michael Bailey) Date: Sat Apr 23 14:44:33 2005 Subject: [Csci551-talk] Using the TA code Message-ID: <426AC1B8.8020503@usc.edu> If I want to base my project B on the TA's Project A, you say that I must keep the filenames the same, but then you say to put my changes in another file? If I want to make changes to the provided code should I copy that code into another file and change it there or make my changes in the file provided? Thank you, Michael Bailey From asyed at usc.edu Sat Apr 23 15:23:28 2005 From: asyed at usc.edu (Affan, Syed) Date: Sat Apr 23 15:25:26 2005 Subject: [Csci551-talk] Using the TA code In-Reply-To: <426AC1B8.8020503@usc.edu> Message-ID: <000401c54853$1835ed80$0300a8c0@A2D> I am not sure, where is it said to make ur changes in another file? My understanding is that you should document the changes very well, in the file (using comment) and mention specific s in the README. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Michael Bailey Sent: Saturday, April 23, 2005 2:44 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Using the TA code If I want to base my project B on the TA's Project A, you say that I must keep the filenames the same, but then you say to put my changes in another file? If I want to make changes to the provided code should I copy that code into another file and change it there or make my changes in the file provided? Thank you, Michael Bailey From mjbailey at usc.edu Sat Apr 23 15:39:13 2005 From: mjbailey at usc.edu (Michael Bailey) Date: Sat Apr 23 15:39:27 2005 Subject: [Csci551-talk] Using the TA code In-Reply-To: <000401c54853$1835ed80$0300a8c0@A2D> References: <000401c54853$1835ed80$0300a8c0@A2D> Message-ID: <426ACE91.7090502@usc.edu> In the project B spec, second paragraph under introduction: "If you re-use any code, you must keep the filenames of the reused code the same. You are also strongly encouraged to make as few changes to that code as possible. (Put your changes in other files.) You must document what code you reuse in your README file." Michael Bailey Affan, Syed wrote: >I am not sure, where is it said to make ur changes in another file? My >understanding is that you should document the changes very well, in the >file (using comment) and mention specific s in the README. > >Best Regards, >Affan, Syed. > > > >-----Original Message----- >From: csci551-talk-bounces@mailman.isi.edu >[mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Michael >Bailey >Sent: Saturday, April 23, 2005 2:44 PM >To: csci551-talk@mailman.isi.edu >Subject: [Csci551-talk] Using the TA code > > >If I want to base my project B on the TA's Project A, >you say that I must keep the filenames the same, but >then you say to put my changes in another file? >If I want to make changes to the provided code should I >copy that code into another file and change it there or >make my changes in the file provided? > >Thank you, > >Michael Bailey > > > > From asyed at usc.edu Sat Apr 23 16:04:31 2005 From: asyed at usc.edu (Affan, Syed) Date: Sat Apr 23 16:06:25 2005 Subject: [Csci551-talk] Using the TA code In-Reply-To: <426ACE91.7090502@usc.edu> Message-ID: <000501c54858$d50ce080$0300a8c0@A2D> The concpet over here was to modularize and make any changes (e.g addition functions that you call) implemented in a separate file. This would allow easier code checking through MOSS (yes we are doing that!) and also allows us to figure out exactly what you did differnet, and maybe give you more credit. If the code works without that, we wont look at it. So, if you are confident.. Go ahead.. But document, document, document :) Best Regards, Affan, Syed. -----Original Message----- From: mjbailey@usc.edu [mailto:mjbailey@usc.edu] Sent: Saturday, April 23, 2005 3:39 PM To: Affan, Syed Cc: csci551-talk@mailman.isi.edu Subject: Re: [Csci551-talk] Using the TA code In the project B spec, second paragraph under introduction: "If you re-use any code, you must keep the filenames of the reused code the same. You are also strongly encouraged to make as few changes to that code as possible. (Put your changes in other files.) You must document what code you reuse in your README file." Michael Bailey Affan, Syed wrote: >I am not sure, where is it said to make ur changes in another file? My >understanding is that you should document the changes very well, in the >file (using comment) and mention specific s in the README. > >Best Regards, >Affan, Syed. > > > >-----Original Message----- >From: csci551-talk-bounces@mailman.isi.edu >[mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Michael >Bailey >Sent: Saturday, April 23, 2005 2:44 PM >To: csci551-talk@mailman.isi.edu >Subject: [Csci551-talk] Using the TA code > > >If I want to base my project B on the TA's Project A, >you say that I must keep the filenames the same, but >then you say to put my changes in another file? >If I want to make changes to the provided code should I >copy that code into another file and change it there or >make my changes in the file provided? > >Thank you, > >Michael Bailey > > > > From mikestephens at gmail.com Sat Apr 23 22:56:09 2005 From: mikestephens at gmail.com (Michael Stephens) Date: Sat Apr 23 22:56:35 2005 Subject: [Csci551-talk] TA code: selectnSendSegReq does not drop packets Message-ID: <55aa0735050423225657c233f6@mail.gmail.com> I am looking at the TA code in the selectnSendSegReq() operation of the ClientNode class. This operation seems to send the outgoing packets (segment requests) without checking to see if any of these packets should be dropped. The Project A specification does not seem to imply that this behavior is acceptable (i.e. in section 4.5 where it discusses packet loss, it does not indicate that segment requests are immune to loss). From yogendra at usc.edu Sun Apr 24 17:57:34 2005 From: yogendra at usc.edu (hariram yogendran) Date: Sun Apr 24 17:58:26 2005 Subject: [Csci551-talk] Working of sample implementation code Message-ID: <620ce0c2f85d.426bde0e@usc.edu> I dont know how many of you guys got the code running.I am using the manager.conf used in testcase 5 in the sample implementation.If I use the manager.conf directly the tracker exits immediately before the clients begin eventhough the exit timer value is twice timeout value and the first node begins exactly on the timeout value (i.e) first node begins at the 3rd second and timeout value is 3.But when I set the timeout value to 5 the code runs fine.Any of you guys have any idea on this behaviour did you come across this scenario. One more intersting thing that happened is when I include a print statement in the code any print statement then i think the delay is affecting our timers and the code runs with 3secs timeout itself but the file transfers do not happen(I dont know why). I just want to check with you people before i start working on my code as i dont want to waste time on it. Regards, Y From mikestephens at gmail.com Sun Apr 24 19:33:24 2005 From: mikestephens at gmail.com (Michael Stephens) Date: Sun Apr 24 19:34:28 2005 Subject: [Csci551-talk] Assumption: When to start timeout Message-ID: <55aa073505042419333a7f0e7d@mail.gmail.com> I assume that the timeout counter should start when the client "queues" a message to be sent, not when the message is actually sent after delays. In our system we are simulating delays in the network connection; in a real system the client would probably not be aware of such delays. 1. Is it valid to assume that the timeout counter should start when the client "queues" a message, not when the message is actually sent? 2. Should we log the time that the client "queues" a message to be sent as well as the time the message is actually sent after delays, or only the time the message is actually sent? From nsolanki at usc.edu Mon Apr 25 16:26:18 2005 From: nsolanki at usc.edu (nainesh solanki) Date: Mon Apr 25 16:26:38 2005 Subject: [Csci551-talk] Re: some thoughts about TA's sample implemenation Message-ID: <10edcf6a17add.426d1a2a@usc.edu> > 2. In TA's code, a node can only start next round of download when the > ReqTOTimer expires. That means, even there are no loss in > CLNT_SEG_REP,a node must wait timeout to send next > GROUP_SHOW_INTEREST. But I think a > node should start next round of downloading immediately after it gets > all the CLNT_SEG_REP. It should only wait for a timeout if some > CLNT_SEG_REPs are lost. > > That might be overlooked but can be easily taken care of, and if oyu > want to use it, it would be good that you do implement this. > Actually the code does implement it. It removes the timer once all the CLNT_SEG_REP messages are received. I dont know if I am supposed to discuss the working of code so I havent pointed out where this is done. If the instructor doesnt mind I can give you a pointer. thanks Nainesh Solanki ----- Original Message ----- From: csci551-talk-request@mailman.isi.edu Date: Saturday, April 23, 2005 12:00 pm Subject: Csci551-talk Digest, Vol 9, Issue 16 > Send Csci551-talk mailing list submissions to > csci551-talk@mailman.isi.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.isi.edu/mailman/listinfo/csci551-talk > or, via email, send a message with subject or body 'help' to > csci551-talk-request@mailman.isi.edu > > You can reach the person managing the list at > csci551-talk-owner@mailman.isi.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Csci551-talk digest..." > > > Today's Topics: > > 1. some thoughts about TA's sample implemenation (hua liu) > 2. homework 3 has been posted to the class web page (John > Heidemann) 3. RE: some thoughts about TA's sample implemenation > (Affan, Syed) > 4. RE: some thoughts about TA's sample implemenation (hual) > 5. Re: homework 3 has been posted to the class web page > (John Heidemann) > > > ------------------------------------------------------------------- > --- > > Message: 1 > Date: Fri, 22 Apr 2005 12:15:01 -0700 > From: hua liu > Subject: [Csci551-talk] some thoughts about TA's sample implemenation > To: csci551-talk@mailman.isi.edu > Message-ID: <971a401c2fb87.4268eac5@usc.edu> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I compared my implementation and TA's sample implmentation of > ProjA and had some questions in TA's code. Here are my thoughts: > > 1. What if node A is in e_SegUpdate or in e_FileXchange and now a > new node B joins in. Node B will send tracker a > GROUP_SHOW_INTEREST, and tracker will send GROUP_ASSIGN to node A > and node B. In TA's code, on reception of GROUP_ASSIGN, node A > will generate an error message. But is this actually an error? > > 2. In TA's code, a node can only start next round of download when > the ReqTOTimer expires. That means, even there are no loss in > CLNT_SEG_REP, a node must wait timeout to send next > GROUP_SHOW_INTEREST. But I think a node should start next round of > downloading immediately after it gets all the CLNT_SEG_REP. It > should only wait for a timeout if some CLNT_SEG_REPs are lost. > > Correct me if I am wrong. I am wondering how do we handle the > first case. Can we just ignore the GROUP_ASSIGN if we are not in > e_TrackerSent? > > Thanks! > Hua > > > > > ------------------------------ > > Message: 2 > Date: Fri, 22 Apr 2005 12:45:07 -0700 > From: John Heidemann > Subject: [Csci551-talk] homework 3 has been posted to the class web > page > To: csci551-talk@ISI.EDU > Message-ID: <200504221945.j3MJj7qu011616@dash.isi.edu> > Content-Type: text/plain; charset=US-ASCII > > > Homework 3 has been posted to the class web page. > -John Heidemann > > > ------------------------------ > > Message: 3 > Date: Fri, 22 Apr 2005 12:53:41 -0700 > From: "Affan, Syed" > Subject: RE: [Csci551-talk] some thoughts about TA's sample > implemenation > To: "'hua liu'" , > Message-ID: <000201c54775$028036f0$0300a8c0@A2D> > Content-Type: text/plain; charset="us-ascii" > > > > -----Original Message----- > From: csci551-talk-bounces@mailman.isi.edu > [csci551-talk-bounces@mailman.isi.edu] On Behalf Of hua liu > Sent: Friday, April 22, 2005 12:15 PM > To: csci551-talk@mailman.isi.edu > Subject: [Csci551-talk] some thoughts about TA's sample implemenation > > > Hi, > > I compared my implementation and TA's sample implmentation of > ProjA and > had some questions in TA's code. Here are my thoughts: > > 1. What if node A is in e_SegUpdate or in e_FileXchange and now a new > node B joins in. Node B will send tracker a GROUP_SHOW_INTEREST, and > tracker will send GROUP_ASSIGN to node A and node B. In TA's code, on > reception of GROUP_ASSIGN, node A will generate an error message. > But is > this actually an error? > > I don't get it, why would A receive the GROUP_ASSIGN? The new > node B > receives that and he should be in e_TrackerSent state. There is no > needfor tracker to send gratuitous group assignments. > > > 2. In TA's code, a node can only start next round of download when the > ReqTOTimer expires. That means, even there are no loss in > CLNT_SEG_REP,a node must wait timeout to send next > GROUP_SHOW_INTEREST. But I think a > node should start next round of downloading immediately after it gets > all the CLNT_SEG_REP. It should only wait for a timeout if some > CLNT_SEG_REPs are lost. > > That might be overlooked but can be easily taken care of, and if oyu > want to use it, it would be good that you do implement this. > > Correct me if I am wrong. I am wondering how do we handle the first > case. Can we just ignore the GROUP_ASSIGN if we are not in > e_TrackerSent? > > Thanks! > Hua > > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 22 Apr 2005 14:10:37 -0700 (PDT) > From: hual > Subject: RE: [Csci551-talk] some thoughts about TA's sample > implemenation > To: "Affan, Syed" > Cc: csci551-talk@mailman.isi.edu > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > On Fri, 22 Apr 2005, Affan, Syed wrote: > > > > > > > -----Original Message----- > > From: csci551-talk-bounces@mailman.isi.edu > > [csci551-talk-bounces@mailman.isi.edu] On Behalf Of hua liu > > Sent: Friday, April 22, 2005 12:15 PM > > To: csci551-talk@mailman.isi.edu > > Subject: [Csci551-talk] some thoughts about TA's sample > implemenation> > > > > Hi, > > > > I compared my implementation and TA's sample implmentation of > ProjA and > > had some questions in TA's code. Here are my thoughts: > > > > 1. What if node A is in e_SegUpdate or in e_FileXchange and now > a new > > node B joins in. Node B will send tracker a > GROUP_SHOW_INTEREST, and > > tracker will send GROUP_ASSIGN to node A and node B. In TA's > code, on > > reception of GROUP_ASSIGN, node A will generate an error > message. But is > > this actually an error? > > > I don't get it, why would A receive the GROUP_ASSIGN? The new > node B > > receives that and he should be in e_TrackerSent state. There is > no need > > for tracker to send gratuitous group assignments. > > > > Thanks. I get your point. I made a mistake on the client-track > protocl.The tracker should only reply the requesting node. Not all > the node in a > group. > > > > > 2. In TA's code, a node can only start next round of download > when the > > ReqTOTimer expires. That means, even there are no loss in > CLNT_SEG_REP,> a node must wait timeout to send next > GROUP_SHOW_INTEREST. But I think a > > node should start next round of downloading immediately after it > gets> all the CLNT_SEG_REP. It should only wait for a timeout if some > > CLNT_SEG_REPs are lost. > > > That might be overlooked but can be easily taken care of, and > if oyu > > want to use it, it would be good that you do implement this. > > > Thanks. I think if the loss probability of the network is small, > implementthis can improve the performance. > > > Correct me if I am wrong. I am wondering how do we handle the first > > case. Can we just ignore the GROUP_ASSIGN if we are not in > > e_TrackerSent? > > > > Thanks! > > Hua > > > > > > > > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 22 Apr 2005 14:58:57 -0700 > From: John Heidemann > Subject: Re: [Csci551-talk] homework 3 has been posted to the class > web page > To: csci551-talk@ISI.EDU > Message-ID: <200504222158.j3MLwvjX014775@dash.isi.edu> > Content-Type: text/plain; charset=US-ASCII > > On Fri, 22 Apr 2005 12:45:07 PDT, John Heidemann wrote: > > > >Homework 3 has been posted to the class web page. > > -John Heidemann > > After two (sigh) errors the hw3 links should now be correct. > > -John Heidemann > > > > ------------------------------ > > _______________________________________________ > Csci551-talk mailing list > Csci551-talk@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/csci551-talk > > > End of Csci551-talk Digest, Vol 9, Issue 16 > ******************************************* > From rmchandr at usc.edu Mon Apr 25 16:26:49 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Mon Apr 25 16:27:30 2005 Subject: [Csci551-talk] Packet drops and freeloaders. Message-ID: <5e473e822f008.426d1a49@usc.edu> Freeloaders drop Segment Request packets. Is this considered a drop at all ? I mean to say, its inherent for a freeloader to *ignore* any request packet. Also, I was of the opinion that packet drop statistics are only a result of the packet drop probability in the manager.conf. So, should the *REFUSED* packets also be added to the freeloader's dropped packets counter ? This issue was raised some time back on the groups but I am not sure I understood the TA's response. Any help ? -Rashmi. From nikhilbh at usc.edu Mon Apr 25 18:19:36 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Mon Apr 25 18:20:37 2005 Subject: [Csci551-talk] Re:Packet Drops and freeloaders Message-ID: Rashmi, Packets can only be REFUSED if they are able to reach a node (ie they do not get droped) Essentially the packet drop counter is independant of the application. Packet Drop counter is more of a Physical layer statistics and REQUEST drop is at the application layer one. I hope this is true ,until and unless TA has some other take on it :) -Nikhil Bhatia Reply To Rashmi, Freeloaders drop Segment Request packets. Is this considered a drop at all ? I mean to say, its inherent for a freeloader to *ignore* any request packet. Also, I was of the opinion that packet drop statistics are only a result of the packet drop probability in the manager.conf. So, should the *REFUSED* packets also be added to the freeloader's dropped packets counter ? This issue was raised some time back on the groups but I am not sure I understood the TA's response. Any help ? -Rashmi. From asyed at usc.edu Mon Apr 25 18:47:23 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 25 18:49:31 2005 Subject: [Csci551-talk] Packet drops and freeloaders. In-Reply-To: <5e473e822f008.426d1a49@usc.edu> Message-ID: <000001c54a01$ea13b530$0300a8c0@A2D> I am not sure what you mean. We had specified that the sender of a request decides according to its drop prob to drop a packet. And the drop statistics were kept based on that, not at the receiver. The receiver did not drop a pkt on reception. So Free loaders still have to drop pkts that are outgoing. They refuse the pkts that they receive. I hope this is clear. Thank you. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of rashmi chandrasekhar Sent: Monday, April 25, 2005 4:27 PM To: csci551-talk@ISI.EDU Subject: [Csci551-talk] Packet drops and freeloaders. Freeloaders drop Segment Request packets. Is this considered a drop at all ? I mean to say, its inherent for a freeloader to *ignore* any request packet. Also, I was of the opinion that packet drop statistics are only a result of the packet drop probability in the manager.conf. So, should the *REFUSED* packets also be added to the freeloader's dropped packets counter ? This issue was raised some time back on the groups but I am not sure I understood the TA's response. Any help ? -Rashmi. From srubin at flash.net Mon Apr 25 19:58:05 2005 From: srubin at flash.net (S. Rubin) Date: Mon Apr 25 19:58:30 2005 Subject: [Csci551-talk] Packet drops and freeloaders. Message-ID: <20050426025805.58435.qmail@web81303.mail.yahoo.com> I think what is confusing is the association that has been made in the project spec that states "discarded packets by freeloaders should be like packet loss". The bottom line quesiton is should we keep any stats on the "refused" packets or just make an entry in the log file only? Sophia I am not sure what you mean. We had specified that the sender of arequest decides according to its drop prob to drop a packet. And thedrop statistics were kept based on that, not at the receiver. Thereceiver did not drop a pkt on reception. So Free loaders still have todrop pkts that are outgoing. They refuse the pkts that they receive. Ihope this is clear. Thank you. Best Regards,Affan, Syed. -----Original Message-----From: csci551-talk-bounces at mailman.isi.edu[mailto:csci551-talk-bounces at mailman.isi.edu] On Behalf Of rashmichandrasekharSent: Monday, April 25, 2005 4:27 PMTo: csci551-talk at ISI.EDUSubject: [Csci551-talk] Packet drops and freeloaders.Freeloaders drop Segment Request packets. Is this considered a drop atall ? I mean to say, its inherent for a freeloader to *ignore* anyrequest packet. Also, I was of the opinion that packet drop statisticsare only a result of the packet drop probability in the manager.conf.So, should the *REFUSED* packets also be added to the freeloader'sdropped packets counter ?This issue was raised some time back on the groups but I am not sure Iunderstood the TA's response. Any help ?-Rashmi. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050425/f7f04e1f/attachment.html From asyed at usc.edu Mon Apr 25 20:04:45 2005 From: asyed at usc.edu (Affan, Syed) Date: Mon Apr 25 20:06:32 2005 Subject: [Csci551-talk] Packet drops and freeloaders. In-Reply-To: <6f5c54a92e6de.426d37be@usc.edu> Message-ID: <000301c54a0c$b58fa480$0300a8c0@A2D> Hi Affan, Suppose node 1 is a freeloader. He gets an INFO_REQ message from node 2. He is not going to send a reply to this. In this case, does he consider not sending this reply as a dropped packet ? >> No, although as sophia pointed out it would bebetter that we maintain stats for refused packets.. But sicne the initial stats didn't mention that, this is not required. Just log the INFO_REQ refused! However, when node 1 sends his own INFO_REQ or SEG_REQ messages to other nodes, he drops them probabilistically (and so will the receipients for the INFO_REP and SEG_REP). Am i correct ? >>Yes Thanks, Regards., Rashmi. ----- Original Message ----- From: "Affan, Syed" Date: Monday, April 25, 2005 5:47 pm Subject: RE: [Csci551-talk] Packet drops and freeloaders. > I am not sure what you mean. We had specified that the sender of a > request decides according to its drop prob to drop a packet. And the > drop statistics were kept based on that, not at the receiver. The > receiver did not drop a pkt on reception. So Free loaders still have > to drop pkts that are outgoing. They refuse the pkts that they > receive. I > hope this is clear. > Thank you. > Best Regards, > Affan, Syed. > > > > -----Original Message----- > From: csci551-talk-bounces@mailman.isi.edu > [csci551-talk-bounces@mailman.isi.edu] On Behalf Of rashmi > chandrasekhar > Sent: Monday, April 25, 2005 4:27 PM > To: csci551-talk@ISI.EDU > Subject: [Csci551-talk] Packet drops and freeloaders. > > > > Freeloaders drop Segment Request packets. Is this considered a > drop at > all ? I mean to say, its inherent for a freeloader to *ignore* any > request packet. Also, I was of the opinion that packet drop statistics > are only a result of the packet drop probability in the manager.conf. > So, should the *REFUSED* packets also be added to the freeloader's > dropped packets counter ? > > This issue was raised some time back on the groups but I am not > sure I > understood the TA's response. Any help ? > > -Rashmi. > > > > From rmchandr at usc.edu Mon Apr 25 23:01:20 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Mon Apr 25 23:02:35 2005 Subject: [Csci551-talk] Another Freeloader doubt. Message-ID: <8548367e2cd6e.426d68b0@usc.edu> Should the freeloader continue to refuse giving information even after it finishes its download ? I feel its not necessary because it has already got all segments and is now acting like the seed and hence, should be able to process other nodes' requests. Any views otherwise ? Regards, Rashmi. From nikhilbh at usc.edu Mon Apr 25 23:40:18 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Mon Apr 25 23:40:31 2005 Subject: [Csci551-talk] Re: Another Freeloader doubt. Message-ID: Common ! Think if you were a freeloader what would you do ? The guy is a freeloader , a thief , he just get the file and get out the network .ie will terminate ! -Nikhil Bhatia Reply to:- Should the freeloader continue to refuse giving information even after it finishes its download ? I feel its not necessary because it has already got all segments and is now acting like the seed and hence, should be able to process other nodes' requests. Any views otherwise ? Regards, Rashmi. From asyed at usc.edu Tue Apr 26 00:08:22 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 00:10:30 2005 Subject: [Csci551-talk] Re: Another Freeloader doubt. In-Reply-To: Message-ID: <000301c54a2e$be713b50$0300a8c0@A2D> Nikhil thinks the right way :) Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of nikhil bhatia Sent: Monday, April 25, 2005 11:40 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Re: Another Freeloader doubt. Common ! Think if you were a freeloader what would you do ? The guy is a freeloader , a thief , he just get the file and get out the network .ie will terminate ! -Nikhil Bhatia Reply to:- Should the freeloader continue to refuse giving information even after it finishes its download ? I feel its not necessary because it has already got all segments and is now acting like the seed and hence, should be able to process other nodes' requests. Any views otherwise ? Regards, Rashmi. From rmchandr at usc.edu Tue Apr 26 01:14:37 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Tue Apr 26 01:15:30 2005 Subject: [Csci551-talk] Re: Another Freeloader doubt. Message-ID: <8cf281522ab98.426d87ed@usc.edu> "Everyone benefits from everyone's bandwidth" is the essence of p2p networks. In practice, why would someone be a freeloader in the first place ? Someone who is ignorant about the above fact, someone who might think that sharing data would reduce his/her own bandwidth and delay his/her own download. Another reason why someone would be a freeloader is (in your terms) when he is a thief :-) .. but with the p2p networks designed these days, the lesser you share, the lesser/slower you get to download .. there really is no motivation for someone to be a freeloader. If the reason was the former one (fear of slowing his/her own download), this wouldnt hold once the download tasks are complete. In view of all this, I felt it was ok if a freeloader allowed sharing *after* his/her own download. But if he is thief, I guess you are right as he wouldnt care and just terminate. Regards, Rashmi. ----- Original Message ----- From: nikhil bhatia Date: Monday, April 25, 2005 10:40 pm Subject: [Csci551-talk] Re: Another Freeloader doubt. > Common ! Think if you were a freeloader what would you do ? > > The guy is a freeloader , a thief , > he just get the file and get out the network .ie will terminate ! > > -Nikhil Bhatia > > > Reply to:- > Should the freeloader continue to refuse giving information even > after it finishes its download ? I feel its not necessary because > it has already got all segments and is now acting like the seed > and hence, should be able to process other nodes' requests. > > Any views otherwise ? > > Regards, > Rashmi. > > From nikhilbh at usc.edu Tue Apr 26 01:37:47 2005 From: nikhilbh at usc.edu (nikhil bhatia) Date: Tue Apr 26 01:38:34 2005 Subject: [Csci551-talk] Re: Another Freeloader doubt. Message-ID: <4688000014b76.426d9b6b@usc.edu> freeloaders do not make their downloaded files accessible, sharers must wait longer and longer to get access to the same files from other shares. This degrades the health of the p2p network. Infact if the freeloadrs spend more time in the network they can spoil sharers life. ie a freeloader with a killer instinct ..just kidding. :) -Nikhil Bhatia ----- Original Message ----- From: rashmi chandrasekhar Date: Tuesday, April 26, 2005 1:14 am Subject: Re: [Csci551-talk] Re: Another Freeloader doubt. > > "Everyone benefits from everyone's bandwidth" is the essence of p2p > networks. In practice, why would someone be a freeloader in the > first place ? Someone who is ignorant about the above fact, someone > who might think that sharing data would reduce his/her own > bandwidth and delay his/her own download. Another reason why > someone would be a freeloader is (in your terms) when he is a thief > :-) .. but with the p2p networks designed these days, the lesser > you share, the lesser/slower you get to download .. there really is > no motivation for someone to be a freeloader. > > If the reason was the former one (fear of slowing his/her own > download), this wouldnt hold once the download tasks are complete. > In view of all this, I felt it was ok if a freeloader allowed > sharing *after* his/her own download. But if he is thief, I guess > you are right as he wouldnt care and just terminate. > > Regards, > Rashmi. > > > ----- Original Message ----- > From: nikhil bhatia > Date: Monday, April 25, 2005 10:40 pm > Subject: [Csci551-talk] Re: Another Freeloader doubt. > > > Common ! Think if you were a freeloader what would you do ? > > > > The guy is a freeloader , a thief , > > he just get the file and get out the network .ie will terminate ! > > > > -Nikhil Bhatia > > > > > > Reply to:- > > Should the freeloader continue to refuse giving information even > > after it finishes its download ? I feel its not necessary because > > it has already got all segments and is now acting like the seed > > and hence, should be able to process other nodes' requests. > > > > Any views otherwise ? > > > > Regards, > > Rashmi. > > > > > > From nsachary at usc.edu Tue Apr 26 10:24:12 2005 From: nsachary at usc.edu (Narendra Acharya) Date: Tue Apr 26 10:24:49 2005 Subject: [Csci551-talk] Should Freeloader terminate or log packets as REFUSED Message-ID: <0IFK004B5DOBURE0@msg-mx2.usc.edu> Should a freeloader terminate directly after completing file download or log all the packets as REFUSED and then terminate according to the termination algorithm for all seeds? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050426/6fe7219a/attachment.html From asyed at usc.edu Tue Apr 26 10:44:19 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 10:45:41 2005 Subject: [Csci551-talk] Should Freeloader terminate or log packets as REFUSED In-Reply-To: <0IFK004B5DOBURE0@msg-mx2.usc.edu> Message-ID: <000301c54a87$981af0f0$0300a8c0@A2D> Since it is not specified, this is open to you. In either case the effect on the network is exactly the same. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Narendra Acharya Sent: Tuesday, April 26, 2005 10:24 AM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Should Freeloader terminate or log packets as REFUSED Should a freeloader terminate directly after completing file download or log all the packets as REFUSED and then terminate according to the termination algorithm for all seeds? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050426/883255cd/attachment.html From xiw at usc.edu Tue Apr 26 12:08:19 2005 From: xiw at usc.edu (xi wang) Date: Tue Apr 26 12:08:42 2005 Subject: [Csci551-talk] Re: [Cs551] Project b - Time out question Message-ID: > Hi, > (1)Now,,,in the termination codition of non-seed nodes,,,,they > shouldn't make any progress in downloading for 4 rounds,,,the > progress here does it mean recving some segments only or it could > mean also recving request as well from other clients? > > if we are to consider recving a req as a progress , then we fall > into an infinite situation in high loss rate,,,,assume i have one > seed and 2 clients if the seed terminated because it didn't recv a > req(because the req are lost), then the 2 clients will never end > since they recv req from each other? > You can do some experiments with these. A good way is to consider a node is making progress if it is receiving a segment or sending out a segment. Swapping segment information is not considered as progress, so there won't be infinite loops. > > (2)Assume the following scenario, The delay is one second...and > the timeout is 5 second,,,,now if client send to the seed seg req > and assume the seed has 10 replies waiting,,,then the seed will > send the client reply after 11 second....the problem here is the > client will timeout assuming that the packet is lost where it > didn't>,.....Do we have to consider such a scenario in our project > or we can safely assume that if i sent a packet and then i > timeout without recving a response then this packet is lost? > > In other words, can we assume that if the time out is always very > large comparing to the delay > If nodes cannot complete downloading due to high delay and small timeout value, and they terminate gracefully, that's not an error. We will use higher timeouts for some testcases. -Xi From asyed at usc.edu Tue Apr 26 12:27:32 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 12:29:42 2005 Subject: [Csci551-talk] Re: [Cs551] Project b - Time out question In-Reply-To: Message-ID: <000001c54a96$0423ebe0$0300a8c0@A2D> I think an even better approach to (1) is to consider progreess if you only get SEG_REQ, INFO_REQ should not be treated as progress. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of xi wang Sent: Tuesday, April 26, 2005 12:08 PM To: cs551@catarina.usc.edu Cc: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] Re: [Cs551] Project b - Time out question > Hi, > (1)Now,,,in the termination codition of non-seed nodes,,,,they > shouldn't make any progress in downloading for 4 rounds,,,the > progress here does it mean recving some segments only or it could > mean also recving request as well from other clients? > > if we are to consider recving a req as a progress , then we fall > into an infinite situation in high loss rate,,,,assume i have one > seed and 2 clients if the seed terminated because it didn't recv a > req(because the req are lost), then the 2 clients will never end > since they recv req from each other? > You can do some experiments with these. A good way is to consider a node is making progress if it is receiving a segment or sending out a segment. Swapping segment information is not considered as progress, so there won't be infinite loops. > > (2)Assume the following scenario, The delay is one second...and > the timeout is 5 second,,,,now if client send to the seed seg req > and assume the seed has 10 replies waiting,,,then the seed will > send the client reply after 11 second....the problem here is the > client will timeout assuming that the packet is lost where it > didn't>,.....Do we have to consider such a scenario in our project > or we can safely assume that if i sent a packet and then i > timeout without recving a response then this packet is lost? > > In other words, can we assume that if the time out is always very > large comparing to the delay > If nodes cannot complete downloading due to high delay and small timeout value, and they terminate gracefully, that's not an error. We will use higher timeouts for some testcases. -Xi From asyed at usc.edu Tue Apr 26 12:34:06 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 12:36:34 2005 Subject: IMP all studnets please read ! [Csci551-talk] Assumption: When to start timeout Message-ID: <000201c54a96$ee52f0d0$0300a8c0@A2D> Sorry for the delayed response but it was a good question and needed some thought. The correct approach has got to be to start timer as soon as you buffer the packet. But the log time should be when it is actually sent. I know this can create pathological scenarios, but this is most realistic and we can test your implementation through simpler scenarios :) Thanks. Affan >>>>-----Original Message----- >>>>From: csci551-talk-bounces@mailman.isi.edu >>>>[mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Michael >>>>Stephens >>>>Sent: Sunday, April 24, 2005 7:33 PM >>>>To: csci551-talk@ISI.EDU >>>>Subject: [Csci551-talk] Assumption: When to start timeout >>>> >>>> >>>>I assume that the timeout counter should start when the client >>>>"queues" a message to be sent, not when the message is actually sent >>>>after delays. In our system we are simulating delays in the network >>>>connection; in a real system the client would probably not be aware >>>>of >>> >>> >>>>such delays. >>>> >>>>1. Is it valid to assume that the timeout counter should start when >>>>the client "queues" a message, not when the message is actually sent? > > >>>>2. Should we log the time that the client "queues" a message to be >>>>sent as well as the time the message is actually sent after delays, >>>>or >>> >>> >>>>only the time the message is actually sent? From srubin at flash.net Tue Apr 26 13:25:12 2005 From: srubin at flash.net (S. Rubin) Date: Tue Apr 26 13:25:44 2005 Subject: IMP all studnets please read ! [Csci551-talk] Assumption: When to start timeout Message-ID: <20050426202512.88771.qmail@web81303.mail.yahoo.com> On April 18 in my posting Re: more info on odd time delay values I gave a set of examples with the start and end times and posed a question, but never got any replies. Since it is now more clear, any thoughts on why I am seeing the "extra" time? Is anyone else "seeing" it too? Sophia Sorry for the delayed response but it was a good question and needed some thought. The correct approach has got to be to start timer as soon as you buffer the packet. But the log time should be when it is actually sent. I know this can create pathological scenarios, but this is most realistic and we can test your implementation through simpler scenarios :) Thanks. Affan >>>>-----Original Message----- >>>>From: csci551-talk-bounces at mailman.isi.edu >>>>[mailto:csci551-talk-bounces at mailman.isi.edu] On Behalf Of Michael >>>>Stephens >>>>Sent: Sunday, April 24, 2005 7:33 PM >>>>To: csci551-talk at ISI.EDU >>>>Subject: [Csci551-talk] Assumption: When to start timeout >>>> >>>> >>>>I assume that the timeout counter should start when the client >>>>"queues" a message to be sent, not when the message is actually sent >>>>after delays. In our system we are simulating delays in the network >>>>connection; in a real system the client would probably not be aware >>>>of >>> >>> >>>>such delays. >>>> >>>>1. Is it valid to assume that the timeout counter should start when >>>>the client "queues" a message, not when the message is actually sent? > > >>>>2. Should we log the time that the client "queues" a message to be >>>>sent as well as the time the message is actually sent after delays, >>>>or >>> >>> >>>>only the time the message is actually sent? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050426/54eb57f3/attachment.html From xiw at usc.edu Tue Apr 26 21:29:32 2005 From: xiw at usc.edu (Xi Wang) Date: Tue Apr 26 21:33:36 2005 Subject: [Csci551-talk] Re: [Cs551] question-logging In-Reply-To: <74e2dfdf1faf1.426e53de@usc.edu> References: <74e2dfdf1faf1.426e53de@usc.edu> Message-ID: <426F152C.9020006@usc.edu> Again and again, bandwidth limitation is seperate component to simulate underlying network (Internet) behavior. So the rest of your program don't know when the packets are received. The conclusion is log a message as soon as you send it. -Xi mishari ibrahim almishari wrote: > (1) In the logging of the sent messages,,,,do we log them after completely sending them or we log them as soon as we issue the send them( as soon as we put them in the queue), if this is the case them sending 8 segments will have the same time in the log file? > > -mish > > > > > > _______________________________________________ > Cs551 mailing list > Cs551@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/cs551 From xiw at usc.edu Tue Apr 26 21:36:06 2005 From: xiw at usc.edu (Xi Wang) Date: Tue Apr 26 21:39:34 2005 Subject: [Csci551-talk] Re: [Cs551] Q-Seq numbers In-Reply-To: <904f98c91e50d.426e90c4@usc.edu> References: <904f98c91e50d.426e90c4@usc.edu> Message-ID: <426F16B6.70204@usc.edu> I don't think you have to distinguish old from new. Just process every message you received and there should be no ill effect if you design your program correctly. -Xi mishari ibrahim almishari wrote: > (1)Assume the I send a group update message.....because of the limited bw i recieved in the next round....now the question how can i differentiate between the old group update message and the new one...i thought of a sequence number but that may complicate the problem a bit....so CAN we safely assume that such scenarion will not occur in the project....or do have to handle it,,,and if yes do we use seq numbers or there is a better way? > > > -mish > > _______________________________________________ > Cs551 mailing list > Cs551@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/cs551 From asyed at usc.edu Tue Apr 26 22:05:22 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 22:08:35 2005 Subject: [Csci551-talk] Packet drops in TA code Message-ID: <000601c54ae6$bf073020$6500a8c0@A2D> Hi all, As brought to my notice by Michael Stephens (thanks :)), the TA code is not dropping packets, if they are specified, only in the selectnSend() function, in the clientNode.cpp. Please every body include that portion in the code by modifying the line of code as follows: Change sendto(listenSockfd, &downloadReq,sizeof(SClntSegReq),0,(sockaddr *)(&sendAddr), sizeof(sendAddr)); TO: bool drop = ( (float)rand()/(float)RAND_MAX < myConfig.configInfo.pkt_drop ); // random drop if (drop) { pktsDropped++; } else { sendto(listenSockfd, &downloadReq,sizeof(SClntSegReq),0,(sockaddr *)(&sendAddr), sizeof(sendAddr)); pktsSent++; } Best Regards, Affan, Syed. From asyed at usc.edu Tue Apr 26 22:39:45 2005 From: asyed at usc.edu (Affan, Syed) Date: Tue Apr 26 22:42:48 2005 Subject: [Csci551-talk] Imp information about Project B Message-ID: <000801c54aeb$8afb6b70$6500a8c0@A2D> Hello all, These are just some guidelines for all students to maximize their score in proj B. 1- Give the writeup with experimentation some thought and time. It is a substantial part of your project score. Don't depend on just getting the code to run. 2- Keep the README and WRITEUP clearly separate in the file that you submit alongwith code. Or submit as too different files. 3- While writing the writup about the project, be faithful to the guidelines in phase 6 i.e. use the hypothesis provided and only fill in the sections asked to be filled in. If you are adding extra remarks/experiments/results, clearly flag them. But they will *not* compensate for you not fulfilling the required portion or failing in being convincing regarding these. Best of luck. Best Regards, Affan, Syed. From mikestephens at gmail.com Tue Apr 26 22:41:58 2005 From: mikestephens at gmail.com (Michael Stephens) Date: Tue Apr 26 22:43:39 2005 Subject: [Csci551-talk] Re: [Cs551] question-logging Message-ID: <55aa073505042622411893a8ba@mail.gmail.com> I am sorry, I do not mean to be monopolizing the discussion board, but now I am really confused. Affan's message says to log the message when it is actually sent, not when it is queued. Xi's email seems to imply that the message should be logged when it is queued (i.e. when the client "thinks" it is sent). Which one is it? (Or have I misinterpreted one or both postings?) Thank you everyone for your continuing help...Michael Affan's message: -------------------------------------------------------------------------------- Subject: IMP all studnets please read ! [Csci551-talk] Assumption: When to start timeout Sorry for the delayed response but it was a good question and needed some thought. The correct approach has got to be to start timer as soon as you buffer the packet. But the log time should be when it is actually sent. I know this can create pathological scenarios, but this is most realistic and we can test your implementation through simpler scenarios :) Thanks. Affan -------------------------------------------------------------------------------- Xi's message: -------------------------------------------------------------------------------- Subject: [Csci551-talk] Re: [Cs551] question-logging Again and again, bandwidth limitation is seperate component to simulate underlying network (Internet) behavior. So the rest of your program don't know when the packets are received. The conclusion is log a message as soon as you send it. -Xi mishari ibrahim almishari wrote: > (1) In the logging of the sent messages,,,,do we log them after completely sending them or we log them as soon as we issue the send them( as soon as we put them in the queue), if this is the case them sending 8 segments will have the same time in the log file? > > -mish -------------------------------------------------------------------------------- From xiw at usc.edu Tue Apr 26 22:47:01 2005 From: xiw at usc.edu (Xi Wang) Date: Tue Apr 26 22:50:36 2005 Subject: [Csci551-talk] Re: [Cs551] question-logging In-Reply-To: <55aa073505042622411893a8ba@mail.gmail.com> References: <55aa073505042622411893a8ba@mail.gmail.com> Message-ID: <426F2755.6020904@usc.edu> Right, please disregard my post. Let's use Affan's approach by create timestamp when a packet is actually sent. That would be better for grading. -Xi Michael Stephens wrote: > I am sorry, I do not mean to be monopolizing the discussion board, but > now I am really confused. > > Affan's message says to log the message when it is actually sent, not > when it is queued. > > Xi's email seems to imply that the message should be logged when it is > queued (i.e. when the client "thinks" it is sent). > > Which one is it? (Or have I misinterpreted one or both postings?) > > Thank you everyone for your continuing help...Michael > > Affan's message: > -------------------------------------------------------------------------------- > Subject: IMP all studnets please read ! [Csci551-talk] Assumption: > When to start timeout > Sorry for the delayed response but it was a good question and needed > some thought. > The correct approach has got to be to start timer as soon as you buffer > the packet. But the log time should be when it is actually sent. I know > this can create pathological scenarios, but this is most realistic and > we can test your implementation through simpler scenarios :) > > Thanks. > Affan > -------------------------------------------------------------------------------- > > Xi's message: > -------------------------------------------------------------------------------- > Subject: [Csci551-talk] Re: [Cs551] question-logging > Again and again, bandwidth limitation is seperate component to simulate > underlying network (Internet) behavior. So the rest of your program > don't know when the packets are received. The conclusion is log a > message as soon as you send it. > > -Xi > mishari ibrahim almishari wrote: > > >>(1) In the logging of the sent messages,,,,do we log them after completely sending them or we log them as soon as we issue the send them( as soon as we put them in the queue), if this is the case them sending 8 segments will have the same time in the log file? >> >>-mish > > -------------------------------------------------------------------------------- From ramasubr at usc.edu Wed Apr 27 10:57:26 2005 From: ramasubr at usc.edu (nangavalli ramasubramanian) Date: Wed Apr 27 10:57:42 2005 Subject: [Csci551-talk] Re: Question on BW limiting Message-ID: Hi, I know, this question is odd to be sent at this last minute. By BW limitation, I would like to know if the sender has to queue all the requested segments and send them in sequential order ? This is what is mentioned in the Project B requirement. Also, does the BW limitation means, the sender sends the required segments to the requester until the time out expires and then again sends the segments for the next round? The current TA's code seems to be sending the segments in this order. Thanks. NR. From asyed at usc.edu Wed Apr 27 11:44:37 2005 From: asyed at usc.edu (Affan, Syed) Date: Wed Apr 27 11:47:23 2005 Subject: [Csci551-talk] RE: Question on BW limiting In-Reply-To: Message-ID: <000201c54b59$2c5a86f0$6500a8c0@A2D> The specs very clearly state what we want as BW limiting.. They even give an example.. Note that we are not distinguishing b/w pkts, just queue all outgoing pkts. I am not sure what you mean by your second question, queueing is done at the phy layers.. So it should not be aware of any application layer TO. Best Regards, Affan, Syed. -----Original Message----- From: nangavalli ramasubramanian [mailto:ramasubr@usc.edu] Sent: Wednesday, April 27, 2005 10:57 AM To: Affan, Syed Cc: csci551-talk@mailman.isi.edu Subject: Re: Question on BW limiting Hi, I know, this question is odd to be sent at this last minute. By BW limitation, I would like to know if the sender has to queue all the requested segments and send them in sequential order ? This is what is mentioned in the Project B requirement. Also, does the BW limitation means, the sender sends the required segments to the requester until the time out expires and then again sends the segments for the next round? The current TA's code seems to be sending the segments in this order. Thanks. NR. From rmchandr at usc.edu Wed Apr 27 23:57:38 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Wed Apr 27 23:58:40 2005 Subject: [Csci551-talk] Same random segments across clients. Message-ID: <502964673108a.427018e2@usc.edu> For the R algorithm, although, I get 8 different random segments per group update, all clients tend to choose the same random segments in their group updates, making it no different from the S algorithm (with all of them choosing the same order of segments). All hacks seem to help only with choosing 8 random segments but not differently across clients. Anyone with the same problem ? Regards, Rashmi. From srubin at flash.net Thu Apr 28 08:23:24 2005 From: srubin at flash.net (S. Rubin) Date: Thu Apr 28 08:24:02 2005 Subject: [Csci551-talk] Same random segments across clients. Message-ID: <20050428152324.51336.qmail@web81306.mail.yahoo.com> What are you using to seed the rand function? If you use the "seconds" portion of the timeval struct, you should get a different seed each time, and therefore start with a different number. See if that helps. Sophia For the R algorithm, although, I get 8 different random segments per group update, all clients tend to choose the same random segments in their group updates, making it no different from the S algorithm (with all of them choosing the same order of segments). All hacks seem to help only with choosing 8 random segments but not differently across clients. Anyone with the same problem ? Regards, Rashmi. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050428/b434a9bb/attachment.html From rmchandr at usc.edu Thu Apr 28 11:29:52 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Thu Apr 28 11:33:26 2005 Subject: [Csci551-talk] Same random segments across clients. Message-ID: <67365e8337d47.4270bb20@usc.edu> Hi Sophia, Thanks for the mail. I was using a variable (a large number) to seed the rand function and was doubling that variable before each call to rand. So, I got 8 different random segments but all clients started off with the same variable value. Now I used the microsecond part of the timeval structure and even that seems to give a better randomization. Thanks for the suggestion. Regards, Rashmi. ----- Original Message ----- From: "S. Rubin" Date: Thursday, April 28, 2005 7:23 am Subject: [Csci551-talk] Same random segments across clients. > > What are you using to seed the rand function? If you use the > "seconds" portion > > of the timeval struct, you should get a different seed each time, > and therefore > > start with a different number. See if that helps. > > > > Sophia > > > > For the R algorithm, although, I get 8 different random segments > per group update, all clients tend to choose the same random > segments in their group updates, making it no different from the S > algorithm (with all of them choosing the same order of segments). > All hacks seem to help only with choosing 8 random segments but > not differently across clients. Anyone with the same problem ? > > Regards, > Rashmi. > > > From johnh at ISI.EDU Thu Apr 28 14:24:09 2005 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 28 14:25:47 2005 Subject: [Csci551-talk] Assumption: When to start timeout In-Reply-To: <55aa073505042419333a7f0e7d@mail.gmail.com> Message-ID: <200504282124.j3SLO9Sh014338@dash.isi.edu> On Sun, 24 Apr 2005 19:33:24 PDT, Michael Stephens wrote: >I assume that the timeout counter should start when the client >"queues" a message to be sent, not when the message is actually sent >after delays. In our system we are simulating delays in the network >connection; in a real system the client would probably not be aware of >such delays. > >1. Is it valid to assume that the timeout counter should start when >the client "queues" a message, not when the message is actually sent? >2. Should we log the time that the client "queues" a message to be >sent as well as the time the message is actually sent after delays, or >only the time the message is actually sent? In general, when the project doesn't specify something, you should do what you think makes most sense and note the potential ambiguity in your README. Your reasonsing sounds reasonable, though. -John Heidemann From johnh at ISI.EDU Thu Apr 28 15:00:59 2005 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 28 15:02:46 2005 Subject: [Csci551-talk] Assumption: When to start timeout In-Reply-To: <200504282124.j3SLO9Sh014338@dash.isi.edu> Message-ID: <200504282200.j3SM0xwl015527@dash.isi.edu> On Thu, 28 Apr 2005 14:24:09 PDT, John Heidemann wrote: >On Sun, 24 Apr 2005 19:33:24 PDT, Michael Stephens wrote: >>I assume that the timeout counter should start when the client >>"queues" a message to be sent, not when the message is actually sent >>after delays. In our system we are simulating delays in the network >>connection; in a real system the client would probably not be aware of >>such delays. >> >>1. Is it valid to assume that the timeout counter should start when >>the client "queues" a message, not when the message is actually sent? >>2. Should we log the time that the client "queues" a message to be >>sent as well as the time the message is actually sent after delays, or >>only the time the message is actually sent? > >In general, when the project doesn't specify something, you should do >what you think makes most sense and note the potential ambiguity in >your README. > >Your reasonsing sounds reasonable, though. > > -John Heidemann Note that Affan clarified this issue in a follow-on e-mail message. But, to repeat: In general, when the project doesn't specify something, you should do what you think makes most sense and note the potential ambiguity in your README. -John Heidemann From yogendra at usc.edu Thu Apr 28 15:57:30 2005 From: yogendra at usc.edu (hariram yogendran) Date: Thu Apr 28 15:58:42 2005 Subject: [Csci551-talk] Finding total number of segments Message-ID: <8127a44236781.4270f9da@usc.edu> Hi, For algorithm T we need to find the total number of segments in the file before we start downlading the file to calculate the sequence.For this does the seed have to calculate the number of segments send it to the tracker (this means that we will need new messege type for sending the total segments).Then the tracker will send this to all the clients.Or can I assume that the total number of segments is going to be fixed.Or is it going to be the maximm number of segments.Please clarify so that I can proceed. Regards, Hari. From rmchandr at usc.edu Thu Apr 28 16:23:01 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Thu Apr 28 16:24:43 2005 Subject: [Csci551-talk] Finding total number of segments Message-ID: <83a08ca2357e2.42710de5@usc.edu> If 'somebody' replies with a non-zero value to your INFO_REQ message, you can be sure that, that 'somebody' is either the seed or is a client who has downloaded some segments. In either case, we know that the seed is already existing in the system. So, you can check to see the maximum value advertised by members in the group update, and use it as the total file size. If nobody replies with a non-zero value for your INFO_REQ, timeout and retry again. Hope it helps. Regards, Rashmi. ----- Original Message ----- From: hariram yogendran Date: Thursday, April 28, 2005 3:57 pm Subject: [Csci551-talk] Finding total number of segments > Hi, > > > For algorithm T we need to find the total number of segments in > the file before > we start downlading the file to calculate the sequence.For this > does the seed > have to calculate the number of segments send it to the tracker > (this means that > we will need new messege type for sending the total segments).Then > the tracker > will send this to all the clients.Or can I assume that the total > number of segments > is going to be fixed.Or is it going to be the maximm number of > segments.Please > clarify so that I can proceed. > > Regards, > Hari. > > From xiw at usc.edu Thu Apr 28 18:24:59 2005 From: xiw at usc.edu (Xi Wang) Date: Thu Apr 28 18:27:38 2005 Subject: [Csci551-talk] Re: [Cs551] methodology in phase 6 In-Reply-To: <06e10cdafc1304df878409f3a885d5eb@usc.edu> References: <06e10cdafc1304df878409f3a885d5eb@usc.edu> Message-ID: <42718CEB.4090401@usc.edu> Please include seed. So "2" would mean one-to-one downloading. -Xi Jonathan May wrote: > We are required to compare the algorithms with 2, 5, and 10 peers. Does > this number include the seed? e.g. for "2" should I have 2 requestors > and one seed, or one seed and one requestor? > > jon > > _______________________________________________ > Cs551 mailing list > Cs551@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/cs551 From xiw at usc.edu Thu Apr 28 18:32:38 2005 From: xiw at usc.edu (Xi Wang) Date: Thu Apr 28 18:35:36 2005 Subject: [Csci551-talk] Re: [Cs551] means and stdev In-Reply-To: <9c5830fecbc87f3c535afd8e028add6a@usc.edu> References: <9c5830fecbc87f3c535afd8e028add6a@usc.edu> Message-ID: <42718EB6.5080001@usc.edu> > "run the algorithms 5 times for each combination and report the means > and standard deviation." > > Let's consider running algorithm R with 10 peers. I get 5 experiments, > each with 10 running times. I could report 5 mean/stdevs, one for each ^^^^^^^^^^^^^^^^^ Not 10 readings - you should get one overall time. Count the time from beginning to the point when the last node finishes downloading. > run, or the mean/stdev of all peers over all experiments. Which is desired? -Xi From xiw at usc.edu Thu Apr 28 18:39:51 2005 From: xiw at usc.edu (Xi Wang) Date: Thu Apr 28 18:43:39 2005 Subject: [Csci551-talk] Finding total number of segments In-Reply-To: <8127a44236781.4270f9da@usc.edu> References: <8127a44236781.4270f9da@usc.edu> Message-ID: <42719067.80301@usc.edu> You can get total file size by sending INFO_REQ to peers. INFO_REP should contain total file size information. Even if a peer only has one segment it still can/should know the total size. -Xi hariram yogendran wrote: > Hi, > > > For algorithm T we need to find the total number of segments in the file before > we start downlading the file to calculate the sequence.For this does the seed > have to calculate the number of segments send it to the tracker (this means that > we will need new messege type for sending the total segments).Then the tracker > will send this to all the clients.Or can I assume that the total number of segments > is going to be fixed.Or is it going to be the maximm number of segments.Please > clarify so that I can proceed. > > Regards, > Hari. > From nsachary at usc.edu Fri Apr 29 11:28:30 2005 From: nsachary at usc.edu (Narendra Acharya) Date: Fri Apr 29 11:29:52 2005 Subject: [Csci551-talk] Experimental Writeup Confusion Message-ID: <0IFQ00GI70NJ4F50@msg-mx3.usc.edu> I am a bit confused about Xi's answer. According to him we have to take the time from start to the end of the completion of simulation. But this works only if we consider that all the peers start at the same time. If we consider different start time for different peers then we would not be able to judge the performance of different algorithms. Therefore isn't it better if we consider the individual file download times for each peer and then take required statistics? Because when evaluating the algorithms we are not bothered about the time it take for a simulation to complete, but rather are concerned about getting better file download times. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050429/65ea6915/attachment.html From xiw at usc.edu Fri Apr 29 12:21:39 2005 From: xiw at usc.edu (Xi Wang) Date: Fri Apr 29 12:25:10 2005 Subject: [Csci551-talk] Re: [Cs551] Project- b-writeup In-Reply-To: <25b38863196a1.42720511@usc.edu> References: <25b38863196a1.42720511@usc.edu> Message-ID: <42728943.5030509@usc.edu> mishari ibrahim almishari wrote: > Hi,,, > (1) In the methodology section, we run the algorithms 5 times for each combination.....Are the parameters the same in the 5 runs or we can change some?and if we have to change some parameters what we should change? for example do we only change the delay of the nodes or the starting time or both...or what exactly? > Same parameters. The purpose is to see how much random variations are there. > (2)Start time of the running > > Do we measure the start of the running time when the manager starts? Or when the tracker starts or when the first client start? or there is no difference? > First client > End of the run time.... > Do we consider the ending of the running as the end of the execution of the last client or when the tracker ends (which means all the clients ended) or no difference.....? > End of downloading > > (3)When we perform the experiments of the free loader....I believe that we are comparing the performance when there are free loaders and when there are not...Question...do we use one specific selection algorithm or use them all in different cases when trying to compare? > > -mish > This is not specified so it's up to you. You don't have to compare multiple algorithms. -Xi From xiw at usc.edu Fri Apr 29 12:33:03 2005 From: xiw at usc.edu (Xi Wang) Date: Fri Apr 29 12:35:40 2005 Subject: [Csci551-talk] Experimental Writeup Confusion In-Reply-To: <0IFQ00GI70NJ4F50@msg-mx3.usc.edu> References: <0IFQ00GI70NJ4F50@msg-mx3.usc.edu> Message-ID: <42728BEF.4070506@usc.edu> It is specified that all nodes start at the same time. The purpose to test the system performance under heavy load. For example if a new download tasks only starts when all previous tasks has completed the a peer-to-peer system would perform no better than a central server. Narendra Acharya wrote: > I am a bit confused about Xi?s answer. According to him we have to take > the time from start to the end of the completion of simulation. But this > works only if we consider that all the peers start at the same time. If > we consider different start time for different peers then we would not > be able to judge the performance of different algorithms. Therefore > isn?t it better if we consider the individual file download times for > each peer and then take required statistics? Because when evaluating the > algorithms we are not bothered about the time it take for a simulation > to complete, but rather are concerned about getting better file download > times. > From xiw at usc.edu Fri Apr 29 12:15:29 2005 From: xiw at usc.edu (Xi Wang) Date: Fri Apr 29 12:42:31 2005 Subject: [Csci551-talk] Re: [Cs551] termination conditions with long latency In-Reply-To: <01d701c54c84$350e2280$69c57d80@VAIO> References: <0f881823fab65b8705e617affebb560a@usc.edu> <426B28EF.6050905@usc.edu> <01d701c54c84$350e2280$69c57d80@VAIO> Message-ID: <427287D1.70404@usc.edu> Let's make the number of iterations to 4. We will also try different global timeout values. -Xi S. Houtris wrote: > Hi Xi, > > What exactly do you mean by "adjusting the termination condition" ? You > mean increasing the number of iterations without progress before > exiting? ie making it 4 (instead of 2) rounds of group update without > "progress" for a seed before exiting, and 6 (instead of 4) for a non-seed? > > This is a very easy thing to change but also very important to the > behavior of our program... > > Thanks. > > Solon > > > ----- Original Message ----- From: "Xi Wang" > To: > Sent: Saturday, April 23, 2005 10:04 PM > Subject: Re: [Cs551] termination conditions with long latency > > >> First, bandwidth is different from latency. For project B bandwidth >> limitation is added and the latency test would be the same as project A. >> >> Yes please adjust termination condition. We may increase global >> timeout for testcases with low bandwidth. If low bandwidth is the only >> reason for node to exit before completion, it would not be considered >> as an error. >> >> -Xi >> >> >> Jonathan May wrote: >> >>> In projects a we were supposed to allow graceful termination of nodes >>> following reasonable constraints. For seeds or nodes that became >>> seeds, I allowed termination if 2*the request timeout seconds had >>> expired without any incoming traffic (i.e. requests). If, as the TAs >>> have proposed, latency times are bumped up to the order of seconds, >>> this becomes a problem if the request timeout is left at, say, 5 >>> (seconds). 5 nodes with a latency of 1 second in the midst of a large >>> packet request that happens not to touch the seed (as might be the >>> case after a certain point) will easily exceed the termination >>> condition and the seed will die. May I assume that large latencies >>> will accompany large request timeouts (which seems like a reasonable >>> assumption)? Or should I just allow for more hanging on (changing my >>> multiplication constant to something like 10)? Or is there another >>> solution? >>> >>> thanks, >>> jon >>> >>> _______________________________________________ >>> Cs551 mailing list >>> Cs551@catarina.usc.edu >>> http://catarina.usc.edu/mailman/listinfo/cs551 >> >> _______________________________________________ >> Cs551 mailing list >> Cs551@catarina.usc.edu >> http://catarina.usc.edu/mailman/listinfo/cs551 > > > _______________________________________________ > Cs551 mailing list > Cs551@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/cs551 From aneeketp at usc.edu Fri Apr 29 13:59:47 2005 From: aneeketp at usc.edu (Aneeket Patil) Date: Fri Apr 29 14:00:43 2005 Subject: [Csci551-talk] Ideal Freeloader Message-ID: <4272A043.6030609@usc.edu> Whenever a node acts as a freeloader.........ideally in a real world scenario......he/she never announces that it has the file to the tracker right? So ideally no node should even send the request for a file to a freeloader. I just wanted to confirm , that in Project B , we are supossed to request the freeloader........and log the response. We are doing this only to observe the effects of freeloaders ,right? So, In an real world scenario , the freeloader never announces that it has the file to the tracker , right? Aneeket From rmchandr at usc.edu Fri Apr 29 14:09:24 2005 From: rmchandr at usc.edu (rashmi chandrasekhar) Date: Fri Apr 29 14:09:42 2005 Subject: [Csci551-talk] Ideal Freeloader Message-ID: <1faf145b279d.42724014@usc.edu> If you have a centralized management of information (the tracker) like our Freebits project or the Bit Torrent, a freeloader has to request the tracker to send him/her the list of clients who have the file (otherwise from whom will the freeloader download the segments from ?). The tracker would then store this guy's ID and send it to other nodes upon request for a group update. These other nodes will request the freeloader (they dont know he/she is a freeloader) for information. So, querying a freeloader CAN happen in a practical scenario too (as in the Bit Torrent case). Regards, Rashmi. ----- Original Message ----- From: Aneeket Patil Date: Friday, April 29, 2005 1:59 pm Subject: [Csci551-talk] Ideal Freeloader > Whenever a node acts as a freeloader.........ideally in a real > world > scenario......he/she never announces that it has the file to the > tracker > right? > So ideally no node should even send the request for a file to a > freeloader. I just wanted to confirm , that in Project B , we > are supossed to > request the freeloader........and log the response. > We are doing this only to observe the effects of freeloaders ,right? > So, In an real world scenario , the freeloader never announces > that it > has the file to the tracker , right? > Aneeket > > From srubin at flash.net Fri Apr 29 16:19:57 2005 From: srubin at flash.net (S. Rubin) Date: Fri Apr 29 16:20:51 2005 Subject: [Csci551-talk] mixed instructions from TAs Message-ID: <20050429231957.39038.qmail@web81309.mail.yahoo.com> Can the TAs synch up the responses, please, as we are getting some mixed instructions. For example, I posed a quesiton on Apr 20 re: testing of algorithms to be done with all clients starting at the same time. Affan's responses (see below), implied that it was not a good idea. I do not wish to re-run and re-write my tests and write-up due to the change in view couple of days before the project is due, but I do not want to get penalized either. I ended up taking the mean of all clients' elapsed time and then taking the mean of the means and the standard deviation at the end of each run - more work, but a better estimate. Here is the trail of Q&A: My question: 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). Affan's response # 1 > How do they say that? I have reread the specs but nothing seems to imply that, and really the algorithm is localized, it shouldn't be doen with assumtion of nodes starting at the same time. My rebuttal: Specs state the following for Part A: First paragraph, last sentence: "This algorithm should focus all peers on the same part of the file at the same time if they start at the same time." Then, the very next sentnce states: "Question for README: how do you expect Algorithm S to perform compared to Algorithm R assuming all nodes start at exactly the same time? Why does it perform better or worse?" and again for Part B, Question for README states the same thing. Is it meant to be purely theoretical and not to be used for test cases? Affan's response, which I took to mean "not a good idea": Well you can use this condition to distill the behavior of the algorith, Your program however should not *use* this as a neccecary condition. In other words, simplify the infput to beter understand the algo, but donot assume that we will (for checking) provide such simple input. Here is the trail from Xi: It is specified that all nodes start at the same time. The purpose to test the system performance under heavy load. For example if a new download tasks only starts when all previous tasks has completed the a peer-to-peer system would perform no better than a central server. Narendra Acharya wrote: > I am a bit confused about Xi’s answer. According to him we have to take > the time from start to the end of the completion of simulation. But this > works only if we consider that all the peers start at the same time. If > we consider different start time for different peers then we would not > be able to judge the performance of different algorithms. Therefore > isn’t it better if we consider the individual file download times for > each peer and then take required statistics? Because when evaluating the > algorithms we are not bothered about the time it take for a simulation > to complete, but rather are concerned about getting better file download > times. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050429/bda19b39/attachment.html From asyed at usc.edu Fri Apr 29 19:13:02 2005 From: asyed at usc.edu (Affan, Syed) Date: Fri Apr 29 19:14:41 2005 Subject: FW: [Csci551-talk] mixed instructions from TAs Message-ID: <000201c54d2a$280af8a0$0300a8c0@A2D> I am sorry if my earlier reply confused you, but my only point was to state that you can run with same startup times for your simulation results but donot *code* the algo to work only with nodes starting at the same time. We ahve to test if you have implemented the algo A to work in all scenario's, but for the performance analysis you can run with the same nodes - that is what "Well you can use this condition to distill the behavior of the algorithm". meant In any case, if you can pull off correct inferences from diverse starting conditions, then that is okay, it is just more difficult to do so. Normally you try to vary as few parameter to single out the effect of a single parameter. I hope there is no more confustion. Thank you. Best Regards, Affan, Syed. -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of S. Rubin Sent: Friday, April 29, 2005 4:20 PM To: csci551-talk@mailman.isi.edu Subject: [Csci551-talk] mixed instructions from TAs Can the TAs synch up the responses, please, as we are getting some mixed instructions. For example, I posed a quesiton on Apr 20 re: testing of algorithms to be done with all clients starting at the same time. Affan's responses (see below), implied that it was not a good idea. I do not wish to re-run and re-write my tests and write-up due to the change in view couple of days before the project is due, but I do not want to get penalized either. I ended up taking the mean of all clients' elapsed time and then taking the mean of the means and the standard deviation at the end of each run - more work, but a better estimate. Here is the trail of Q&A: My question: 2. For phase 6, is it correct to assume that for random algorithm all nodes start at the same time? (Parts A and B state that about 2 other algorithms). Affan's response # 1 > How do they say that? I have reread the specs but nothing seems to imply that, and really the algorithm is localized, it shouldn't be doen with assumtion of nodes starting at the same time. My rebuttal: Specs state the following for Part A: First paragraph, last sentence: "This algorithm should focus all peers on the same part of the file at the same time if they start at the same time." Then, the very next sentnce states: "Question for README: how do you expect Algorithm S to perform compared to Algorithm R assuming all nodes start at exactly the same time? Why does it perform better or worse?" and again for Part B, Question for README states the same thing. Is it meant to be purely theoretical and not to be used for test cases? Affan's response, which I took to mean "not a good idea": Well you can use this condition to distill the behavior of the algorith, Your program however should not *use* this as a neccecary condition. In other words, simplify the infput to beter understand the algo, but donot assume that we will (for checking) provide such simple input. Here is the trail from Xi: It is specified that all nodes start at the same time. The purpose to test the system performance under heavy load. For example if a new download tasks only starts when all previous tasks has completed the a peer-to-peer system would perform no better than a central server. Narendra Acharya wrote: > I am a bit confused about Xi's answer. According to him we have to take > the time from start to the end of the completion of simulation. But this > works only if we consider that all the peers start at the same time. If > we consider different start time for different peers then we would not > be able to judge the performance of different algorithms. Therefore > isn't it better if we consider the individual file download times for > each peer and then take required statistics? Because when evaluating the > algorithms we are not bothered ab! out the time it take for a simulation > to complete, but rather are concerned about getting better file download > times. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20050429/343ce045/attachment-0001.html From xiw at usc.edu Sat Apr 30 14:00:51 2005 From: xiw at usc.edu (Xi Wang) Date: Sat Apr 30 14:03:50 2005 Subject: [Csci551-talk] Re: [Cs551] something wrong in ClientNode::selectnSendSegReq() In-Reply-To: <0IFQ0004IT2FOE00@msg-mx3.usc.edu> References: <0IFQ0004IT2FOE00@msg-mx3.usc.edu> Message-ID: <4273F203.7010804@usc.edu> Could you explian the difference between the two methods you described? -Xi Kelvin Chou wrote: > Dear Xi, > Please correct me if I am wrong. Seems the function ClientNode::selectnSendSegReq() does not try to find at most 8 segments, instead it just tries to find segments 8 times... > > Kelvin Chou > From urvikkup at usc.edu Sat Apr 30 14:22:13 2005 From: urvikkup at usc.edu (urvikkumar patel) Date: Sat Apr 30 14:22:40 2005 Subject: [Csci551-talk] 3 levels of freeloaders Message-ID: <5164616f7636.42739495@usc.edu> Hi, In the project specification, part 4 freeloaders 4th paragraph. It was written that "You should consider the 3 levels of freeloaders." Can you explain me what is the meaning of the 3 levels of freeloaders. Thanks Urvik From asyed at usc.edu Sat Apr 30 14:25:10 2005 From: asyed at usc.edu (Affan, Syed) Date: Sat Apr 30 14:26:40 2005 Subject: [Csci551-talk] RE: 3 levels of freeloaders In-Reply-To: <5164616f7636.42739495@usc.edu> Message-ID: <000e01c54dcb$1b6e7210$0300a8c0@A2D> We are basically refering to changing the percentage of free loaders in the network. Thanks. Best Regards, Affan, Syed. -----Original Message----- From: urvikkumar patel [mailto:urvikkup@usc.edu] Sent: Saturday, April 30, 2005 2:22 PM To: asyed@usc.edu; csci551-talk@ISI.EDU Subject: 3 levels of freeloaders Hi, In the project specification, part 4 freeloaders 4th paragraph. It was written that "You should consider the 3 levels of freeloaders." Can you explain me what is the meaning of the 3 levels of freeloaders. Thanks Urvik From xiw at usc.edu Sat Apr 30 23:14:43 2005 From: xiw at usc.edu (Xi Wang) Date: Sat Apr 30 23:17:41 2005 Subject: [Csci551-talk] Re: [Cs551] something wrong in ClientNode::selectnSendSegReq() In-Reply-To: <5a0a80be19ef.4273bf2b@usc.edu> References: <5a0a80be19ef.4273bf2b@usc.edu> Message-ID: <427473D3.9050905@usc.edu> No the code doesn't work as you described. It will pick 8 segments. -Xi chao-chin chou wrote: > Hi, > By " try to find at most 8 segments" I mean the for loop runs until it finds 8 segments or it finds that no more segment is available, while " tries to find segments 8 times " means the for loop just loop 8 times no matter how many segments it has found. > > Kelvin > > ----- Original Message ----- > From: Xi Wang > Date: Saturday, April 30, 2005 2:00 pm > Subject: Re: [Cs551] something wrong in ClientNode::selectnSendSegReq() > > >>Could you explian the difference between the two methods you >>described? >>-Xi >> >>Kelvin Chou wrote: >> >> >>>Dear Xi, >>>Please correct me if I am wrong. Seems the function >> >>ClientNode::selectnSendSegReq() does not try to find at most 8 >>segments, instead it just tries to find segments 8 times... >> >>>Kelvin Chou >>> >> >>_______________________________________________ >>Cs551 mailing list >>Cs551@catarina.usc.edu >>http://catarina.usc.edu/mailman/listinfo/cs551 >> > >