From vern at icir.org Sat Aug 26 12:34:24 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 26 Aug 2006 12:34:24 -0700 Subject: [EE122] testing mail to ee122@icsi.berkeley.edu Message-ID: <200608261934.k7QJYOd0014495@jaguar.icir.org> From vern at icir.org Sun Sep 3 08:55:10 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 03 Sep 2006 08:55:10 -0700 Subject: [EE122] update on textbooks for EE 122 Message-ID: <200609031555.k83FtAsa020003@jaguar.icir.org> I've talked with the textbook folks. On Thursday they said "we had already reordered earlier this week for more books to arrive hopefully by tomorrow"; this was regarding the Peterson/Davie text. On Friday they wrote "An update - Unix Network Programming is out of stock at the publisher until September 6 so we hope to have it early the week of September 11". So, (1) can someone confirm whether the Peterson/Davie textbook is now in stock, and (2) are folks finding problems with getting the Stevens text as well as the Peterson/Davie text? I'm really sorry about this :-(. The texts were ordered quite a while ago, so I'm not sure why there are problems. I'm arranging to have an electronic copy of Chapter 1 for the P/D text available by early this coming week if the textbook isn't available then; and in any case, we'll be slipping the due date for Homework #1. Oh, and one more question: only 21 students are subscribed to this list (appended). If you know of other students who aren't on it yet, please nudge them to subscribe. I'd also be interested in understanding why more haven't subscribed, as this list will be used for communications throughout the course. Vern awaage at gmail.com binetude at eecs.berkeley.edu brad at ischool.berkeley.edu dilip.antony.joseph at gmail.com djacobs at berkeley.edu dtv at berkeley.edu ee122-bk at imail.eecs.berkeley.edu glennkim at berkeley.edu johnpaulhawley at yahoo.com kevin.liu at gmail.com kwoyach at eecs.berkeley.edu laupeter at berkeley.edu lyahdav at berkeley.edu mishraak at berkeley.edu mjohnston at berkeley.edu ri_chen at berkeley.edu sujay at berkeley.edu svol at berkeley.edu theochu at berkeley.edu tuanphan06 at gmail.com ulf.strohmaier at tu-harburg.de usaini08 at berkeley.edu vern at icir.org yuhung at berkeley.edu From vern at icir.org Tue Sep 5 10:51:08 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 05 Sep 2006 10:51:08 -0700 Subject: [EE122] electronic version of chapter 1 of Peterson/Davie text Message-ID: <200609051751.k85Hp8xG012790@jaguar.icir.org> Turns out it's available at: http://books.elsevier.com/bookscat/samples/155860832X/ch-01.pdf - Vern From vern at icir.org Tue Sep 5 23:25:49 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 05 Sep 2006 23:25:49 -0700 Subject: [EE122] a number of course announcements Message-ID: <200609060625.k866PnWF054410@jaguar.icir.org> [now added to the announcement web page] * Because the bookstores are delayed in stocking the Peterson/Davie text, the due date for Homework #1 is postponed one week to Sept. 20. * In the interim, see the announcement page for a link to an electronic version of Chapter 1. * During the week of Sept. 11-15, Vern and Dilip will be away at ACM SIGCOMM 2006. Consequently, they will not have office hours. * No lecture on Weds Sept. 13. * The PDF files for the lecture notes stall some of the campus printers. Please use one of the following newer printers to print them: lw105 (105 Cory) lw119 (119 Cory) lw199 (199 Cory) lw330 (330 Soda) lw349 (349 Soda, card-key access only) * Problem 2 in the homework ("ping") has been updated to change some of the probed hosts to fix ones that don't respond. From nlv85 at berkeley.edu Wed Sep 6 18:36:06 2006 From: nlv85 at berkeley.edu (Neelav Rana) Date: Wed, 6 Sep 2006 18:36:06 -0700 Subject: [EE122] HW 1 changes Message-ID: <760D4F6D-CC48-4234-BA49-7459F8626E96@berkeley.edu> Is it just me or are the addresses we are supposed to ping exactly the same. The problematic host was nyu.edu and its still in the assignment. Neelav From vern at icir.org Wed Sep 6 19:04:38 2006 From: vern at icir.org (Vern Paxson) Date: Wed, 06 Sep 2006 19:04:38 -0700 Subject: [EE122] HW 1 changes In-Reply-To: <760D4F6D-CC48-4234-BA49-7459F8626E96@berkeley.edu> (Wed, 06 Sep 2006 18:36:06 PDT). Message-ID: <200609070204.k8724c1Z020350@jaguar.icir.org> > Is it just me or are the addresses we are supposed to ping exactly > the same. The problematic host was nyu.edu and its still in the > assignment. Argh, my screw-up. Please try it again now and let me know if there's still a problem. Vern From vern at icir.org Sat Sep 9 13:50:10 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 09 Sep 2006 13:50:10 -0700 Subject: [EE122] some questions & answers Message-ID: <200609092050.k89KoA8I033531@jaguar.icir.org> Jack Markarian sent along the following questions via email, which I thought I'd answer using the mailing list as they're likely of general interest. Please feel free to send questions to the mailing list. Vern > 1) On a telephone network, how is it possible that two people speak at the > same time? I mean, how is the wire sending a signal two both receivers? > Is this done by frequency multiplexing? If so, is there a protocol where > the caller knows to accept a certain frequency and send its signals in > another frequency, and the receiver does the opposite? First, some terminology. If a link (or more generally a series of links comprising a path across a network, like with a telephone circuit) allows transmission in both directions then it's termed a "duplex" link. If not, it's a "simplex" link. (So television broadcasts are simplex, for example.) If a duplex link can be used *simultaneously* in both directions, then it's "full duplex". Otherwise, it's "half duplex", and the two directions have to figure out how to somehow take turns using it. For example, with CB radio the users coordinate by saying "Over" when they're done talking and the other person can start. Often, full duplex links are implemented by using two wires (or radio frequencies) rather than one. It's also possible with some link technologies to use multiplexing; there's even an approach where each side remembers what it sent and subtracts it out from the combined signal it receives. For the telephone system, I believe (but am not sure) that most landline phones simply use two wires ("twisted pair"), and cell phones use different frequencies. > 2) In discussion, Sukun discussed time multiplexing in telephone networks > in the following fashion: "Assume you have two wires that each could > handle 50kbps, and then they are going to share a trunk whose bandwith is > 100kbps. Therefore, the trunk could handle the total bandwith required by > those two individual lines". My confusion comes from the fact that the > trunk is now giving each line half a second to accept 50kb which takes the > smaller line one complete second to produce. Could you explain how this > delay works? First, the trunk might divide time up much more finely than splitting entire seconds into 500 ms frames. Second, speed mismatches are dealt with using buffers. These might be very small (e.g., an individual byte) or significantly larger, depending on the granularity of the time-division. Finally, another approach would be to change the *encoding* of the signals, such that a different pattern is used on the high-speed link which directly combines the signals of the two lower-speed links. > 3) When you type into your browser, www.google.com, how does your browser > know the location of the DNS server in order to get the actual address of > google? Do all DNS servers have information about every domain? Or do > particular DNSs serve particular domains? Great question! We'll go into this in detail later this month, but in brief: (1) Your browser generally will be using the OS for name resolution rather than doing it directly. (2) The OS will be configured with the address of a nearby DNS server (not with its name, as obviously that would have bootstrap problems!). (3) The nearby DNS server has hardwired into it the address of the *root* of the DNS naming hierarchy. (In fact, it likely has wired into it multiple addresses for the root, as we'll discuss.) It then asks the root for the name server for "com"; asks that name server for the name server for "google.com"; and asks *that* name server for the address of "www.google.com". (4) There's a ton of caching used to cut down the number of lookups that actually get made. (5) Regarding "do particular DNSs serve particular domains?", one of the crucial properties of the DNS is that there's a single global instance of it, and thus all names are accessible from within the same system. That said, particular DNS *servers* are responsible for particular domains; this is how the system (hugely) distributes its load. > 4) From lecture 2 slide 48; You said that if you type that GET command in > telnet on port 80, you should be able to get data from the server. I > haven't been able to connect to any host through telnet on either port 80 > or 23. So, what is telnet used for and could I use it to connect to a > host in order to execute requests from the command line? If not, is there > any http command line support? You have to type a tad more. Here's what I used just now to fetch Google's home page: cory 1 % telnet www.google.com 80 Trying 66.102.7.147... Connected to www.l.google.com. Escape character is '^]'. GET /index.html HTTP/1.0 HTTP/1.0 200 OK Cache-Control: private Content-Type: text/html Set-Cookie: PREF=ID=feabe352f0bbb199:TM=1157834568:LM=1157834568:S=-rRmL3IPw5SgllrH; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Server: GWS/2.1 Date: Sat, 09 Sep 2006 20:42:48 GMT Connection: Close Google
Personalized Home | Sign in
Google

[[ 10 more lines of HTML gobblydegook deleted ]] Of this, the command "telnet www.google.com 80" invokes telnet, instructing it to connect to www.google.com (which it will translate to an address using the DNS) and also to use port 80 rather than the default port for Telnet (23, which you can see in /etc/services). This: Trying 66.102.7.147... Connected to www.l.google.com. Escape character is '^]'. is saying that www.google.com resolved to 66.102.7.147. Then, that the connection to that address succeeded. Note that the name it reports is not www.google.com but www.l.google.com - this is because the name www.google.com translated into a name-pointer (a "CNAME", in DNS lingo) to www.l.google.com (Google does this for load-balancing), which itself then translated to 66.102.7.147. Finally, telnet informs me that the Escape character is control-right-bracket, which I can use to get its attention during my connection. After connecting, I typed: GET /index.html HTTP/1.0 Which is an HTTP (Web) request to fetch the home page using version 1.0 of the HTTP protocol. Google's server replies with: HTTP/1.0 200 OK Cache-Control: private Content-Type: text/html Set-Cookie: PREF=ID=feabe352f0bbb199:TM=1157834568:LM=1157834568:S=-rRmL3IPw5SgllrH; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Server: GWS/2.1 Date: Sat, 09 Sep 2006 20:42:48 GMT Connection: Close The first line informing me that it's speaking version 1.0 also, and that the command has status 200, meaning it succeeded. This is followed by a bunch of headers indicating meta-information associated with the transfer and the content. It then follows this with the content itself, and closes the connection (not shown above). From vern at icir.org Sat Sep 9 14:31:33 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 09 Sep 2006 14:31:33 -0700 Subject: [EE122] when sending a single bit, why is its transmission time 0? Message-ID: <200609092131.k89LVXkR034306@jaguar.icir.org> Dilip passed along the following question from yesterday's section: > If we have just one bit to send, why do we consider the transmit time to be > 0? Are we just ignoring it because it is too small? First off, this is a definitional detail that almost never matters in practice. Second, I disagree with the view in the text that for single bits, all that matters is the propagation time and not the transmit time. The reason I disagree is because I like the simple formulation of how long a packet of B bits takes to send over a link with bandwidth R bits/sec and propagation time T, namely time = T + B/R With the book's definition, strictly speaking this would be time = T + (B-1)/R which is uglier and makes it easy to commit "fencepost" errors. I would bet that the book's definition comes from the question of how do you *measure* propagation time. With their definition, the measurement is well-formed: you can actually send a single bit and time how long it takes to arrive. The definition I prefer would instead require measuring how long does it take for the *beginning* of the signal that encodes a bit to travel from one end of the link to the other - not something you can easily measure. In any case, in this course (and in your professional career :-) you'll do fine with the definition that lets you use "time = T + B/R", and in practice the difference is virtually always too small to matter. Vern From vern at icir.org Sat Sep 9 17:59:37 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 09 Sep 2006 17:59:37 -0700 Subject: [EE122] Project #1 is out now Message-ID: <200609100059.k8A0xbkP036995@jaguar.icir.org> It's described at http://inst.eecs.berkeley.edu/%7Eee122/fa06/projects/project1.html for you eager beavers who want to get started early on it (a good idea!). The slides for Monday's lecture on Socket Programming are also now available from the class Web page. Vern From vern at icir.org Tue Sep 19 13:01:12 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 19 Sep 2006 13:01:12 -0700 Subject: [EE122] clarification regarding Homework #1 problem 1.13 Message-ID: <200609192001.k8JK1C8D036054@jaguar.icir.org> A number of students have asked about just what the problem means by how "long" is a bit. To clarify, the problem is simply asking how much time does a bit take up ("wide") and how much physical distance ("long"). The latter assumes that when bits move along a link, they come back-to-back; so the distance they take is intimately related to the time they take and the speed of signal propagation in the link. Vern From dilip.antony.joseph at gmail.com Wed Sep 20 15:52:11 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 20 Sep 2006 15:52:11 -0700 Subject: [EE122] project 1: clarifications Message-ID: <4cd0c11b0609201552r23657b40i7a794f50515981@mail.gmail.com> Hello, Some clarifications about project 1 based on the questions that came up during discussion sections: 1. Message buffer size The echo_client program should accept input from the keyboard that can be upto 2048 bytes long. Make sure you size the buffers in echo_client and echo_server appropriately. 2. send() The send() function does not always send the entire data given to it. Make sure to compare the return value of send() with the number of bytes you intended to send . Repeatedly call send() till all the data is sent. 3. recv() The recv() function call does not always read in all the available data in one go. You have to repeatedly call recv() till all the data is received. In this project, you know the number of expected bytes because it is equal to the number of bytes you had sent out. In project 2, you will use some other methods to know when all the bytes have been received. 4. C++ You may use C++ for your project. If you get a missing library error when compiling/linking your code, make sure that /usr/sww/lib is part of your LD_LIBRARY_PATH and try again. 5. Submission instructions 0. Make sure you are registered with the EECS instructional account system (different from registration for the class). You would have been prompted to register the first time you logged in to your instructional account. You can check your registration status by running the command "check-register". If you find yourself not registered, run the command "register". 1. Log in to your instructional account. 2. Create a directory called "proj1" : mkdir proj1 3. Change to that directory: cd proj1 4. Copy all the files that you wish to submit to this directory 5. Run the submit program: submit proj1 6. Make sure that no error messages are displayed. If some error occurs, retry. If it still occurs, contact the TAs. The information in this email is also posted on the Project 1 web page. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20060920/32ee0601/attachment.html From vern at icir.org Tue Sep 26 13:11:03 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 26 Sep 2006 13:11:03 -0700 Subject: [EE122] adjustment to tomorrow's lecture material Message-ID: <200609262011.k8QKB3Rq033448@jaguar.icir.org> FYI, we won't be covering FTP during lecture tomorrow after all. Instead, it will be covered during discussion section, starting with Friday's section. So you can wait a couple of days on skimming RFC 959 if you wish. Vern From dilip.antony.joseph at gmail.com Wed Sep 27 13:53:39 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 27 Sep 2006 13:53:39 -0700 Subject: [EE122] project 1 : clarifications Message-ID: <4cd0c11b0609271353w1efc1e99q15532816f5af4d4a@mail.gmail.com> Handling Error Conditions ------------------------------------- Make sure that your client program does not crash under error conditions like a.) the hostname passed to it fails to resolve b.) the connection to server could not be established. c.) the server crashes/is stopped when the client is connected. Make sure the server does not crash a.) if the client crashes There can be more ways in which the server or client can fail. The most effective strategy to handle errors is to be defensive - If a function returns an error code, always check it and appropriately handle the error, as you are writing the code. Do not leave handling return values for later, as you may forget to put it in the checks. In most cases, you just need to print a human readable error message and exit the program. For example, if the hostname passed to the client does not resolve, your client can print something like: "Unable to resolve xyz.com. Aborting" and quit. End of File ---------------- The client program should be terminated by typing the Ctrl-C character or the End of file character (Ctrl-D). Extra Credit ----------------- If you have implemented some extra credit features or other relevant features we did not specify, make sure to list it in the README.txt so that we don't miss it. -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From dilip.antony.joseph at gmail.com Wed Sep 27 23:15:55 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 27 Sep 2006 23:15:55 -0700 Subject: [EE122] Extra office hours tomorrow (Thursday) Message-ID: <4cd0c11b0609272315u3b86c270q6afe3c12fe99547e@mail.gmail.com> Hi, I will be having extra office hours from 1:45 pm to 2:45 pm tomorrow (Thursday). Just in case you have any questions about project 1, please drop by. I will be near Soda 311. 311 is the room on your left hand side as you enter Soda Hall from the third floor entrance. The room is just OUTSIDE the building. I might be inside the room or if many of you turn up, I will be just outside, in the space between Soda and Etcheverry, so that our discussions do not disturb my office mates. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From tonyw85 at berkeley.edu Wed Sep 27 23:50:17 2006 From: tonyw85 at berkeley.edu (tonyw85 at berkeley.edu) Date: Wed, 27 Sep 2006 23:50:17 -0700 (PDT) Subject: [EE122] Proj 1: sample server In-Reply-To: <4cd0c11b0609272315u3b86c270q6afe3c12fe99547e@mail.gmail.com> References: <4cd0c11b0609272315u3b86c270q6afe3c12fe99547e@mail.gmail.com> Message-ID: <62415.69.109.249.228.1159426217.squirrel@calmail.berkeley.edu> Is the sample server on i1.millennium.berkeley.edu:7788 currently up? My client used to work, but now it's getting "connection refused." -Tony From dilip.antony.joseph at gmail.com Thu Sep 28 05:43:15 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 28 Sep 2006 05:43:15 -0700 Subject: [EE122] Proj 1: sample server In-Reply-To: <62415.69.109.249.228.1159426217.squirrel@calmail.berkeley.edu> References: <4cd0c11b0609272315u3b86c270q6afe3c12fe99547e@mail.gmail.com> <62415.69.109.249.228.1159426217.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0609280543k4ec0a5a6rdbb2fb65d4e911d@mail.gmail.com> Yes, the sample server stopped running some time after I went to bed yesterday night. It is now up again. While the server was down, your connect() call would have failed with the error "Connection refused". I apologize for any inconvenience caused. Regards, Dilip On 9/27/06, tonyw85 at berkeley.edu wrote: > Is the sample server on i1.millennium.berkeley.edu:7788 currently up? My > client used to work, but now it's getting "connection refused." > > -Tony > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From lyahdav at berkeley.edu Thu Sep 28 14:16:52 2006 From: lyahdav at berkeley.edu (Liron Yahdav) Date: Thu, 28 Sep 2006 14:16:52 -0700 Subject: [EE122] Proj1: connect never returns in some cases Message-ID: <000001c6e343$6de70b10$4101a8c0@Liron> When I try calling echo_client using: echo_client cnn.com 7788 For example, the connect() call never returns and the program seems to freeze. Shouldn't it not be able to connect to cnn.com on that port? Do we need to handle this case? Liron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20060928/858ea6ac/attachment.html From vern at icir.org Thu Sep 28 14:27:40 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 28 Sep 2006 14:27:40 -0700 Subject: [EE122] Proj1: connect never returns in some cases In-Reply-To: <000001c6e343$6de70b10$4101a8c0@Liron> (Thu, 28 Sep 2006 14:16:52 PDT). Message-ID: <200609282127.k8SLReGr091042@jaguar.icir.org> > When I try calling echo_client using: > > echo_client cnn.com 7788 > > For example, the connect() call never returns and the program seems to > freeze. Shouldn't it not be able to connect to cnn.com on that port? cnn.com isn't running[*] an echo service. This is why you need to test against the server Dilip has left running as mentioned in the write-up. (You should also test against your own server.) Vern [*] In fact, there's a standard echo service defined to run on UDP and TCP port 7, but most machines have it turned off these days. From lyahdav at berkeley.edu Thu Sep 28 14:34:59 2006 From: lyahdav at berkeley.edu (Liron Yahdav) Date: Thu, 28 Sep 2006 14:34:59 -0700 Subject: [EE122] Proj1: connect never returns in some cases In-Reply-To: <200609282127.k8SLReGr091042@jaguar.icir.org> Message-ID: <000b01c6e345$f6029210$4101a8c0@Liron> I'm just confused why the connect call doesn't return an error message or anything at all. It just never returns and the program stalls. Can we assume we will only try to connect to servers running an echo service? Liron -----Original Message----- From: Vern Paxson [mailto:vern at icir.org] Sent: Thursday, September 28, 2006 2:28 PM To: Liron Yahdav Cc: ee122 at ICSI.Berkeley.EDU Subject: Re: [EE122] Proj1: connect never returns in some cases > When I try calling echo_client using: > > echo_client cnn.com 7788 > > For example, the connect() call never returns and the program seems to > freeze. Shouldn't it not be able to connect to cnn.com on that port? cnn.com isn't running[*] an echo service. This is why you need to test against the server Dilip has left running as mentioned in the write-up. (You should also test against your own server.) Vern [*] In fact, there's a standard echo service defined to run on UDP and TCP port 7, but most machines have it turned off these days. From vern at icir.org Thu Sep 28 14:53:46 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 28 Sep 2006 14:53:46 -0700 Subject: [EE122] Proj1: connect never returns in some cases In-Reply-To: <000b01c6e345$f6029210$4101a8c0@Liron> (Thu, 28 Sep 2006 14:34:59 PDT). Message-ID: <200609282153.k8SLrkBS093728@jaguar.icir.org> > I'm just confused why the connect call doesn't return an error message or > anything at all. It just never returns and the program stalls. It should eventually return with ETIMEDOUT, but only after many minutes of trying (since TCP is tenacious in trying to establish a connection). > Can we assume > we will only try to connect to servers running an echo service? You should handle the connect() call failing in a graceful manner. As noted above, the timeout takes a looong time. What's much quicker is a rejected connection attempt (ECONNREFUSED). That's what cnn.com *should* return, since it's not running a server, but no doubt what's going on is that their firewall is silently discarding your connection attempt rather than signaling rejection, so you wind up in the timeout case. (The underlying details of the timeout case vs. the rejection case will become more clear after we dive into the workings of TCP later in the course.) Try connecting to port 8899 on www.icsi.berkeley.edu. It should return ECONNREFUSED quite promptly. Vern From lyahdav at berkeley.edu Thu Sep 28 20:55:43 2006 From: lyahdav at berkeley.edu (Liron Yahdav) Date: Thu, 28 Sep 2006 20:55:43 -0700 Subject: [EE122] Proj1 tcpdump problems Message-ID: <000f01c6e37b$25cc0cd0$4101a8c0@Liron> I'm unable to get any output from tcpdump from my echo_client or echo_server. I'm doing the following on quasar.cs.berkeley.edu: > tcpdump tcp port 7782 >From another terminal window: > echo_server 7782 >From a 3rd terminal window: > echo_client quasar.cs.berkeley.edu 7782 The data is echoed back from the client to the server correctly, but nothing is outputted from tcpdump. Any ideas? Thanks, Liron From dtv at berkeley.edu Thu Sep 28 21:02:08 2006 From: dtv at berkeley.edu (dtv at berkeley.edu) Date: Thu, 28 Sep 2006 21:02:08 -0700 (PDT) Subject: [EE122] Proj1 tcpdump problems In-Reply-To: <000f01c6e37b$25cc0cd0$4101a8c0@Liron> References: <000f01c6e37b$25cc0cd0$4101a8c0@Liron> Message-ID: <1692.71.146.5.104.1159502528.squirrel@calmail.berkeley.edu> I believe you have to run the client and the server on different machines. I did mines between c199.eecs and cory.eecs and it worked. Hope that helps. David > I'm unable to get any output from tcpdump from my echo_client or > echo_server. I'm doing the following on quasar.cs.berkeley.edu: >> tcpdump tcp port 7782 > >>From another terminal window: >> echo_server 7782 > >>From a 3rd terminal window: >> echo_client quasar.cs.berkeley.edu 7782 > > The data is echoed back from the client to the server correctly, but > nothing > is outputted from tcpdump. > > Any ideas? > > Thanks, > Liron > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > From vern at icir.org Thu Sep 28 21:11:18 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 28 Sep 2006 21:11:18 -0700 Subject: [EE122] Proj1 tcpdump problems In-Reply-To: <1692.71.146.5.104.1159502528.squirrel@calmail.berkeley.edu> (Thu, 28 Sep 2006 21:02:08 PDT). Message-ID: <200609290411.k8T4BI34009232@jaguar.icir.org> > I believe you have to run the client and the server on different machines. That is indeed the case. Network communication that stays within a host doesn't actually reach the network interface (which is what tcpdump hooks into). Depending on the operating system, you may be able to see it using "tcpdump -i lo0 ...", which directs tcpdump to monitor the "loopback" pseudo-interface used for internal communication. However, the particulars of how this interface works varies from one operating system to another. Vern From dilip.antony.joseph at gmail.com Thu Sep 28 21:13:33 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 28 Sep 2006 21:13:33 -0700 Subject: [EE122] Proj1 tcpdump problems In-Reply-To: <1692.71.146.5.104.1159502528.squirrel@calmail.berkeley.edu> References: <000f01c6e37b$25cc0cd0$4101a8c0@Liron> <1692.71.146.5.104.1159502528.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0609282113w6f6169b1vefd545fb8e081db8@mail.gmail.com> Yes, as David mentioned, if the client and server are running on the same machine, tcpdump does not see the packets. Dilip On 9/28/06, dtv at berkeley.edu wrote: > I believe you have to run the client and the server on different machines. > I did mines between c199.eecs and cory.eecs and it worked. Hope that > helps. > > David > > > I'm unable to get any output from tcpdump from my echo_client or > > echo_server. I'm doing the following on quasar.cs.berkeley.edu: > >> tcpdump tcp port 7782 > > > >>From another terminal window: > >> echo_server 7782 > > > >>From a 3rd terminal window: > >> echo_client quasar.cs.berkeley.edu 7782 > > > > The data is echoed back from the client to the server correctly, but > > nothing > > is outputted from tcpdump. > > > > Any ideas? > > > > Thanks, > > Liron > > > > _______________________________________________ > > EE122 mailing list > > EE122 at mailman.icsi.berkeley.edu > > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > > > > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From kronrod at berkeley.edu Thu Sep 28 22:08:16 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Thu, 28 Sep 2006 22:08:16 -0700 (PDT) Subject: [EE122] broken pipe Message-ID: <4294.68.122.70.34.1159506496.squirrel@calmail.berkeley.edu> I opened an echo-server and an echo-client and then fed a lot of messages into the client from a file. The server crashes and says "broken pipe" at the end. I was wondering what "broken pipe" is. I am assuming the client sends all the messages and quits before the server has the chance to echo everything back and broken pipe comes from attempting to use sockets when they are closed. I am not sure why this would happen, since I do error check each time I try to send/recieve stuff. any ideas? Thanks, Alex. From vern at icir.org Thu Sep 28 22:29:03 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 28 Sep 2006 22:29:03 -0700 Subject: [EE122] broken pipe In-Reply-To: <4294.68.122.70.34.1159506496.squirrel@calmail.berkeley.edu> (Thu, 28 Sep 2006 22:08:16 PDT). Message-ID: <200609290529.k8T5T3xG010675@jaguar.icir.org> > The server crashes and says "broken pipe" at > the end. I was wondering what "broken pipe" is. I am assuming the client > sends all the messages and quits before the server has the chance to echo > everything back and broken pipe comes from attempting to use sockets when > they are closed. Yes, that's what it means in this case - the server did a write() to a socket that has already been closed by the client at the other end. > I am not sure why this would happen, since I do error > check each time I try to send/recieve stuff. How does your client decide that it is done? You shouldn't run into this problem if the client writes a single line at a time and waits to read back the echo from the server before proceeding to the next line. Vern From dilip.antony.joseph at gmail.com Fri Sep 29 08:43:49 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 29 Sep 2006 08:43:49 -0700 Subject: [EE122] project 1 submissions Message-ID: <4cd0c11b0609290843m494b408dv5b06c6b44e381c02@mail.gmail.com> Hello, I hope all you have submitted project 1. The submit program would have allowed you to make multiple submissions. By default I will be grading the last submitted version. If the last submitted version was made after 11:10 pm yesterday night, late penalties will occur. If you had submitted a fully functional version before 11:10 pm and prefer to have that graded, please email me your login name ee122-??. Regards, Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From dilip.antony.joseph at gmail.com Fri Sep 29 18:17:45 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 29 Sep 2006 18:17:45 -0700 Subject: [EE122] project 1 grading begins Message-ID: <4cd0c11b0609291817l70f0ac83l55f8a5c12b98ef1f@mail.gmail.com> Hi, I will start grading project 1 shortly. If you submitted your program after 11:10 pm yesterday or submit it in the future, be sure to email me. Otherwise, I might miss the latest submission and grade an earlier version of your submission. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From dilip.antony.joseph at gmail.com Mon Oct 2 23:13:23 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 2 Oct 2006 23:13:23 -0700 Subject: [EE122] Project 1 grade report emails sent Message-ID: <4cd0c11b0610022313y5e81ba9bw42a469ea9763630f@mail.gmail.com> Hello, I just sent out individual project 1 grade reports to the email address supplied while you registered with the EECS instructional accounts. Please email me if you didn't get your report or have any questions/clarifications about it. Please use glookup (while logged into your instructional account) and check your total score for project 1. Make sure that it matches the total in your grade report. A reference implementation of the echo server and client are up on the project 1 web page. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From vern at icir.org Tue Oct 3 00:24:14 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 03 Oct 2006 00:24:14 -0700 Subject: [EE122] HTTP statelessness & Web authentication Message-ID: <200610030724.k937OEnG032497@jaguar.icir.org> Steve Jiang sent along the following question (forwarded with permission): > In today's lecture you've mentioned that the server is stateless, that it > does not remember client's requests, and handles each request independently. > A question that pops in my mind is that: > > How does the server handles authentications through protocols like HTTP? > Say, in an online forum where clients are required to login using their > username and password. On one request, I can imagine the the client sends > the username and password for authentication, but what if this client needs > to go to other password protected page? Are the same user/pass info being > sent to the server per request? Or, is there someway for the server to > remember this client? Others wondered about this along similar lines. The general answer is "cookies". For example, when I authenticate to the mailing list manager for this mailing list, it replies with a Set-Cookie: header that sets an "ee122+admin" cookie that looks like: ee122+admin=28020000006951[80 more digits deleted]36530646630373466 As long as my browser stores that cookie, it sends the cookie along in any subsequent requests. The server extracts from it information about my access rights (presumably it's encrypted; hard to tell from the above). These rights will usually include the user identity that my commands run as plus additional context; but usually won't include my password (which isn't needed on each request, but just when I authenticate in order for the server to confirm that it should send me the cookie in the first place). A second answer would be "the server can use state if it wants to". For example, it might return a cookie that is simply an index into a data structure it's keeping (though hopefully it would at least make these hard to guess/forge); or not return a cookie at all, but instead store state associated with my IP address and perhaps User-Agent. However, in either case it now needs to decide when to time the state out, since HTTP doesn't include any signal that a user has finished their Web session. Finally, there's the question about how can you figure stuff like this out. To get the mailing-list manager's cookie, I ran tcpdump on my laptop (it has to run on the same machine as your browser in order to see its traffic) and captured "port 80" traffic using -s 0. I then accessed the mailing list using my browser once without having authenticated and then again once I had. At this point I killed tcpdump and poked through the trace using "ipsumdump -r trace -s --payload" to see each packet payload sent by both my browser and by the remote server. (Alternatively, I could have used tcpdump; or even "strings trace", which usually works, though you get some gobbleydegook in the process.) Not that this always works. I first tried with nytimes.com, but it sends back an incredibly baroque set of cookies, from which I couldn't readily figure out just what's going on. Vern From dilip.antony.joseph at gmail.com Tue Oct 3 10:38:32 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 3 Oct 2006 10:38:32 -0700 Subject: [EE122] project 2: specs and grading policy updated Message-ID: <4cd0c11b0610031038x2217f81dw6724a1d8dff9bf2c@mail.gmail.com> Hello, The project 2 specifications have been updated. We have added a simple new required feature: Fetched pages should be written to disk. This will feature will be very useful when you are debugging your programs. We have also updated the grading rubric to reflect the new feature. The points allotted to Extra Credit have been reduced from 30 to 15. Details are on the Project 2 home page. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip From andyvster at gmail.com Tue Oct 3 13:43:25 2006 From: andyvster at gmail.com (Andy V) Date: Tue, 3 Oct 2006 13:43:25 -0700 Subject: [EE122] Question on HW2, question 4c References: <4cd0c11b0610031038x2217f81dw6724a1d8dff9bf2c@mail.gmail.com> Message-ID: <005f01c6e72c$96cd44d0$28aa9888@TOSHIBAKEN> For question 4 in general, can we assume that all the packets within the sliding window arrive to the reciever at the same time, thus letting the reciever send out all the ack knowledgement packets at the same time? ----- Original Message ----- From: "Dilip Joseph" To: Sent: Tuesday, October 03, 2006 10:38 AM Subject: [EE122] project 2: specs and grading policy updated > Hello, > > The project 2 specifications have been updated. We have added a simple > new required feature: Fetched pages should be written to disk. This > will feature will be very useful when you are debugging your programs. > > We have also updated the grading rubric to reflect the new feature. > The points allotted to Extra Credit have been reduced from 30 to 15. > > Details are on the Project 2 home page. > > Regards > > Dilip > > -- > _________________________________________ > Dilip Antony Joseph > Graduate Student > Computer Science Division, > University of California, Berkeley > http://www.cs.berkeley.edu/~dilip > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 From binetude at eecs.berkeley.edu Tue Oct 3 14:59:21 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Tue, 03 Oct 2006 14:59:21 -0700 Subject: [EE122] Question on HW2, question 4c In-Reply-To: <005f01c6e72c$96cd44d0$28aa9888@TOSHIBAKEN> References: <4cd0c11b0610031038x2217f81dw6724a1d8dff9bf2c@mail.gmail.com> <005f01c6e72c$96cd44d0$28aa9888@TOSHIBAKEN> Message-ID: It can't be assumed that packets will arrive at the same time. Instead, they will arrive one by one. Thank you. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude ----- Original Message ----- From: Andy V Date: Tuesday, October 3, 2006 1:43 pm Subject: [EE122] Question on HW2, question 4c > For question 4 in general, can we assume that all the packets > within the > sliding window arrive to the reciever at the same time, thus > letting the > reciever send out all the ack knowledgement packets at the same time? > > > ----- Original Message ----- > From: "Dilip Joseph" > To: > Sent: Tuesday, October 03, 2006 10:38 AM > Subject: [EE122] project 2: specs and grading policy updated > > > > Hello, > > > > The project 2 specifications have been updated. We have added a > simple> new required feature: Fetched pages should be written to > disk. This > > will feature will be very useful when you are debugging your > programs.> > > We have also updated the grading rubric to reflect the new feature. > > The points allotted to Extra Credit have been reduced from 30 to 15. > > > > Details are on the Project 2 home page. > > > > Regards > > > > Dilip > > > > -- > > _________________________________________ > > Dilip Antony Joseph > > Graduate Student > > Computer Science Division, > > University of California, Berkeley > > http://www.cs.berkeley.edu/~dilip > > > > _______________________________________________ > > EE122 mailing list > > EE122 at mailman.icsi.berkeley.edu > > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > From dilip.antony.joseph at gmail.com Sat Oct 7 15:24:57 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 7 Oct 2006 15:24:57 -0700 Subject: [EE122] Project 2: Test cases and grading script v0.1 available Message-ID: <4cd0c11b0610071524o273ac27ak967b9de726b709df@mail.gmail.com> Hello, Unlike project 1, project 2 will be graded using an automated script. You can use the same script to evaluate your submissions. I have uploaded version 0.1 of the grading script and some sample test cases to the project website. v0.1 of the script is limited to * checking if comand line arguments are correctly specified. * checking if the keyword was found or not. We will be enhancing the script to check for other features and will post it once ready. We will also be adding more sample test cases. The ones which are currently on the project page are sufficient for checking if your submission satisfies the checkpoint requirements. If you have any problems using the scripts or find any bugs, please email me. Project 2 will involve a lot more code than project 1. So, it will be a good idea to start early. Good luck, Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061007/e9fc3d1a/attachment.html From binetude at eecs.berkeley.edu Sun Oct 8 15:21:53 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Sun, 08 Oct 2006 15:21:53 -0700 Subject: [EE122] Clarifications on Homework #2 Message-ID: Hi. There are clarifications on Homework #2. (1) P&D 3.1 Links are assumed to be bidirectional. If A->B first uses VCI 0, then later B->A will be assigned VCI 1. It is assumed that even if switch 1 has assigned VCI 0 to port 1, it can assign VCI 0 again to port 2. (2) P&D 4.4 Textbook states ?Every network type has a maximum transmission unit (MTU), which is the largest IP datagram that it can carry in a frame?. (3) Question #2 ?IP includes two options for including a ?source route?? ? here two options are intended to mean two different types of source routing: strict and loose. (4) Question #3 ?4 blocks of 256 addresses? are intended to mean 1024 addresses (147.17.204.0 ~ 147.17.207.255). In (a), ?class-A/B/C? is intended to mean normal routing, in contrast to CIDR. In (c), only CIDR is used, and subnetting is not used. (5) Question #4 Latency of 5ms is not correctly stated. Latency here excludes transmit time of the sender, and is fixed regardless of the packet size. To put it simple, you can assume that there is a single link from Berkeley to San Francisco with a propagation delay of 5ms. Thank you for all comments. Any questions or comments regarding homework are really appreciated. From dilip.antony.joseph at gmail.com Mon Oct 9 23:57:40 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 9 Oct 2006 23:57:40 -0700 Subject: [EE122] project 1 grades: extra credits separated out Message-ID: <4cd0c11b0610092357t6dec7df7mf0b45b691e3b4219@mail.gmail.com> Hi, I have re-entered the points for project 1 : extra credit is now separately indicated as proj1extra. Please use the glookup script from your EECS inst account and verify that your total points are consistent with what was there previously. If you got points changed recently, make sure you do the verification. If you find that I messed up something, please email me. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061009/fc959fdd/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 11 14:05:37 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 11 Oct 2006 14:05:37 -0700 Subject: [EE122] project 2 clarification: No external libraries Message-ID: <4cd0c11b0610111405l76f3cbbwf3f77d27ecf5c383@mail.gmail.com> Hi, Some students asked use of external libraries was permitted for project 2. You are NOT allowed to use external libraries for fetching web pages. The goal of the project is to understand the HTTP protocol and hence, you must implement it yourself. You don't need to do complete HTML parsing (please see the project specs). Hence the standard C/C++ string manipulation functions are sufficient and no external HTML parsing libraries may be used. If you are using an external library for some other purpose, please email me and make sure that it is acceptable for this project. If you have any questions about the specs or other aspects of the project, please email me. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061011/f4fc107d/attachment.html From vern at icir.org Thu Oct 12 23:43:18 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 12 Oct 2006 23:43:18 -0700 Subject: [EE122] acronyms relating to networking Message-ID: <200610130643.k9D6hINi000110@jaguar.icir.org> During Monday's review, the topic came up of all the acronyms used in networking. Unfortunately, there are a lot, many of which you need to know. Here's a list. If you're wondering about others to add, or about the meaning/expansion of some of these, let us know. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If no pronunciation is given, then it is each letter individually, e.g., TCP = "tee-sea-pea". Acronyms we've already covered ------------------------------ ACK pronounced as spelled ARP pronounced as spelled ARQ CDN CIDR pronounced "cider" CNAME pronounced "See-name" CRC CSMA CSMA/CD DF This is the only IPv4 header bit that people commonly talked about. DNS FDM not in fact widely used FDMA same, not in fact widely used FTP Gbps pronounced "gigabit-per-second" or just "gigabit" HTTP IEEE pronounced "eye-triple-ee" IETF IMAP pronounced "eye-map"; sometimes is "IMAP4" for version 4 of the protocol IP IPv4 IPv6 ISP LAN pronounced as spelled; local area network MAC pronounced as spelled; often combined to "MAC address" MIME pronounced as spelled MTU MX Mbps pronounced "megabit-per-second" or just "megabit" NAK pronounced as spelled NIC pronounced as spelled NRZ not in fact widely used NRZI not in fact widely used POP pronounced as spelled; sometimes as "POP3" for version 3 of the protocol PTR pronounced either "P-T-R" or "Pointer" RFC RIR RR RTT SACK pronounced as spelled SMTP SONET pronounced "sonnet" TCP TDM TDMA TLD TOS pronounced "toss" TTL UDP URI URL WAN pronounced as spelled; wide-area network, i.e., a network that spans a large geographic region WWW pronounced "dub-dub-dub" or sometimes "triple-dub" Acronyms we've not yet covered ------------------------------ AIMD BGP CWND pronounced "sea-wind" DDoS pronounced "dee-dos" DHCP DoS pronounced as spelled ECN FIN pronounced as spelled ICMP MSS NAT pronounced as spelled OSPF P2P pronounced "pea-two-pea" PMTU QoS pronounced either "Q-O-S" or "kwas" RED pronounced as spelled RST pronounced "reset" SSTHRESH pronounced "ess-ess-thresh" SYN pronounced "sin" VOIP pronounced "voyp" Acronyms we probably won't cover, but you still should know ----------------------------------------------------------- 10BaseT pronounced "ten-base-tee"; the Twisted Pair version ('T') of 10 Mbps Ethernet; also 100BaseT, 1000BaseT 10G pronounced "ten-gee" or "ten-gig"; Ethernet that runs at 10 Gbps 802.3 pronounced "eight-oh-two-dot-three"; the IEEE standardization of Ethernet 802.11 pronounced "eight-oh-two-dot-eleven"; the IEEE family of wireless protocol standards such as "Wavelan" ADDL pronounced as spelled; the DNS "additional" RRs ATM "ay-tee-em"; Asynchronous Transfer Mode; a complex, high-speed link layer AUTH pronounced as spelled; the DNS "authority" RRs FastEther "fast-ether"; refers to 100 Mbps Ethernet GigEther "gig-ether"; 1 Gbps Ethernet MAN pronounced as spelled; metropolitan-area network NANOG pronounced "nan-nog"; North American Network Operators Group PHY pronounced "fie"; refers to the physical layer From binetude at eecs.berkeley.edu Fri Oct 13 10:46:30 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Fri, 13 Oct 2006 10:46:30 -0700 Subject: [EE122] Grading of Homework #2 will be started Message-ID: Grading of Homework #2 will be started. In case of multiple submissions, the latest version will be graded. So in case you want an earlier version graded, please send me an email. Thank you. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From dilip.antony.joseph at gmail.com Sat Oct 14 21:34:14 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 14 Oct 2006 21:34:14 -0700 Subject: [EE122] project 2 checkpoint clarifications Message-ID: <4cd0c11b0610142134i49c7d031paaf91f14c3825afc@mail.gmail.com> Hi, Some of you had some questions about what needs to be implemented for the project 2 checkpoint. You do NOT have to implement robots.txt support for the checkpoint. You do NOT have to handle links for the checkpoint - the test cases used to evaluate the checkpoint will not have any links. Project 2 checkpoint submission instructions are now available on the project 2 webpage. Please email me if you have any questions about project 2. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061014/4b485515/attachment.html From vern at icir.org Sun Oct 15 00:50:52 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 15 Oct 2006 00:50:52 -0700 Subject: [EE122] solutions for Homework #2 are now out Message-ID: <200610150750.k9F7oqsl032462@jaguar.icir.org> Available at http://inst.eecs.berkeley.edu/%7Eee122/fa06/hw/hw2-soln.pdf - Vern From dilip.antony.joseph at gmail.com Sun Oct 15 07:04:22 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 15 Oct 2006 07:04:22 -0700 Subject: [EE122] more clarifications about project 2 Message-ID: <4cd0c11b0610150704s274567dcv66ee82a6401b50bc@mail.gmail.com> Hi, The last email generated more questions about project 2. Some more clarifications have been added to the web page (reproduced here for your convenience): 1. What should I do with the HTTP headers in the reply from the server? Should I save them? Should I search for the keyword in them? *Answer:*You should not save the headers as part of the output file. Only the body should be saved. You should search for the keyword only inside the body. 2. If the keyword is not found, should I output NOT_FOUND_KEYWORD: or NOT_FOUND_KEYWORD: TheKeywordIAmLookingFor? *Answer:* As described in the specs, you should output only NOT_FOUND_KEYWORD:. There IS a colon at the end. 3. What exactly is a "line"? *Answer:* Lines are groups of characters terminated by \n or \r\n. This corresponds to our familiar notion of a line. When we hit enter when typing text, a \n or \r\n gets inserted (depending on your editor and OS). You should parse the reply from the server line by line. Note that the data returned in a single recv() call can contain multiple lines, or a single line may be split across multiple recv() calls. It is your responsibility to appropriately parse line by line 4. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061015/114e8644/attachment.html From greatkei at berkeley.edu Mon Oct 16 19:36:19 2006 From: greatkei at berkeley.edu (greatkei at berkeley.edu) Date: Mon, 16 Oct 2006 19:36:19 -0700 (PDT) Subject: [EE122] proj2 checkpoint req. Message-ID: <37454.128.32.42.140.1161052579.squirrel@calmail.berkeley.edu> Hi: For the checkpoint, does the program need to store the page when the output directory is supplied? Also, do we need to check the input validity for the checkpoint? Thanks, Steve From dilip.antony.joseph at gmail.com Mon Oct 16 19:41:51 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 16 Oct 2006 19:41:51 -0700 Subject: [EE122] proj2 checkpoint req. In-Reply-To: <37454.128.32.42.140.1161052579.squirrel@calmail.berkeley.edu> References: <37454.128.32.42.140.1161052579.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0610161941i7bc8a210o5beb3019e4da0b1a@mail.gmail.com> On 10/16/06, greatkei at berkeley.edu wrote: > > Hi: > For the checkpoint, does the program need to store the page when the > output directory is supplied? No. Also, do we need to check the input validity for the checkpoint? Yes Dilip Thanks, > > Steve > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061016/cabc7f8a/attachment.html From mjohnston at berkeley.edu Tue Oct 17 13:33:53 2006 From: mjohnston at berkeley.edu (Matt Johnston) Date: Tue, 17 Oct 2006 13:33:53 -0700 Subject: [EE122] Proj 2 checkpoint again Message-ID: <00a701c6f22b$90ade9b0$6402a8c0@Alfred> How about tcpdump files? Do we need to submit some of these for the checkpoint? Thanks Matt Johnston -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061017/62c91810/attachment.html From dilip.antony.joseph at gmail.com Tue Oct 17 13:35:32 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 17 Oct 2006 13:35:32 -0700 Subject: [EE122] Proj 2 checkpoint again In-Reply-To: <00a701c6f22b$90ade9b0$6402a8c0@Alfred> References: <00a701c6f22b$90ade9b0$6402a8c0@Alfred> Message-ID: <4cd0c11b0610171335s13d41af8x1a0f68f085c327d3@mail.gmail.com> You do not need to submit any tcpdump files for the checkpoint. Dilip On 10/17/06, Matt Johnston wrote: > > How about tcpdump files? Do we need to submit some of these for the > checkpoint? Thanks > > Matt Johnston > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > > > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061017/c3e5c6d7/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 18 13:37:46 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 18 Oct 2006 13:37:46 -0700 Subject: [EE122] clarification about project 2 output files Message-ID: <4cd0c11b0610181337p5f479fcag761b5cdea18645ab@mail.gmail.com> Hi, There was a question about the output files to be written by KeywordHunter in today's section. To clarify: You should write all successfuly fetched pages to the output directory. If a page could not be successfully fetched (for e.g., page not found) , you shouldn't write it to disk. For the successfully fetched pages, write only the body to the file. The idea is that you can look at this file in a webbrowser, if you wish to. If you do not visit a link while searching for the keyword, you do not have to write it to disk ( I guess this is obvious). For the pages you are writing to disk, make sure you write the whole page to disk. For example, if you find the keyword halfway in a page, don't exit the program immediately - but go ahead and finish writing the entire page to the output file. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061018/bdea6587/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 18 17:56:30 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 18 Oct 2006 17:56:30 -0700 Subject: [EE122] project 2: Permission Denied while running test case Message-ID: <4cd0c11b0610181756x798cd9fdrc6ded76429eef41f@mail.gmail.com> If you get the error "Permission Denied" while trying to run evaluate.pl on the test cases, please try executing the following command and then retry the evaluation script. chmod +x evaluate.pl Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061018/dbb7dd37/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 18 18:10:08 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 18 Oct 2006 18:10:08 -0700 Subject: [EE122] project 2: using regex.h Message-ID: <4cd0c11b0610181810h5d2ccdbdmcd8074ee2c9cf154@mail.gmail.com> Hi, A few students asked if it is okay to use regex.h for regular expression parsing. You may use regex if you want. Just a reminder: You don't have to do complex parsing. Regular string functions may be simpler to use. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061018/186ba797/attachment.html From vern at icir.org Fri Oct 20 00:50:23 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 20 Oct 2006 00:50:23 -0700 Subject: [EE122] midterm scores & solutions now available Message-ID: <200610200750.k9K7oNUX056018@jaguar.icir.org> Scores for the midterm have been entered into the grading system, and solutions are now available from: http://inst.eecs.berkeley.edu/%7Eee122/fa06/notes/midterm-soln.pdf - Vern From tonyw85 at berkeley.edu Sat Oct 21 21:27:37 2006 From: tonyw85 at berkeley.edu (tonyw85 at berkeley.edu) Date: Sat, 21 Oct 2006 21:27:37 -0700 (PDT) Subject: [EE122] clarification about project 2 output files In-Reply-To: <4cd0c11b0610181337p5f479fcag761b5cdea18645ab@mail.gmail.com> References: <4cd0c11b0610181337p5f479fcag761b5cdea18645ab@mail.gmail.com> Message-ID: <60132.69.109.219.156.1161491257.squirrel@calmail.berkeley.edu> The project specs say that KeywordHunter should output a LINK: line for each link that it finds. How should we handle links found on the same page as the keyword? By the specs, we should print them, but what actioncode should we use? They were not followed, since the search terminates when the keyword is found. Also, should we print all links on the page with the keyword? Or only the ones before the keyword? -Tony From dilip.antony.joseph at gmail.com Sat Oct 21 22:30:55 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 21 Oct 2006 22:30:55 -0700 Subject: [EE122] clarification about project 2 output files In-Reply-To: <60132.69.109.219.156.1161491257.squirrel@calmail.berkeley.edu> References: <4cd0c11b0610181337p5f479fcag761b5cdea18645ab@mail.gmail.com> <60132.69.109.219.156.1161491257.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0610212230x33bad71bh190ba7e13086b47b@mail.gmail.com> You can structure your program in different ways. If you look for the keyword in the page before looking for links, on the page containing the keyword, you won't even 'see' the links. If your program is so structured, you don't have to even print the LINK line for those links. However, if you process links as the page is incrementally read in, you should the print the LINK line and the PAGE line (if applicable). When I test your programs for link traversal, the search keyword won't be found in any page. This means that I can easily check whether you are following all the applicable links, irrespective of how you choose to structure your program. Dilip On 10/21/06, tonyw85 at berkeley.edu wrote: > > The project specs say that KeywordHunter should output a LINK: line for > each link that it finds. How should we handle links found on the same page > as the keyword? By the specs, we should print them, but what actioncode > should we use? They were not followed, since the search terminates when > the keyword is found. Also, should we print all links on the page with the > keyword? Or only the ones before the keyword? > > -Tony > > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061021/969d10fc/attachment.html From andyvster at gmail.com Sun Oct 22 11:02:08 2006 From: andyvster at gmail.com (Andy V) Date: Sun, 22 Oct 2006 11:02:08 -0700 Subject: [EE122] More test cases? References: <4cd0c11b0610181337p5f479fcag761b5cdea18645ab@mail.gmail.com> <60132.69.109.219.156.1161491257.squirrel@calmail.berkeley.edu> Message-ID: <002e01c6f604$3421a4c0$6501a8c0@TOSHIBAKEN> Since the project deadline is coming up, are there going to be more test cases up? Andy Vu From dilip.antony.joseph at gmail.com Sun Oct 22 19:00:42 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 22 Oct 2006 19:00:42 -0700 Subject: [EE122] project 2 checkpoint grades + clarifications Message-ID: <4cd0c11b0610221900l23c988a1i7387b0d8c90e3222@mail.gmail.com> Hello, The grade reports for project 2 checkpoint were sent out a few hours ago. Some of the emails bounced (quota exceeded). If you haven't got your grade report, please make space in your email account or send me an alternate address. The grades have also been entered into the glookup system under the heading proj2checkpoint. The grade report was generated automatically. For those of you who lost points, I did manually verify if the automated evaluation was correct. If you have any concerns about your grading, please email me. Please quote your instructional login name as well as attach your grade report with your email. The test cases and modified script used for evaluating the checkpoint submissions are attached. You can try it out yourself. There was confusion about some aspects of the specifications. Please read the rest of the email for important clarifications. 1. Should I print a LINK: line for the start URL? Ans: No. The starting URL is not a link you encounter while parsing the page. This time, you were not penalized for printing it. 2. Should I print a PAGE: line for the page corresponding to the start URL? Ans: Yes. You should print a PAGE: line for every page you fetch. Since this was not clear in the specs, I did not cut points for including or not including the PAGE: line. For the final submission, you will lose points if you do not print out the PAGE: line for the start URL. 3. You must return the appropriate exit codes if the keyword is found or not found - not just for invalid command line arguments. Some submissions did not satisfy this requirement. Please refer your grade report for details. No points were cut this time. But points will be cut if the error persists in the final submission. 4. Please ensure that your makefile works on solaris (c199). There were many submissions without makefiles or faulty make files. If you don't fix the problem, you will lose points in the final submission. Also, please ensure that simply running the command 'make' will generate the KeywordHunter executable in the top level directory of your submission. If the executable is generated inside a 'bin' or some other directory, my automated script will not be able to find it. Also, if your make process is dependent on the presence of certain subdirectories, please make sure that you submit those too. 5. Some of your programs took a long time to exit. I suspect that you are not sending the "Connection: Close" header as part of the GET request. No points were cut this time. You may lose a few points in the final submisison, if the problem persists. 6. Some of you presented the output in exactly the same form as the sample test case answers. It is great to know that you looked at the test cases. However, it is not necessary to output all the lines present in the test case answer files (Ofcourse, no penalties if you do so). You just need to follow the output formats dictated by the specs. 7. The most common reason for losing points in the command line arguments test case was the program segfaulting. You may try out the test cases yourself and see what happens. If you have any further questions or clarifications, please email me. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061022/15626f0d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: chkpoint_eval.tar.gz Type: application/x-gzip Size: 4386 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061022/15626f0d/attachment.gz From vern at icir.org Mon Oct 23 01:13:02 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 23 Oct 2006 01:13:02 -0700 Subject: [EE122] questions/requests regarding grading of your midterm exam Message-ID: <200610230813.k9N8D2xf062236@jaguar.icir.org> In answer to a question that came up in Friday's section, if you want to discuss the grading of one of your answers on the midterm, please send me a note by Monday Oct. 30 detailing which problem(s) and the question you have and/or why you don't think it was properly graded. Vern From dilip.antony.joseph at gmail.com Mon Oct 23 19:06:17 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 23 Oct 2006 19:06:17 -0700 Subject: [EE122] Project 2: More test cases Message-ID: <4cd0c11b0610231906o5d21408br7f5408b71b12a13a@mail.gmail.com> Here are some more test cases for you to try out. You need to copy the CASE* files to the cases subdirectory. I am including only the new test cases. You can download the evaluation script and the original test cases from the project web page. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061023/0493923a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: more_cases.tar.gz Type: application/x-gzip Size: 1252 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061023/0493923a/attachment.gz From dilip.antony.joseph at gmail.com Tue Oct 24 14:09:22 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 24 Oct 2006 14:09:22 -0700 Subject: [EE122] project 2 clarification Message-ID: <4cd0c11b0610241409m1e6aa2f2l318e907ac2afaa66@mail.gmail.com> Hi, In today's discussion section, there was a question about what KeywordHunter should do if the search keyword occurs multiple times in the same page? You can just consider the first occurrence. When I evaluate your submissions, the keyword will be present atmost once. So this scenario will never occurr during evaluation. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061024/ee29d7ec/attachment.html From binetude at eecs.berkeley.edu Tue Oct 24 14:11:06 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Tue, 24 Oct 2006 14:11:06 -0700 Subject: [EE122] Homework #1 and Homework #2 Message-ID: 1. Extra credit of Homework #1 is separated as hw1extra from hw1. 2. Points of Homework #2 is entered (hw2 and hw2extra) 3. Points are partial points of Homework #2 can be found in http://inst.eecs.berkeley.edu/~ee122/fa06/hw/points2.pdf Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From ee122-bk at imail.eecs.berkeley.edu Tue Oct 24 16:59:15 2006 From: ee122-bk at imail.eecs.berkeley.edu (Evan Huang) Date: Tue, 24 Oct 2006 16:59:15 -0700 Subject: [EE122] Request for Project Message-ID: <453EA8D3.60100@imail.eecs.berkeley.edu> Hi Dilip, If you can could you please update the project web page with the new test cases and clarifications you presented in the newsgroup? It is true that you can reach all of us by the mailing list, but in my opinion the most convenient place for these things is in the project description page itself. Thank you very much. Evan Huang From dilip.antony.joseph at gmail.com Tue Oct 24 17:27:07 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 24 Oct 2006 17:27:07 -0700 Subject: [EE122] Request for Project In-Reply-To: <453EA8D3.60100@imail.eecs.berkeley.edu> References: <453EA8D3.60100@imail.eecs.berkeley.edu> Message-ID: <4cd0c11b0610241727l1fced749q75e9a8ae4ec5b33c@mail.gmail.com> Ok. I have uploaded the test cases to the project2 webpage. I will post any future clarifications to the webpage For previous clarification emails sent to the group, please check the mailing list archives at http://mailman.icsi.berkeley.edu/pipermail/ee122/2006/date.html There aren't many messages there. So it should be easy for you to find any clarification emails. Dilip On 10/24/06, Evan Huang wrote: > > Hi Dilip, > > If you can could you please update the project web page with the new > test cases and clarifications you presented in the newsgroup? It is true > that you can reach all of us by the mailing list, but in my opinion the > most convenient place for these things is in the project description > page itself. Thank you very much. > > Evan Huang > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061024/c5b8db54/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 25 15:42:27 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 25 Oct 2006 15:42:27 -0700 Subject: [EE122] latest evaluation script Message-ID: <4cd0c11b0610251542s44fa8e11gd9948ce93f22659a@mail.gmail.com> Hi, I just realized that some of you are not using the latest version of the evaluation script (The one I sent out with the email announcing the midterm grades). The initial version of the evaluation script does not check for valid link traversals, robots.txt and a whole bunch of other required features. You should use the latest version of the evaluation script. I have uploaded the latest version of the script and all the test cases to the project project webpage ( http://inst.eecs.berkeley.edu/%7Eee122/fa06/projects/project2/project2_testcases_0_3.tar.gz). Please use that for testing your project. If you find any problems with the scripts or test cases, please email me. Thanks, Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061025/c0968630/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 25 15:47:26 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 25 Oct 2006 15:47:26 -0700 Subject: [EE122] extra office hours tomorrow Message-ID: <4cd0c11b0610251547p4443bb4cs70bbd7b7fb16dbee@mail.gmail.com> Hi, I will be having extra office hours tomorrow from 4-5pm at 311 Soda (We might move to a lab on the second floor if necessary. There will be a note on 311 door if we do so). In my previous email, I made an error - I was referring to my email announcing the project 2 checkpoint grades and not the midterm grades ( http://mailman.icsi.berkeley.edu/pipermail/ee122/2006/000053.html) Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061025/1343fc28/attachment.html From dilip.antony.joseph at gmail.com Wed Oct 25 18:59:14 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 25 Oct 2006 18:59:14 -0700 Subject: [EE122] project2 : error in test cases Message-ID: <4cd0c11b0610251859ic4109afj119aff4e3ce6d793@mail.gmail.com> Hi, I am sorry that the sample test cases 2 and 3 had errors. They were using fetching pages to dept 6 and not 5 as required. Thanks to Abhishek Mishra and Tony for pointing this out. I have uploaded the updated test cases (version 0_4) to the website. Sorry for the inconvenience. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061025/414f90d4/attachment.html From vern at icir.org Thu Oct 26 07:51:29 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 26 Oct 2006 07:51:29 -0700 Subject: [EE122] changes to lecture schedule (affects reading for next Monday) Message-ID: <200610261451.k9QEpTCA080574@jaguar.icir.org> I've decided to shift the lecture schedule a bit. Next Monday we'll start on TCP rather than performance evaluation, so the reading for Monday is P&D 5.2 rather than P&D 1.5 (which is now for a week later). The reason for this is that I'm going to combine the performance evaluation material with further study of TCP. This leaves the lecture for Nov. 8 as TBD, though I anticipate it will be a continuation of TCP performance issues and evaluation. Vern From dilip.antony.joseph at gmail.com Thu Oct 26 14:44:42 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 26 Oct 2006 14:44:42 -0700 Subject: [EE122] office hours today and your emails Message-ID: <4cd0c11b0610261444h559f6657n5fa6e9011f62750@mail.gmail.com> Hi, Just wanted to remind you that I have extra office hours from 4pm to 5pm today. I will be in 311 Soda. But it is highly likely that I might move to one of the labs in 2nd floor Soda. Please check the labs if I am not in 311. I got around 100 emails in the 24 hours. I think I have replied to everything. If I forgot to answer any of your emails, please resend your query. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061026/fe62c8eb/attachment.html From dilip.antony.joseph at gmail.com Thu Oct 26 19:52:52 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 26 Oct 2006 19:52:52 -0700 Subject: [EE122] project2 : test website back up Message-ID: <4cd0c11b0610261952v7275ac0cp334d3c3c66f011b7@mail.gmail.com> The test website went down for 10-20 minutes some time back. Someone tripped over my network cable while doing some maintenance work in my new office. The website is back up now. Just another example of how unreliable the Internet can be - all you need to bring down a machine is to trip over a network cable! :-) Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061026/3c55b15c/attachment.html From dilip.antony.joseph at gmail.com Sat Oct 28 17:31:26 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 28 Oct 2006 17:31:26 -0700 Subject: [EE122] project 2 early grading Message-ID: <4cd0c11b0610281731t46a8e1cck7e37c882ddb95fbb@mail.gmail.com> Hi, If you have already submitted project 2 and don't plan to make any changes to your submission, please email me your insructional login id. I will evaluate your submission right away and you will get your evaluation report once the late submission period closes tomorrow night. I will grade other submissions sometime on Thursday or Friday. If you have implemented any extra credit features and forgot to mention it in the README, please do email me (Don't forget to mention your login-id in the email) Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061028/c3849afd/attachment.html From dilip.antony.joseph at gmail.com Sun Oct 29 23:18:29 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 29 Oct 2006 23:18:29 -0800 Subject: [EE122] project 2 grades Message-ID: <4cd0c11b0610292318k34e92e2ex7a27a1ba8090aee2@mail.gmail.com> Hi, I have emailed the project 2 grade reports for those who responded to my earlier email (around 25 of you) before today evening. I am sorry if I missed any of you. Everyone else will get their grade reports by tomorrow(Monday) morning. Please note that the points in the grade report do NOT include the checkpoint scores - they have been separately entered into the grade database. Note about expected output: I have manually edited the expected output to include only certain lines which are important to the feature being tested by a particular test case. For example, if a testcase is testing for the robots_ignore feature, you will find that I have pruned away a few of the PAGE: and LINK: lines that are not relevant for this feature. Ofcourse, you are not penalized for (correctly) including the PAGE: and LINK lines that are not shown as part of the expected output. The different tests in various cases are weighted to stress the importance of certain features. For example, in the test case associated with saving the file to disk, the PAGE, KEYWORD_NOT_FOUND etc lines have 0 weight - you get points for that test case only if the file is saved correctly. The weights associated with the different test cases will be inside the .txt file corresponding to the case. I manually inspected the test cases where you lost points in order to make sure that my automated script behaved correctly. However, I may have made errors - either in my script or in manual inspection. If you find any errors or if you cannot figure out why you lost points for a particular test case, please meet me during office hours. I will put up the test cases and the latest version of the evaluate.plscript tomorrow. Due to a technical difficulty, I cannot put them up right now. Sorry about that. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061029/4ef63828/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 04:02:35 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 04:02:35 -0800 Subject: [EE122] all project 2 submissions graded Message-ID: <4cd0c11b0610300402q558d0852y35448ced6f5cb639@mail.gmail.com> Hi, I have mailed the grade reports for all project 2 submissions. If you have any questions about the grading or you think you deserve more points on any particular cases, please meet me during office hours. Meeting directly is a much better option than doing this over email. If you have any problems with project 2, please get it corrected before Nov 10, Friday. I haven't yet entered the grades in the grade database. Will do that in a few days. Average score for project 2 (including extra credit) = 68.4. Average score for project 2 (no extra credit) = 65.94. Extra credit will not be considered when drawing the final grading curve. Some more comments about project 2: 1. KeywordHunter is a big program. Still atleast 50% of the submissions put all the code in a single file. It is often more convenient to split your code into multiple files. Your code becomes more manageable, more understandable and easier to debug. 2. If "Your Output" is blank for a case in your grade report, it means that your program segfaulted. 3. If you are emailing me regarding project 2, please include your instructional login id and grade report with the email. Thanks, Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/327df2ec/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 11:03:39 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 11:03:39 -0800 Subject: [EE122] Change in office hours location Message-ID: <4cd0c11b0610301103m24816e1dh8233c3d67bd5f129@mail.gmail.com> Hi, I no longer sit in 311 Soda. >From this week, my office hours will be held in 751 Soda Hall (alcove). TIme remains the same : Friday 11-12. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/cdc6f961/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 20:20:06 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 20:20:06 -0800 Subject: [EE122] project 2 evaluation scripts and test cases Message-ID: <4cd0c11b0610302020x2e3f26d1r91b0d65216d027d7@mail.gmail.com> Hello, The script and the test cases used for evaluating project 2 are now up on the project 2 webpage. If you lost points, please run the scripts yourself and see what happened. If you find any grading discrepancies, please meet me during office hours on Friday 11:10-12:10pm at 751 Soda alcove. Doing it over email takes more time - so it will be better if you could come and meet me. If Friday 11:10-12:10 is not convenient for you , please email me. Note: the evaluate.pl script now takes 4 command line arguments. Please run without any command line arguments see the usage information. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/1ca7e1b5/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 20:59:47 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 20:59:47 -0800 Subject: [EE122] project 2 : grades entered in the database Message-ID: <4cd0c11b0610302059ta43aaccrbf0ecede3f00e182@mail.gmail.com> Hi, I have entered the project 2 grades in the database. Please do check your grade using glookup and make sure that your grade report and the database scores are the same. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/55ec168a/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 21:38:19 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 21:38:19 -0800 Subject: [EE122] distance vector discussion section notes Message-ID: <4cd0c11b0610302138y23e11704g683e0ff75bc7a5d1@mail.gmail.com> Hi, I have uploaded the notes I used for last week's distance vector routing discussion to my section home page http://www.cs.berkeley.edu/~dilip/ee122_fa06/discussion.shtml. I am sorry I don't have time to type it out- so I just scanned my handwritten notes. Hopefully, you will be able to read my handwriting. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/82b706dc/attachment.html From dilip.antony.joseph at gmail.com Mon Oct 30 22:05:51 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 30 Oct 2006 22:05:51 -0800 Subject: [EE122] office hours tomorrow Message-ID: <4cd0c11b0610302205k5a28c1cex7cb75f56c4d538a7@mail.gmail.com> Hi, I will be handling Sukun's office hours tomorrow. I have a meeting at 11:30. So, I am sorry I won't be around past 11:45. I will be in 410 Soda (Sukun's regular OH venue). If I am unable to get into his office, I might be in the alcove nearby. If you have questions about project 2 grading, you are welcome to meet me tomorrow. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061030/f957ed54/attachment.html From dilip.antony.joseph at gmail.com Wed Nov 1 18:16:02 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 1 Nov 2006 18:16:02 -0800 Subject: [EE122] project 3 specifications out Message-ID: <4cd0c11b0611011816v28828dccra1cd9fb9409b9309@mail.gmail.com> Hello, Project 3 phase 1 specifications are now available on the course website. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061101/8ab21ff5/attachment.html From andyvster at gmail.com Fri Nov 3 11:50:18 2006 From: andyvster at gmail.com (Andy V) Date: Fri, 3 Nov 2006 11:50:18 -0800 Subject: [EE122] Proj 3 partner References: <4cd0c11b0610301103m24816e1dh8233c3d67bd5f129@mail.gmail.com> Message-ID: <002201c6ff81$4dd952b0$2ba89888@TOSHIBAKEN> Hey Everyone, I was wondering if anyone needed a project partner for proj3, because I need one. I'm pretty easy going and my schedule is flexable, so someone let me know if you need someone to work with. Thanks! Andrew Vu ----- Original Message ----- From: Dilip Joseph To: ee122 at ICSI.Berkeley.EDU Sent: Monday, October 30, 2006 11:03 AM Subject: [EE122] Change in office hours location Hi, I no longer sit in 311 Soda. From this week, my office hours will be held in 751 Soda Hall (alcove). TIme remains the same : Friday 11-12. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip ------------------------------------------------------------------------------ _______________________________________________ EE122 mailing list EE122 at mailman.icsi.berkeley.edu http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061103/1518239d/attachment.html From binetude at eecs.berkeley.edu Fri Nov 3 14:23:25 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Fri, 03 Nov 2006 14:23:25 -0800 Subject: [EE122] Extra Office Hour for Homework #3 Message-ID: Hello. For the Homework #3, there will be an extra office hour on next Monday (Nov 6) from 10am to 11am. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From binetude at eecs.berkeley.edu Sat Nov 4 21:57:27 2006 From: binetude at eecs.berkeley.edu (Sukun Kim) Date: Sat, 04 Nov 2006 21:57:27 -0800 Subject: [EE122] Homework #3 Clarification Message-ID: In P&D 2.21 (b), when N gets large, 32-bit error detection code breaks, so we are finding a breaking point given that up to 8-bits error is possible. For 2 (a), collisions need not be considered in calculating the propagation delay. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From chaqke at berkeley.edu Mon Nov 6 15:55:56 2006 From: chaqke at berkeley.edu (chaqke at berkeley.edu) Date: Mon, 6 Nov 2006 15:55:56 -0800 (PST) Subject: [EE122] Looking for a Project 3 Partner. Message-ID: <1232.128.32.112.99.1162857356.squirrel@calmail.berkeley.edu> I am looking for a Project3 partner. If anybody else is looking for a partner as well, please send me an email. Thanks. From vern at icir.org Tue Nov 7 22:34:15 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 07 Nov 2006 22:34:15 -0800 Subject: [EE122] Homework #4 is now out Message-ID: <200611080634.kA86YFEi077328@jaguar.icir.org> You can find it at http://inst.eecs.berkeley.edu/%7Eee122/fa06/hw/hw4.pdf I'll update the announcements and syllabus Web pages to point to it tomorrow. Vern From vern at icir.org Wed Nov 8 15:55:53 2006 From: vern at icir.org (Vern Paxson) Date: Wed, 08 Nov 2006 15:55:53 -0800 Subject: [EE122] additional reading for today's lecture - P&D 3.4 Message-ID: <200611082355.kA8NtrZt048398@jaguar.icir.org> My sincere apologies for overlooking this until now - I hope the late announcement doesn't present any difficulties, and that reading it post-lecture rather than (perhaps) in advance will work okay for folks. Vern From dilip.antony.joseph at gmail.com Wed Nov 8 16:03:06 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 8 Nov 2006 16:03:06 -0800 Subject: [EE122] office hours on friday Message-ID: <4cd0c11b0611081603o210fff1fj48a7603f8e011e7a@mail.gmail.com> Hi, There will be no discussion section on Friday as it is an institute holiday. However, I will be having my regular office hours (11-12PM 751 Soda). Regards, Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061108/93da22e1/attachment.html From dilip.antony.joseph at gmail.com Thu Nov 9 15:03:33 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 9 Nov 2006 15:03:33 -0800 Subject: [EE122] project 2 grades Message-ID: <4cd0c11b0611091503h585d4f08r7b336df2fdf4596d@mail.gmail.com> Hi, Tomorrow (Friday) was the original deadline for any changes to your project 2 grade. Since tomorrow is a holiday, the deadline is extended to next Friday (Nov 17). Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061109/2c9c1c33/attachment.html From dilip.antony.joseph at gmail.com Fri Nov 10 10:18:19 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 10 Nov 2006 10:18:19 -0800 Subject: [EE122] office hours Message-ID: <4cd0c11b0611101018hbb6db3ft3fb2637d053745cb@mail.gmail.com> Hi, Just a reminder - I have office hours today (10-12pm) at 751 Soda (alcove). Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061110/735a9779/attachment.html From dilip.antony.joseph at gmail.com Fri Nov 10 13:05:32 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 10 Nov 2006 13:05:32 -0800 Subject: [EE122] project 3 phase 1 : clarifications Message-ID: <4cd0c11b0611101305y7488e0b2x60c57684672fcd48@mail.gmail.com> Hi, Some clarifications about project 3 phase 1: 1. You need to design 'binary' message formats. HTTP messages are text based and not binary. For examples of binary message formats, please see the IP and DNS formats. 2. Binary does not mean that you have to deal at the level of individual bits for every field - byte granularity is fine. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061110/d92d43e7/attachment.html From awaage at gmail.com Sat Nov 11 09:54:51 2006 From: awaage at gmail.com (Andrew Waage) Date: Sat, 11 Nov 2006 09:54:51 -0800 Subject: [EE122] Looking for a Project 3 Partner. In-Reply-To: <1232.128.32.112.99.1162857356.squirrel@calmail.berkeley.edu> References: <1232.128.32.112.99.1162857356.squirrel@calmail.berkeley.edu> Message-ID: Please send me an email if you are still looking for a proj 3 partner. Thanks, Andrew awaage at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061111/73eb97d1/attachment.html From vern at icir.org Sun Nov 12 23:45:42 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 12 Nov 2006 23:45:42 -0800 Subject: [EE122] homework #3 solutions now available Message-ID: <200611130745.kAD7jgHc057819@jaguar.icir.org> You can get them from http://inst.eecs.berkeley.edu/%7Eee122/fa06/hw/hw3-soln.pdf - Vern From yuhung at berkeley.edu Wed Nov 15 00:07:26 2006 From: yuhung at berkeley.edu (Yu-Hung Lin) Date: Wed, 15 Nov 2006 00:07:26 -0800 Subject: [EE122] looking for a proj3 partner Message-ID: <455ACABE.3060606@berkeley.edu> I'm looking for a project partner. If anyone is interested, please send me an email, thanks. - YL From vern at icir.org Wed Nov 15 18:13:45 2006 From: vern at icir.org (Vern Paxson) Date: Wed, 15 Nov 2006 18:13:45 -0800 Subject: [EE122] topic requests for final lectures? Message-ID: <200611160213.kAG2DjCk078993@jaguar.icir.org> Folks, I'm starting to plan out the final two lectures and would be interested in any requests for topics to cover. These can either be new topics, refinements to topics we've already covered, or revisiting/reviewing previous lecture material. Please send me a note to let me know what you'd like and I'll see what I can do to accommodate. Vern From tonyw85 at berkeley.edu Wed Nov 15 18:15:41 2006 From: tonyw85 at berkeley.edu (tonyw85 at berkeley.edu) Date: Wed, 15 Nov 2006 18:15:41 -0800 (PST) Subject: [EE122] Directory lookup protocol In-Reply-To: <200611130745.kAD7jgHc057819@jaguar.icir.org> References: <200611130745.kAD7jgHc057819@jaguar.icir.org> Message-ID: <63693.69.109.219.156.1163643341.squirrel@calmail.berkeley.edu> Hi, The specs say that the directory lookup protocol uses UDP. Do we assume that it uses the reliable transport protocol described in the 2nd half of the specs? Or does it just use plain lossy unreliable UDP? Thanks. -Tony From dilip.antony.joseph at gmail.com Wed Nov 15 18:29:25 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 15 Nov 2006 18:29:25 -0800 Subject: [EE122] Directory lookup protocol In-Reply-To: <63693.69.109.219.156.1163643341.squirrel@calmail.berkeley.edu> References: <200611130745.kAD7jgHc057819@jaguar.icir.org> <63693.69.109.219.156.1163643341.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0611151829t33faf195ge885035fb94fe1fa@mail.gmail.com> The directory lookup protocol should use plain UDP - not the reliable transport protocol which you are designing over UDP. This means that messages between the client and the directory server can get lost. Dilip On 11/15/06, tonyw85 at berkeley.edu wrote: > > Hi, > > The specs say that the directory lookup protocol uses UDP. Do we assume > that it uses the reliable transport protocol described in the 2nd half of > the specs? Or does it just use plain lossy unreliable UDP? Thanks. > > -Tony > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061115/2a1aa503/attachment.html From kronrod at berkeley.edu Wed Nov 15 23:21:24 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Wed, 15 Nov 2006 23:21:24 -0800 (PST) Subject: [EE122] Directory lookup protocol In-Reply-To: <4cd0c11b0611151829t33faf195ge885035fb94fe1fa@mail.gmail.com> References: <200611130745.kAD7jgHc057819@jaguar.icir.org> <63693.69.109.219.156.1163643341.squirrel@calmail.berkeley.edu> <4cd0c11b0611151829t33faf195ge885035fb94fe1fa@mail.gmail.com> Message-ID: <1095.67.127.54.64.1163661684.squirrel@calmail.berkeley.edu> Isn't the reliable transport protocol used over the directory lookup protocol, so that would guarantee that our message gets from the client to the directory. Or is the reliable tranport protocol only between the two clients. If so, does this mean that directory lookup protocol is only used when talking to the directory server (as the name would suggest)? Alex > The directory lookup protocol should use plain UDP - not the reliable > transport protocol which you are designing over UDP. > This means that messages between the client and the directory server can > get > lost. > > Dilip > > > On 11/15/06, tonyw85 at berkeley.edu wrote: >> >> Hi, >> >> The specs say that the directory lookup protocol uses UDP. Do we assume >> that it uses the reliable transport protocol described in the 2nd half >> of >> the specs? Or does it just use plain lossy unreliable UDP? Thanks. >> >> -Tony >> >> _______________________________________________ >> EE122 mailing list >> EE122 at mailman.icsi.berkeley.edu >> http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 >> > > > > -- > _________________________________________ > Dilip Antony Joseph > Graduate Student > Computer Science Division, > University of California, Berkeley > http://www.cs.berkeley.edu/~dilip > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > From dilip.antony.joseph at gmail.com Thu Nov 16 07:12:59 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 16 Nov 2006 07:12:59 -0800 Subject: [EE122] project 3 phase 1 submission info Message-ID: <4cd0c11b0611160712p23a6deai2369079741a0c995@mail.gmail.com> Hi, A team should submit a single report. Only one of the team members need to run 'submit' - The 'submit' program will ask you the login-id of your partner. Please include the names and instructional log-in ids of both team-members somewhere near the top of your report. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061116/ca4943fc/attachment.html From lyahdav at berkeley.edu Thu Nov 16 14:18:59 2006 From: lyahdav at berkeley.edu (Liron Yahdav) Date: Thu, 16 Nov 2006 14:18:59 -0800 Subject: [EE122] project 3 phase 1 Message-ID: <000f01c709cd$39c44c20$4101a8c0@Liron> In one of your previous responses you said "you don't need to implement reliable transport for this". So does that mean we can assume that all messages in the directory lookup service are in order and not corrupt? If not, then how can we deal with data arriving out of order if we don't need to implement reliable transport? Or are we assuming that each UDP packet that arrives starts with some header of ours? Liron From dilip.antony.joseph at gmail.com Thu Nov 16 14:31:44 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 16 Nov 2006 14:31:44 -0800 Subject: [EE122] project 3 phase 1 In-Reply-To: <000f01c709cd$39c44c20$4101a8c0@Liron> References: <000f01c709cd$39c44c20$4101a8c0@Liron> Message-ID: <4cd0c11b0611161431g51535a6bx92bdbf9925c35223@mail.gmail.com> On 11/16/06, Liron Yahdav wrote: > > In one of your previous responses you said "you don't need to implement > reliable transport for this". So does that mean we can assume that all > messages in the directory lookup service are in order and not corrupt? The messages between the directory server and the client use regular UDP and not the reliable transport you will use for the actual file transfer. The client <--> directory server messages are thus affected by the properties of UDP. You will need to devise appropriate mechanisms in your client<-->directory server protocol to account for this. You may choose to design your own reliable transport protocol over UDP for the client <-->directory server interaction. But you probably do not need a full-fledged reliable transport protocol for the client <-->directory server interaction. You may want to look at DNS as an example of UDP based client <-->directory server interaction. Dilip If not, then how can we deal with data arriving out of order if we don't > need to implement reliable transport? > > Or are we assuming that each UDP packet that arrives starts with some > header > of ours? > > Liron > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061116/915c2e3a/attachment.html From kronrod at berkeley.edu Thu Nov 16 14:48:25 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Thu, 16 Nov 2006 14:48:25 -0800 (PST) Subject: [EE122] project 3 phase 1 In-Reply-To: <4cd0c11b0611161431g51535a6bx92bdbf9925c35223@mail.gmail.com> References: <000f01c709cd$39c44c20$4101a8c0@Liron> <4cd0c11b0611161431g51535a6bx92bdbf9925c35223@mail.gmail.com> Message-ID: <2142.67.127.54.64.1163717305.squirrel@calmail.berkeley.edu> Dilip. I am confused about using our headers with the UDP protocol. Can we ensure that each UDP packet will start with our header? If so, how can we do it (flushing after a some amount of data perhaps)? Can we also make sure what data is going to be in a single UDP packet? If we can't guarantee that and our message =
is split between multiple packets, we'll end up with at least one of the packets containing just data from which it's impossible to reassemble the message. Also, our we allowed to use the UDP version of the checksum or do we have to build a checksum or some other mechanism to ensure integrity? Lastly, do we care about recieving all the data from the server. For example, if the server is sending back 3 packets and the second packet is lost, can we just use the data in the 2 packets without caring about the third? i.e. there are 99 people who are sharing the file we want and each packets has information about 33 people - can we just show 66 answers instead of 99? Alex From vern at icir.org Thu Nov 16 14:58:43 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 16 Nov 2006 14:58:43 -0800 Subject: [EE122] project 3 phase 1 In-Reply-To: <2142.67.127.54.64.1163717305.squirrel@calmail.berkeley.edu> (Thu, 16 Nov 2006 14:48:25 PST). Message-ID: <200611162258.kAGMwhOl069665@jaguar.icir.org> > I am confused about using our headers with the UDP protocol. Can we ensure > that each UDP packet will start with our header? If so, how can we do it > (flushing after a some amount of data perhaps)? When you have a UDP socket and call sendto(), the data you specify in the system call is transmitted in a single UDP packet. What you receive at the other end upon calling recv() or recvfrom() is the contents of that packet, i.e., exactly the data you specified in the call to sendto(). No UDP headers are visible to your program at either the sending or the receiving end. > Can we also make sure what > data is going to be in a single UDP packet? The service model UDP provides is that you can specify up to 65K (minus a few bytes for IP/UDP headers) and that's what it will send as a datagram to the receiver. It is prudent, however, to keep your size well below that; in fact, below 1460 bytes is good to ensure you don't suffer fragmentation when transiting an Ethernet link. > If we can't guarantee that and our message =
is split > between multiple packets, we'll end up with at least one of the packets > containing just data from which it's impossible to reassemble the message. All you need to do is keep your size below UDP's maximum and this won't happen. For Phase 1, it's fine to assume that the entire request or reply is sufficiently small (though it's good for you to note what will happen if it's too large). > Also, our we allowed to use the UDP version of the checksum or do we have > to build a checksum or some other mechanism to ensure integrity? You can assume that the UDP checksum suffices and so don't need to worry about this. > Lastly, do we care about recieving all the data from the server. For > example, if the server is sending back 3 packets and the second packet is > lost, can we just use the data in the 2 packets without caring about the > third? If your protocol actually requires multiple packets, then you'll need to specify how the receiver understands whether they have all three, and what the sender does to ensure they get there. But per my comments above, for Phase 1 it's reasonable to assume that everything fits within a single packet, though you should explain what bounds this imposes on the requests & replies. Vern From alexwall at berkeley.edu Thu Nov 16 16:55:54 2006 From: alexwall at berkeley.edu (Alex Wallisch) Date: Thu, 16 Nov 2006 16:55:54 -0800 Subject: [EE122] project 3 phase 1 In-Reply-To: <200611162258.kAGMwhOl069665@jaguar.icir.org> References: <200611162258.kAGMwhOl069665@jaguar.icir.org> Message-ID: <200611161655.55506.alexwall@berkeley.edu> Wait, now I am confused. In proj1, when my UDP echoserver called recvfrom(), it passed a 'struct sockaddr_in*' into which the incoming address was stored. I was under the impression that this information came out of the UDP header and would be available to the receiver (in this case, the directory server). Is there something different about this project that prevents us from doing this? Alex Wallisch On Thursday 16 November 2006 14:58, Vern Paxson wrote: > When you have a UDP socket and call sendto(), the data you specify in the > system call is transmitted in a single UDP packet. What you receive at > the other end upon calling recv() or recvfrom() is the contents of that > packet, i.e., exactly the data you specified in the call to sendto(). No > UDP headers are visible to your program at either the sending or the > receiving end. From vern at icir.org Thu Nov 16 16:58:41 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 16 Nov 2006 16:58:41 -0800 Subject: [EE122] project 3 phase 1 In-Reply-To: <200611161655.55506.alexwall@berkeley.edu> (Thu, 16 Nov 2006 16:55:54 PST). Message-ID: <200611170058.kAH0wfJ1079662@jaguar.icir.org> > Wait, now I am confused. In proj1, when my UDP echoserver called recvfrom(), > it passed a 'struct sockaddr_in*' into which the incoming address was stored. > I was under the impression that this information came out of the UDP header > and would be available to the receiver (in this case, the directory server). > Is there something different about this project that prevents us from doing > this? No, that will work fine. Perhaps I misunderstood your question. My point was that the *buffer* returned by a recv() or recvfrom() call will just have the data that was present in the buffer passed to sendto(); it won't have any UDP header information. However, you can indeed access some of the UDP header information with the additional "from" (and "fromlen") argument, as you note above. Vern From kronrod at berkeley.edu Thu Nov 16 17:28:45 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Thu, 16 Nov 2006 17:28:45 -0800 (PST) Subject: [EE122] project 3 phase 1 In-Reply-To: <200611170058.kAH0wfJ1079662@jaguar.icir.org> References: <200611161655.55506.alexwall@berkeley.edu> (Thu, 16 Nov 2006 16:55:54 PST). <200611170058.kAH0wfJ1079662@jaguar.icir.org> Message-ID: <2630.67.127.54.64.1163726925.squirrel@calmail.berkeley.edu> I just wanted to clarify what is meant by "design a protocol with messages in binary format". Does this mean that if we have a data section it also has to be in binary format? Can we assume that a length field is sufficient to say how many bits are in data section and then use the data bits in any way we want (i.e. just have a string in the data field)? Alex From vern at icir.org Thu Nov 16 17:32:09 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 16 Nov 2006 17:32:09 -0800 Subject: [EE122] binary format (Re: project 3 phase 1) In-Reply-To: <2630.67.127.54.64.1163726925.squirrel@calmail.berkeley.edu> (Thu, 16 Nov 2006 17:28:45 PST). Message-ID: <200611170132.kAH1W9Np082748@jaguar.icir.org> > Can we assume that a length field is > sufficient to say how many bits are in data section and then use the data > bits in any way we want (i.e. just have a string in the data field)? Yes, that would be okay. The main point is not to design it using HTTP-style headers (say), or, more generally, so that the whole thing is readable as text; and, along with this, to have to deal with some issues involving binary representations of various fields. Vern From dilip.antony.joseph at gmail.com Thu Nov 16 17:35:20 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 16 Nov 2006 17:35:20 -0800 Subject: [EE122] project 3 phase 1 In-Reply-To: <2630.67.127.54.64.1163726925.squirrel@calmail.berkeley.edu> References: <200611161655.55506.alexwall@berkeley.edu> <200611170058.kAH0wfJ1079662@jaguar.icir.org> <2630.67.127.54.64.1163726925.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0611161735u781cca11hf2b9ab47eb7776b7@mail.gmail.com> HTTP is a text based protocol and NOT binary. IP and DNS have binary message formats. So your packet formats should look like IP and DNS and NOT like HTTP. You can have strings for fields like file name - you must specify which bytes in the packet format are occupied by a paticular sting. You should NOT have strings like "LOOKUP fileIamlookingfor". Dilip On 11/16/06, kronrod at berkeley.edu wrote: > > I just wanted to clarify what is meant by "design a protocol with messages > in binary format". Does this mean that if we have a data section it also > has to be in binary format? Can we assume that a length field is > sufficient to say how many bits are in data section and then use the data > bits in any way we want (i.e. just have a string in the data field)? > > Alex > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061116/e11ab0e0/attachment-0001.html From dilip.antony.joseph at gmail.com Fri Nov 17 09:54:53 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 17 Nov 2006 09:54:53 -0800 Subject: [EE122] project 3 phase 1 : grade reports sent : Grading Schema Message-ID: <4cd0c11b0611170954n672a799av44e3e1e88b1c1735@mail.gmail.com> Hi, The project 3 phase 1 grade reports were emailed to you a few minutes ago. I used the schema at the end of this email while grading. +X means you get X points. -Y means you lose Y points from your total. All the +Xs add up to 40. There are no extra credits. The schema only shows the broad categories of features I was looking for. There are many ways to name the features as well as to implement them (i.e. specify the packet format, reasoning etc.). You should have received points for any of those. If you have clarifications about your grade report, please email me. Don't forget to attach your grade report with the email. Last date for corrections to project 3 phase 1 grades will be Dec 4. Reminder: The last date for corrections to project 2 grades is today! Regards, Dilip Schema ------------ Register File Request +2 Some kind of message to register a filename with the directory server. +2 The filename is present in the request. -1 The filename is not variable length - penalty for wasting space. +2 The IP address of the peer (i.e. the client) offering the file is present in the request. -1 More than 4 bytes used for the IP address. +2 The port number of the peer (i.e. the client) offering the file is present in the request. -1 More than 2 bytes used for the port number. Register File Response +2 There are at least 2 types of responses - Success and Failure. +1 Some explanation of failure (e.g.: error code) is part of the response. +1 Some mechanism to ensure that only you can unregister the file - for example, a password. Unregister File Request +2 The message to unregister a file when you no longer wish to share it. +1 Some information that uniquely identifies the file to be unregistered is included in the unregister message. Note that multiple instances of the client software (even running on the same machine) can register files with the same name. +1 Some mechanism to prevent an attacker from unregistering a file which you registered - for example, including the password specified during register. Unregister File Response +2 There are at least 2 types of responses - Success and Failure +1 Some explanation of why unregister failed (eg: error code) - For example, invalid password was supplied. Lookup File Request +2 A message to lookup if the directory server has info about a particular file. +2 The filename is present in the request. -1 The filename is not variable length - penalty for wasting space. Lookup File Response +2 Response should contain IP address of the peer(s) having the file. +2 Response should contain the port number of the peer(s) having the file. +1 Handle the case when the directory server has multiple records matching the file being looked up. +1 Handle the case when all the matching record information will not fit in a single UDP packet. Error Response +1 Recognize that the directory server may need to send error messages that are not directly associated with the semantics of a particular request. For example, malformed request was received and the server could not understand it. Packet Format Table +3 Mention which field is at which byte. The most common way to do this is to have a packet format table. Version Numbers +1 Support extensibility of the protocol by having a version number field. Endianness +2 If you specify the endianness of multi-byte fields. The standard way is to specify that all multi-byte fields are in network byte order. Query Ids +1 Have a way to uniquely match a response with a query. Have some kind of query identifier. +1 Mention an extra security benefit of having a query Id. Support for Retries +1 Identify the fact that requests or response can get lost because UDP is unreliable. +1 Some mechanism to handle lost messages or replies - for example: Resend the request if no response is received in 1 minute. Wastage of Space -5 You can lose upto 5 points if you unnecessarily waste space in the packets (other than for filenames which have a separate penalty) eg: including a checksum when UDP already protects against corrupt packets. Non-Binary Formats -25 The specs clearly indicated that you were to design a binary message format. You can loose up to 25 points if your message formats are not binary. -------------------------------------------------------------------------- Most Points were lost due to the following reasons: 1. Many teams included only the IP address of the client having a file when answering a file lookup. You need the port number at which the client is listening as well. 2. Many teams did not mention anything about the endianness of multi-byte fields (even though there was a hint targetted at it in the specs). Any multi-byte field (for example, a 4-byte IP address) should be in network byte order. All you had to mention in your report was a line like "All multi-byte fields are in network byte order". 3a. Many teams did not provide any way to unregister the files you advertise. 3b. For the teams which did have unregister file functionality, there was no unique way to identify the exact file to be unregistered. Note that the directory server could be holding many files with the same name, registered by different clients. 4. There was no protection against malicious unregisters - Since we focus a lot on security in our class, I was hoping for you to explore at least minor security aspects of your protocol and design. Just 2-3 teams got this correct. 5. UDP already has a checksum which ensures the integrity of the packet. Very many teams included an additional checksum that was redundant. 6. Mention an extra security benefit of having a query Id - If you choose the query ids randomly, you have some protection against spoofed responses. No team mentioned this clearly. -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061117/cc76553c/attachment.html From dilip.antony.joseph at gmail.com Fri Nov 17 12:58:32 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 17 Nov 2006 12:58:32 -0800 Subject: [EE122] project 3 phase 2 specifications out Message-ID: <4cd0c11b0611171258v66b338dfi9158008ce9fe103c@mail.gmail.com> The project 3 phase 2 specifications are now available at http://inst.eecs.berkeley.edu/~ee122/fa06/projects/project3.html. I will be describing the specs during the sections on Tuesday and Wednesday. It will be great if you can read the specs before the section and raise any doubts/concerns during section. Project 3 phase 2 will involve more work than the previous 2 projects. I encourage you to start early. Regards, Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061117/631c1460/attachment.html From dilip.antony.joseph at gmail.com Fri Nov 17 13:39:20 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 17 Nov 2006 13:39:20 -0800 Subject: [EE122] project 3 phase 1 : grades in glookup Message-ID: <4cd0c11b0611171339y765d746y2b36e1811922c9c4@mail.gmail.com> Now you can see your project 3 phase 1 grades in glookup. Please email me if you see any discrepancy. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061117/ca9350dd/attachment.html From dilip.antony.joseph at gmail.com Fri Nov 17 17:56:38 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 17 Nov 2006 17:56:38 -0800 Subject: [EE122] project 3 phase 1 : feedback on reliable transport sent Message-ID: <4cd0c11b0611171756s751b9089p1da73b96fd25f1f8@mail.gmail.com> Hi, I have emailed the feedback on reliable transport to the teams who submitted it. If I somehow missed your document on reliable transport, I am sorry. Please email me and I will make sure I look at it. If you need more feedback or have other questions, please email me. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061117/042be18f/attachment.html From vern at icir.org Sun Nov 19 17:13:59 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 19 Nov 2006 17:13:59 -0800 Subject: [EE122] reading for Monday's lecture Message-ID: <200611200113.kAK1DxUE095232@jaguar.icir.org> I've decided to cover more cryptography in tomorrow's lecture than I had originally planned. Originally, the reading for the lecture was: intro to Chapter 8, intro to 8.1, read 8.1.1, familiarity with 8.2 and 8.3, read 8.5 This is now slightly broader, adding "familiarity with 8.1" (i.e., with the rest of 8.1 beyond the intro and 8.1.1). Familiarity means read to comprehend it at a high level - but you don't need to comprehend the technical details unless you're particularly interested. Vern From vern at icir.org Mon Nov 20 18:18:13 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 20 Nov 2006 18:18:13 -0800 Subject: [EE122] office hours on Wednesday Message-ID: <200611210218.kAL2IDuJ068359@jaguar.icir.org> I've received a request via email, so I'll be holding my regular Soda office hours on Wednesday, 3-4PM. You can also email me for an appointment if that time doesn't work for you. Vern From dilip.antony.joseph at gmail.com Tue Nov 21 00:42:40 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 21 Nov 2006 00:42:40 -0800 Subject: [EE122] project 3 phase 2: Updated directory protocol specs Message-ID: <4cd0c11b0611210042w56984354ta686318c1ea5d85f@mail.gmail.com> Hi, In the project 3 phase 2 directory protocol, you no longer have to include the actual IP address of your client machine in the Register and Unregister messages. You can put any random value in there. The directory server just uses the source IP address of the UDP request packet. This update was made so that you can avoid the cumbersome methods to find your local IP address. Please refer the specs for more details. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061121/d161c400/attachment.html From dilip.antony.joseph at gmail.com Tue Nov 21 00:51:01 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 21 Nov 2006 00:51:01 -0800 Subject: [EE122] discussion sections this week Message-ID: <4cd0c11b0611210051w5df4795eiecc84719cbb9af0@mail.gmail.com> Hi, I will be describing project 3 phase 2 in the discussion sections on Tuesday and Wednesday. It will be great if you browse through the specs before coming to section. This will enable us to spend more time on the more confusing/difficult parts of phase 2. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061121/b9eef9bc/attachment.html From dilip.antony.joseph at gmail.com Sat Nov 25 14:16:33 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 25 Nov 2006 14:16:33 -0800 Subject: [EE122] project 3 phase 2: clarification Message-ID: <4cd0c11b0611251416j23f210dbkf34909ea3136f77c@mail.gmail.com> Hi, Some of you emailed me if MNL should be used for the directory lookup part of phase 2. MNL should be used only for the p2p part, i.e. the actual transfer of files reliably. The directory lookup uses regular UDP sendto (not MNL_sendto). Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061125/6a5d961b/attachment.html From kevin.liu at gmail.com Sun Nov 26 00:58:52 2006 From: kevin.liu at gmail.com (Kevin Liu) Date: Sun, 26 Nov 2006 00:58:52 -0800 Subject: [EE122] quick hwk 4 question Message-ID: Hi Sukun, This I was wondering when homework 4 is actually due. On the pdf file, it says november 27th but on the class calendar it says november 29th. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061126/5c26b974/attachment.html From vern at icir.org Sun Nov 26 08:18:49 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 26 Nov 2006 08:18:49 -0800 Subject: [EE122] quick hwk 4 question In-Reply-To: (Sun, 26 Nov 2006 00:58:52 PST). Message-ID: <200611261618.kAQGInFd081995@jaguar.icir.org> > This I was wondering when homework 4 is actually due. On the pdf file, it > says november 27th but on the class calendar it says november 29th. Sorry about that - we shifted the date to November 29th but hadn't updated the PDF. I've done that now. Vern From binetude at EECS.Berkeley.EDU Sun Nov 26 21:31:29 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Sun, 26 Nov 2006 21:31:29 -0800 Subject: [EE122] Homework #3 Grade Message-ID: The grade of Homework #3 is entered into the system. Fixes to Homework #1 and #2 are also entered. Detailed explanation about grading will be sent out soon. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From binetude at EECS.Berkeley.EDU Mon Nov 27 19:43:53 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Mon, 27 Nov 2006 19:43:53 -0800 Subject: [EE122] Homework #4 Problem #7 Message-ID: For drawing time-sequence plot, there can be multiple ways. You can use any working method. 1. Ethereal draws a graph directly from the trace file. In a menu, "Statistics" -> "TCP Stream Graph" Thanks to Stephen Ng. 2. "awk" is a convenient tool for parsing data. With the parsed data, gnuplot or Excel can be used to draw a plot. 3. You can write a perl or python script to parse the data. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From vern at icir.org Mon Nov 27 19:48:40 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 27 Nov 2006 19:48:40 -0800 Subject: [EE122] Homework #4 Problem #7 In-Reply-To: (Mon, 27 Nov 2006 19:43:53 PST). Message-ID: <200611280348.kAS3meil082350@jaguar.icir.org> > For drawing time-sequence plot, there can be multiple ways. You can use any working method. > > 1. Ethereal draws a graph directly from the trace file. In a menu, "Statistics" -> "TCP Stream Graph" > Thanks to Stephen Ng. > > 2. "awk" is a convenient tool for parsing data. With the parsed data, gnuplot or Excel can be used to draw a plot. > > 3. You can write a perl or python script to parse the data. Two more: 4. Use the ipsumdump tool http://www.cs.ucla.edu/~kohler/ipsumdump/ 5. Edit the output of tcpdump with your favorite editor; use global substitutions to strip out the information you don't want - Vern From binetude at EECS.Berkeley.EDU Mon Nov 27 20:42:09 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Mon, 27 Nov 2006 20:42:09 -0800 Subject: [EE122] Fwd: Re: Re: Homework #4 Problem #7 Message-ID: Thanks to Brad Andrews. ==================================================== -------------- next part -------------- An embedded message was scrubbed... From: Brad Andrews Subject: Re: Re: [EE122] Homework #4 Problem #7 Date: Mon, 27 Nov 2006 20:26:22 -0800 Size: 3925 Url: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061127/fe0af8d4/attachment.mht From vern at icir.org Mon Nov 27 21:36:27 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 27 Nov 2006 21:36:27 -0800 Subject: [EE122] Clarification regarding Homework #4 Problem 4(c) Message-ID: <200611280536.kAS5aRhs083929@jaguar.icir.org> There have been questions regarding the difference between parts (b) and (c) of problem 4. The mechanisms in both parts implement a form of AIMD (used in TCP's Congestion Avoidance mode). However, they don't wind up opening the window at exactly the same rate. The point of this problem is to understand the magnitude of the difference between the three schemes listed in (a), (b) and (c). "Compute the throughput approximately" does *not* mean to ignore this difference - just that we don't want you worrying about minor details (like transmission delays, which don't add up to much on a 100 Mbps path). Vern Also, a hint for part (c): for "increments CWND by a computed number of bytes for every incoming ACK", neither the number of bytes acknowledged nor the size of the incoming ACK affects this computation. It's just a function of sender-side state variables, and is one of the standard forms presented in lecture. From vern at icir.org Tue Nov 28 13:15:52 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 28 Nov 2006 13:15:52 -0800 Subject: [EE122] a clarification regarding using openssl in Homework #4 Message-ID: <200611282115.kASLFqDD096214@jaguar.icir.org> Steve Liang asked about why when running openssl it complains that all of the certification verifications fail. I'm pretty sure this is because the openssl tool itself doesn't have any CAs wired into it (it's meant for debugging, so you'd explicitly configure it with whatever CAs you want to test with). In any case, you can ignore this peculiarity for the assignment. Vern From binetude at EECS.Berkeley.EDU Tue Nov 28 14:55:23 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Tue, 28 Nov 2006 14:55:23 -0800 Subject: [EE122] Discussion Section on Wednesday & Extra Office Hour Message-ID: In the discussion section on Wednesday, Homework #4 will be covered by me. For Homework #4, there will be an extra office hour from 10:00am to 11:00am tomorrow (Wednesday). Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From dilip.antony.joseph at gmail.com Wed Nov 29 19:03:02 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 29 Nov 2006 19:03:02 -0800 Subject: [EE122] project 3 directory lookup Message-ID: <4cd0c11b0611291903g5c65b18ekca7ba2d2fca1138d@mail.gmail.com> Hi, Most of the instructional machines run Solaris (Sparc processor). The directory server is running on a machine with an Intel processor. The directory lookup part of your program may work fine if you try running it on another Intel processor machine. The same code may fail when you try from one of the instructional machines. The code will be evaluated on c199.eecs. So it will be a good idea to test your code on those machines, right from the beginning. Ethereal or tcpdump will be very useful tools in debugging the directory lookup part of your program. These tools will actually show you the contents of the request packet you send out. You can them compare that to the specs and see if everything is okay. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061129/74547441/attachment.html From vern at icir.org Sat Dec 2 13:53:13 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 02 Dec 2006 13:53:13 -0800 Subject: [EE122] reading for Monday's lecture Message-ID: <200612022153.kB2LrDjc067409@jaguar.icir.org> Monday's lecture will be a potpourri of three topics: overviews of multimedia, wireless, and denial-of-service (finishing up from last week's lecture; may be omitted if I find the other two already will take up the full lecture). For these, you've already been assigned the corresponding reading in P&D (2.8, 6.5 8.5) for previous lectures. In addition, the syllabus for Monday's lecture listed P&D 4.3.5. This is on IPv6, which I won't have time to cover, so you should now consider that reading optional. Vern From vern at icir.org Wed Dec 6 18:58:29 2006 From: vern at icir.org (Vern Paxson) Date: Wed, 06 Dec 2006 18:58:29 -0800 Subject: [EE122] Dilip's extra office hours for project-related questions Message-ID: <200612070258.kB72wTip042430@jaguar.icir.org> Dilip will hold extra office hours tomorrow (Thursday) at 3PM. The likely location is 751 Soda. However, if that room turns out to be occupried, he'll leave a note as to where he's relocated. Vern From dilip.antony.joseph at gmail.com Fri Dec 8 13:47:00 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Fri, 8 Dec 2006 13:47:00 -0800 Subject: [EE122] discussion section slides Message-ID: <4cd0c11b0612081347n71959b4fy420122e208f61ff7@mail.gmail.com> Hi, The slides used during this week's discussion sections (on IPv6 and overlays) as well as slides/notes from previous discussion sections are available at http://www.cs.berkeley.edu/~dilip/ee122_fa06/discussion.shtml Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061208/6a7056be/attachment.html From vern at icir.org Sat Dec 9 14:59:17 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 09 Dec 2006 14:59:17 -0800 Subject: [EE122] solutions for homework #4 Message-ID: <200612092259.kB9MxHZL030135@jaguar.icir.org> These are now available from: http://inst.eecs.berkeley.edu/%7Eee122/fa06/hw/hw4-soln.pdf Sukun will have grades posted soon. Vern From lyahdav at berkeley.edu Sat Dec 9 23:12:07 2006 From: lyahdav at berkeley.edu (Liron Yahdav) Date: Sat, 9 Dec 2006 23:12:07 -0800 Subject: [EE122] Proj3 Directory Lookup Service question Message-ID: <000001c71c2a$83908840$4101a8c0@Liron> Because we are retransmitting requests to the Directory Lookup Service (DLS) if a reply isn't received within some time frame, there is no way to tell if the DLS server is unreachable or our packet (or reply) is just getting dropped. So I was wondering if we need to check if the DLS server is reachable before sending requests. If not, the program will just keep trying to resend the requests until the program is killed with Ctrl+C (is this the correct behavior?). Liron From dilip.antony.joseph at gmail.com Sat Dec 9 23:15:46 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sat, 9 Dec 2006 23:15:46 -0800 Subject: [EE122] Proj3 Directory Lookup Service question In-Reply-To: <000001c71c2a$83908840$4101a8c0@Liron> References: <000001c71c2a$83908840$4101a8c0@Liron> Message-ID: <4cd0c11b0612092315m793076b4m210075014916d85c@mail.gmail.com> You can abort with an appropriate error message after a few tries at sending the request messages. Dilip On 12/9/06, Liron Yahdav wrote: > > Because we are retransmitting requests to the Directory Lookup Service > (DLS) > if a reply isn't received within some time frame, there is no way to tell > if > the DLS server is unreachable or our packet (or reply) is just getting > dropped. So I was wondering if we need to check if the DLS server is > reachable before sending requests. If not, the program will just keep > trying > to resend the requests until the program is killed with Ctrl+C (is this > the > correct behavior?). > > Liron > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061209/85333725/attachment.html From theochu at gmail.com Sat Dec 9 23:58:40 2006 From: theochu at gmail.com (Theophilus Chu) Date: Sat, 9 Dec 2006 23:58:40 -0800 Subject: [EE122] Proj3 spec clarifications Message-ID: Hi, I just want to check what is the right procedure when we are given the call BFS fetch newfile* Should we do BFS lookup newfile* and fetch the first file that comes up in the lookup response or is it not allowed (and error should be returned)? Theo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061209/54e5586d/attachment.html From dilip.antony.joseph at gmail.com Sun Dec 10 00:02:19 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 10 Dec 2006 00:02:19 -0800 Subject: [EE122] Proj3 spec clarifications In-Reply-To: References: Message-ID: <4cd0c11b0612100002h1d42f44fxefb646216eca33e3@mail.gmail.com> I am going to test 'fetch' only with specific files (no patterns). One good way to support patterns will be to display a list of available files to the user and have the user choose the one to fetch. It is not mandatory to implement this feature. Dilip On 12/9/06, Theophilus Chu wrote: > > Hi, > > I just want to check what is the right procedure when we are given the > call BFS fetch newfile* > Should we do BFS lookup newfile* and fetch the first file that comes up in > the lookup response > or is it not allowed (and error should be returned)? > > Theo > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > > > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061210/2c52c1fd/attachment.html From binetude at EECS.Berkeley.EDU Sun Dec 10 00:46:37 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Sun, 10 Dec 2006 00:46:37 -0800 Subject: [EE122] Homework #4 Grade is entered into the system Message-ID: Homework #4 Grade is entered into the system. You can pick up the Homework #4 in the office hour. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From joeli at berkeley.edu Sun Dec 10 03:58:22 2006 From: joeli at berkeley.edu (joeli at berkeley.edu) Date: Sun, 10 Dec 2006 03:58:22 -0800 (PST) Subject: [EE122] Proj3 MNLDaemon question Message-ID: <2028.136.152.170.91.1165751902.squirrel@calmail.berkeley.edu> Hi, When i try to run MNLDaemon samplecfg/dnone0.txt on solaris machine, it gives me the message: ld.so.1: MNLDaemon: fatal: libstdc++.so.6: open failed: No such file or directory Killed How do you fix that?? Sincerely, Zhou Li From kronrod at berkeley.edu Sun Dec 10 04:37:01 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Sun, 10 Dec 2006 04:37:01 -0800 (PST) Subject: [EE122] Proj3 MNLDaemon question In-Reply-To: <2028.136.152.170.91.1165751902.squirrel@calmail.berkeley.edu> References: <2028.136.152.170.91.1165751902.squirrel@calmail.berkeley.edu> Message-ID: <4654.68.121.146.19.1165754221.squirrel@calmail.berkeley.edu> Look inside README.txt... before running MNLDaemon, you need to either do export LD_LIBRARY_PATH=/home/ff/ee122/lib:/usr/sww/lib/ or setenv LD_LIBRARY_PATH /home/ff/ee122/lib:/usr/sww/lib/ Also, if you get "permission denied", your file is probably not an executable. You can fix this by doing: "chmod 775 MNLDaemon" Alex > Hi, > > When i try to run MNLDaemon samplecfg/dnone0.txt on solaris machine, it > gives me the message: > ld.so.1: MNLDaemon: fatal: libstdc++.so.6: open failed: No such file or > directory > Killed > > How do you fix that?? > > Sincerely, > Zhou Li > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > From kronrod at berkeley.edu Sun Dec 10 16:19:59 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Sun, 10 Dec 2006 16:19:59 -0800 (PST) Subject: [EE122] MNL args Message-ID: <1357.68.121.146.19.1165796399.squirrel@calmail.berkeley.edu> Isn't iWindowSize always going to be a constant value? It is the number of bytes I have available in my recieve buffer starting with the byte I ACKED. If our program writes everything in the buffer up to the point we've ACKED to a file, then the recieve buffer will always have all the room available for data starting from ACK byte. Is this right or am I missing something? Also, if our we are using a sliding window, but our seqNum starts at 0, it's okay to pass in 0 to iSeqNumStart, right? Or should we avoid starting seqNum with 0. What's the point of these args anyways? Alex. From dilip.antony.joseph at gmail.com Sun Dec 10 16:29:19 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 10 Dec 2006 16:29:19 -0800 Subject: [EE122] MNL args In-Reply-To: <1357.68.121.146.19.1165796399.squirrel@calmail.berkeley.edu> References: <1357.68.121.146.19.1165796399.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0612101629t2ab19faey11e08a667e7db577@mail.gmail.com> On 12/10/06, kronrod at berkeley.edu wrote: > > Isn't iWindowSize always going to be a constant value? It is the number of > bytes I have available in my recieve buffer starting with the byte I > ACKED. If our program writes everything in the buffer up to the point > we've ACKED to a file, then the recieve buffer will always have all the > room available for data starting from ACK byte. Is this right or am I > missing something? iWindowSize is the effective window size. This will be a constant (whatever your program sets) if you are not doing flow control and congestion control. If you buffer packets received out of order, then your advertised window will vary even if you immediately write all in order bytes to disk. Also, if our we are using a sliding window, but our seqNum starts at 0, > it's okay to pass in 0 to iSeqNumStart, right? Or should we avoid starting > seqNum with 0. What's the point of these args anyways? iSeqNumStart is the sequence number of the starting byte in the packet which you are sending using MNL_sendto(). The overall starting number can be 0. These params will only be used by me for understanding how your protocol works. It doesn't affect MNL_sendto in any way. Dilip Alex. > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061210/c5814cc4/attachment.html From kronrod at berkeley.edu Sun Dec 10 16:55:01 2006 From: kronrod at berkeley.edu (kronrod at berkeley.edu) Date: Sun, 10 Dec 2006 16:55:01 -0800 (PST) Subject: [EE122] MNL args In-Reply-To: <4cd0c11b0612101629t2ab19faey11e08a667e7db577@mail.gmail.com> References: <1357.68.121.146.19.1165796399.squirrel@calmail.berkeley.edu> <4cd0c11b0612101629t2ab19faey11e08a667e7db577@mail.gmail.com> Message-ID: <1405.68.121.146.19.1165798501.squirrel@calmail.berkeley.edu> I dont see how out of order packets would change advertised window. If i have the buffer BUF -> [-------------xxxx--------------] I have written everything to the point that I have ACKED, so the next byte I'm expecting is going to go into BUF[0]. Although there may be already some data stored in the middle of the buffer, the buffer, thus the advertised window, is of size buf. No? So I guess the question is: is iWindowSize how much the reciever says he can recieve, or is it how much the sender can send. If it is from the point of sender, then is the effective window (based on flow control) the amount of bytes the sender can send after the bytes that are in flight? This is the only thing I can think of which would make the value not constant. Alex > On 12/10/06, kronrod at berkeley.edu wrote: >> >> Isn't iWindowSize always going to be a constant value? It is the number >> of >> bytes I have available in my recieve buffer starting with the byte I >> ACKED. If our program writes everything in the buffer up to the point >> we've ACKED to a file, then the recieve buffer will always have all the >> room available for data starting from ACK byte. Is this right or am I >> missing something? > > > > iWindowSize is the effective window size. > This will be a constant (whatever your program sets) if you are not doing > flow control and congestion control. > If you buffer packets received out of order, then your advertised window > will vary even if you immediately write all in order bytes to disk. > > > Also, if our we are using a sliding window, but our seqNum starts at 0, >> it's okay to pass in 0 to iSeqNumStart, right? Or should we avoid >> starting >> seqNum with 0. What's the point of these args anyways? > > > iSeqNumStart is the sequence number of the starting byte in the packet > which > you are sending using MNL_sendto(). > > The overall starting number can be 0. > > These params will only be used by me for understanding how your protocol > works. It doesn't affect MNL_sendto in any way. > > Dilip > > > Alex. >> >> _______________________________________________ >> EE122 mailing list >> EE122 at mailman.icsi.berkeley.edu >> http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 >> > > > > -- > _________________________________________ > Dilip Antony Joseph > Graduate Student > Computer Science Division, > University of California, Berkeley > http://www.cs.berkeley.edu/~dilip > From dank at berkeley.edu Sun Dec 10 17:56:04 2006 From: dank at berkeley.edu (Daniel Killebrew) Date: Sun, 10 Dec 2006 17:56:04 -0800 Subject: [EE122] proj makefile Message-ID: <457CBAB4.5030303@berkeley.edu> Should we be building our Makefile for 'gmake' or 'make' ? I ask because 'make' fails to build the MNL sources, while 'gmake' does it fine. I much prefer 'gmake' since it actually seems to work... Daniel From dilip.antony.joseph at gmail.com Sun Dec 10 18:21:23 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 10 Dec 2006 18:21:23 -0800 Subject: [EE122] proj makefile In-Reply-To: <457CBAB4.5030303@berkeley.edu> References: <457CBAB4.5030303@berkeley.edu> Message-ID: <4cd0c11b0612101821m3b76d6c4m1b5a164e21cbb77d@mail.gmail.com> gmake is fine. Dilip On 12/10/06, Daniel Killebrew wrote: > > Should we be building our Makefile for 'gmake' or 'make' ? I ask because > 'make' fails to build the MNL sources, while 'gmake' does it fine. I > much prefer 'gmake' since it actually seems to work... > > Daniel > > _______________________________________________ > EE122 mailing list > EE122 at mailman.icsi.berkeley.edu > http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061210/154fa84b/attachment.html From dilip.antony.joseph at gmail.com Sun Dec 10 18:32:43 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Sun, 10 Dec 2006 18:32:43 -0800 Subject: [EE122] MNL args In-Reply-To: <1405.68.121.146.19.1165798501.squirrel@calmail.berkeley.edu> References: <1357.68.121.146.19.1165796399.squirrel@calmail.berkeley.edu> <4cd0c11b0612101629t2ab19faey11e08a667e7db577@mail.gmail.com> <1405.68.121.146.19.1165798501.squirrel@calmail.berkeley.edu> Message-ID: <4cd0c11b0612101832o6a503eat87dfc5dca87ede1e@mail.gmail.com> On 12/10/06, kronrod at berkeley.edu wrote: > > I dont see how out of order packets would change advertised window. > If i have the buffer > > BUF -> [-------------xxxx--------------] > > I have written everything to the point that I have ACKED, so the next byte > I'm expecting is going to go into BUF[0]. Although there may be already > some data stored in the middle of the buffer, the buffer, thus the > advertised window, is of size buf. No? Yes, if this is the way you manage the buffer, your advertised window is always the total receiver buffer size. So I guess the question is: is iWindowSize how much the reciever says he > can recieve, or is it how much the sender can send. If it is from the > point of sender, then is the effective window (based on flow control) the > amount of bytes the sender can send after the bytes that are in flight? > This is the only thing I can think of which would make the value not > constant. It is the effective window = min(congestion window, advertised window). Depending on how you do do flow control and buffer management at the receiver, advertised window can vary. If you do congestion control, congestion window will vary. Thus your effective window can vary. Alex > > > > > On 12/10/06, kronrod at berkeley.edu wrote: > >> > >> Isn't iWindowSize always going to be a constant value? It is the number > >> of > >> bytes I have available in my recieve buffer starting with the byte I > >> ACKED. If our program writes everything in the buffer up to the point > >> we've ACKED to a file, then the recieve buffer will always have all the > >> room available for data starting from ACK byte. Is this right or am I > >> missing something? > > > > > > > > iWindowSize is the effective window size. > > This will be a constant (whatever your program sets) if you are not > doing > > flow control and congestion control. > > If you buffer packets received out of order, then your advertised window > > will vary even if you immediately write all in order bytes to disk. > > > > > > Also, if our we are using a sliding window, but our seqNum starts at 0, > >> it's okay to pass in 0 to iSeqNumStart, right? Or should we avoid > >> starting > >> seqNum with 0. What's the point of these args anyways? > > > > > > iSeqNumStart is the sequence number of the starting byte in the packet > > which > > you are sending using MNL_sendto(). > > > > The overall starting number can be 0. > > > > These params will only be used by me for understanding how your protocol > > works. It doesn't affect MNL_sendto in any way. > > > > Dilip > > > > > > Alex. > >> > >> _______________________________________________ > >> EE122 mailing list > >> EE122 at mailman.icsi.berkeley.edu > >> http://mailman.icsi.berkeley.edu/mailman/listinfo/ee122 > >> > > > > > > > > -- > > _________________________________________ > > Dilip Antony Joseph > > Graduate Student > > Computer Science Division, > > University of California, Berkeley > > http://www.cs.berkeley.edu/~dilip > > > > > -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061210/c7cc2513/attachment.html From vern at icir.org Mon Dec 11 15:42:42 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 11 Dec 2006 15:42:42 -0800 Subject: [EE122] deadline for regrading - noon Sunday Dec 17 Message-ID: <200612112342.kBBNggcx069528@jaguar.icir.org> Please note, the deadline for regrade requests for either Project #3 or Homework #4 is this coming Sunday, Dec. 17, at *noon*. From binetude at EECS.Berkeley.EDU Mon Dec 11 16:39:10 2006 From: binetude at EECS.Berkeley.EDU (Sukun Kim) Date: Mon, 11 Dec 2006 16:39:10 -0800 Subject: [EE122] Checking Homework Grade Message-ID: You can pick up Homeworks during office hours: Dec 12 (Tue) 11:00 to noon Dec 15 (Fri) 1:00pm to 3:00pm In case these office hours are not feasible, you can also send me an email, then I will let you know detailed points. If there is any question regarding Homeworks, you are very welcome to visit during office hours. This would be the easiest and quickest way. Or you can also send an email. Sukun Kim Contact Information and more - http://www.eecs.berkeley.edu/~binetude From dilip.antony.joseph at gmail.com Mon Dec 11 19:57:08 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Mon, 11 Dec 2006 19:57:08 -0800 Subject: [EE122] project 3 phase 2 early grading Message-ID: <4cd0c11b0612111957v15d15a2s5657763b60888894@mail.gmail.com> Hi, If you have submitted project 3 phase 2 and won't be making any further changes to it, please email me so that I can start evaluating your submissions today. If you email me today or tomorrow, you will get your grade report soon after the last slip deadline (like in project 2 early evaluation). Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061211/ed3416e6/attachment.html From dilip.antony.joseph at gmail.com Tue Dec 12 23:21:23 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Tue, 12 Dec 2006 23:21:23 -0800 Subject: [EE122] project 3 grading and office hours Message-ID: <4cd0c11b0612122321t74f91b1fv7c50704da1aaafbb@mail.gmail.com> Hi, I will be having office hours at the following times: Wednesday : 2-3 PM Thursday : 2-3 PM Friday: 11-12PM Venue: 751 Soda (If the room is occupied, we will move somewhere else- I will leave a note and send an email if we move.) I have finished evaluating the project 3 phase 2 submitted by teams who responded to my earlier email regarding early grading. Those teams will get their grade reports tomorrow night soon after 11 PM. If you submit tonight and won't be making any changes, please email me so that I can grade your submissions during the day tomorrow. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061212/642e4205/attachment.html From alexwall at berkeley.edu Tue Dec 12 23:35:47 2006 From: alexwall at berkeley.edu (Alex Wallisch) Date: Tue, 12 Dec 2006 23:35:47 -0800 Subject: [EE122] project 3 grading and office hours In-Reply-To: <4cd0c11b0612122321t74f91b1fv7c50704da1aaafbb@mail.gmail.com> References: <4cd0c11b0612122321t74f91b1fv7c50704da1aaafbb@mail.gmail.com> Message-ID: <200612122335.47289.alexwall@berkeley.edu> Hi, Sorry for not responding earlier. I turned mine in on Sunday night, and I won't be editing it. It wasn't as finished as I would have liked, but I wanted to have it in by the deadline. Thanks a lot for your help with it. I'm sorry it didn't come out as well as it should have. Alex Wallisch On Tuesday 12 December 2006 23:21, Dilip Joseph wrote: > Hi, > > I will be having office hours at the following times: > Wednesday : 2-3 PM > Thursday : 2-3 PM > Friday: 11-12PM > > Venue: 751 Soda (If the room is occupied, we will move somewhere else- I > will leave a note and send an email if we move.) > > I have finished evaluating the project 3 phase 2 submitted by teams who > responded to my earlier email regarding early grading. Those teams will > get their grade reports tomorrow night soon after 11 PM. If you submit > tonight and won't be making any changes, please email me so that I can > grade your submissions during the day tomorrow. > > Regards > > Dilip From dilip.antony.joseph at gmail.com Wed Dec 13 14:13:18 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 13 Dec 2006 14:13:18 -0800 Subject: [EE122] office hours now - change of location Message-ID: <4cd0c11b0612131413p69959f1saa96bd76e11a2498@mail.gmail.com> Hi, 751 Soda is occupied. So my office hours(now) will be in the space near the elevators on the 7th floor, directly across 751 alcove. Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061213/da448d8e/attachment.html From dilip.antony.joseph at gmail.com Wed Dec 13 23:06:56 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Wed, 13 Dec 2006 23:06:56 -0800 Subject: [EE122] project 3 phase 2 grades Message-ID: <4cd0c11b0612132306u1b094196n7735bba150dfcd95@mail.gmail.com> Hi, I will start sending the project 3 phase 2 grade reports in a few minutes. I am sorry if I missed out grading some group which emailed me. If you do not receive your grade report today, you will receive it before tomorrow evening. If you have any concerns about project 3 phase 2 grading, please contact me as early as possible. I will not be in Berkeley after Sunday 12 noon. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061213/4b8785ad/attachment.html From dilip.antony.joseph at gmail.com Thu Dec 14 10:43:28 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 14 Dec 2006 10:43:28 -0800 Subject: [EE122] project 3 phase 2 - evaluation files Message-ID: <4cd0c11b0612141043n52b669fege9b5aedfd55ed8ff@mail.gmail.com> Hi, The MNL config files and test files for reliable transfer are at http://inst.eecs.berkeley.edu/~ee122/fa06/projects/proj3evalfiles.tar.gz. Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061214/6aee3a24/attachment.html From dilip.antony.joseph at gmail.com Thu Dec 14 17:01:20 2006 From: dilip.antony.joseph at gmail.com (Dilip Joseph) Date: Thu, 14 Dec 2006 17:01:20 -0800 Subject: [EE122] project 3 phase 2: Statistics & Important announcements Message-ID: <4cd0c11b0612141701s6ccd7f46jdcb77daff7ca1aa5@mail.gmail.com> Hi, All project 3 phase 2 reports have been emailed and the grades have been entered into glookup. Extra credit has been entered separately. Those of you who got the report yesterday would have received the latest report again. IMPORTANT Announcments: 1. If you haven't got your report, please email me immediately. 2. If you have some concerns about project 3 grading, please email me immediately. 3. Verify that the grade in glookup and your grade report are the same. If you notice any discrepancy, please email me immediately. 4. The last date for any changes to your project 3 grade is Dec 17, Sunday 12 noon. After that time, I will no longer be in Berkeley. Statistics: Total Students: 50 (stats are per student and not per group) Total Without Extra Credit: avg=111.84 std dev= 49.24 Extra Credit Alone: avg=7.8 sd= 14.84 Regards Dilip -- _________________________________________ Dilip Antony Joseph Graduate Student Computer Science Division, University of California, Berkeley http://www.cs.berkeley.edu/~dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/ee122/attachments/20061214/d3ba0b9b/attachment.html From vern at icir.org Fri Dec 15 00:24:19 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 15 Dec 2006 00:24:19 -0800 Subject: [EE122] clarification regarding the single "crib sheet" for the final Message-ID: <200612150824.kBF8OJ9H055865@jaguar.icir.org> Some folks were wondering whether this sheet is in addition to the sheet used for the midterm. The answer is no - you can only use one sheet total. Also, a reminder that the scope of the questions is the material since the midterm, rather than comprehensive over the whole course (though some of the earlier material will inevitably be relevant due to the nature of how networking involves inter-related mechanisms). Vern From vern at icir.org Fri Dec 15 14:56:40 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 15 Dec 2006 14:56:40 -0800 Subject: [EE122] regarding details of crypto & BGP for the final exam Message-ID: <200612152256.kBFMueF9036307@jaguar.icir.org> FYI, here's a reply I just sent to Abhishek Mishra (his text quoted with his permission) regarding what will be assumed on the final about degree of details for cryptography and BGP. Vern > How deeply do we need to understand cryptography - are we responsible for > the detailed mathematical procedures that are part of DES, for example? Or > do we need to know more about how cryptography is used, the general > information such as various types of crptography, and what they do (at a > high-level) to attain security? Just the latter: how it's used; the differences between public-key vs. secret-key (asymmetric/symmetric); how public key signatures work and provide non-repudiation; the role of hash functions for producing digests as integrity checks and as what gets signed for public-key signatures due to the expense of public-key operations; the sort of information that goes into a PKI certificate and conceptually how it's validated; the names of the main technologies (MD5, SHA-1, AES, DES, RSA) and which they correspond to; the properties of one-time pads; how this comes together into the messages exchanged by HTTPS. Stuff like that. > Also, do we need to know the 'details' of BGP? In your lecture slides > (lecture 16) you point out that the details are boring and that we should > pay more attention to the 'why' than the 'how' (it even says 'try to stay > awake as long as you can' before the details section begins :). Does this > hold for the final as well? Correct, you needn't worry about the details. (Note, those are actually Prof. Scott Shenker's slides, by the way.) You should understand things like: the motivation behind BGP; why it uses path-vector rather than distance-vector or link-state; what sort of problems remain, conceptually; the conceptual difference between intra-domain and inter-domain routing. From vern at icir.org Fri Dec 15 16:36:16 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 15 Dec 2006 16:36:16 -0800 Subject: [EE122] logistics for tomorrow's final exam Message-ID: <200612160036.kBG0aGbA044388@jaguar.icir.org> A reminder: tomorrow's exam is scheduled for 8AM (gads) *in 2 Le Conte* (not in 155 Donner). The exam will start on "Berkeley Time", i.e., at 8:10AM, and you can take up to three full hours (so everyone must finish by 11:10AM). See you bright and early .... Vern From vern at icir.org Thu Dec 21 19:51:58 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 21 Dec 2006 19:51:58 -0800 Subject: [EE122] grades & solutions to the final Message-ID: <200612220351.kBM3pwoO054694@jaguar.icir.org> Solutions to the final are now available from http://inst.eecs.berkeley.edu/%7Eee122/fa06/notes/final-soln.pdf Many folks did *really* well!, which I was delighted to see. Along these lines, Dilip, Sukun & I are in agreement that overall the class exhibited a great deal of first-rate hard work. In accordance with the policy I outlined at the beginning of the class, this shifted the grading curve upward. That plus the extra credit earned by a number of you resulted in about 1/3 of the class receiving an A of some sort - well merited! I've now entered grades into BearFacts. As usual, if you have any particular questions, send me a note. Best wishes for the holidays and the New Year - and my heartfelt thanks to all of you for your efforts. Vern