From merry_c at berkeley.edu Sat Dec 1 18:26:27 2007 From: merry_c at berkeley.edu (Merry Choi) Date: Sat, 1 Dec 2007 18:26:27 -0800 Subject: [ee122] MNL_sendto for ACKing? In-Reply-To: <330471bf0711302051m1bdcaf86kee336bbb8c93dfd5@mail.gmail.com> Message-ID: Are we supposed to use MNL_sendto on the receiver side to ACK packets? Or will send_to suffice, as with TestRecv? From fowler at eecs.berkeley.edu Sat Dec 1 18:27:43 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sat, 1 Dec 2007 18:27:43 -0800 Subject: [ee122] MNL_sendto for ACKing? In-Reply-To: References: <330471bf0711302051m1bdcaf86kee336bbb8c93dfd5@mail.gmail.com> Message-ID: <330471bf0712011827w8a9fd53h826c26d141d89335@mail.gmail.com> Both sides will have to support sending packets through MNL. Your system should be able to drop both data packets and ACKs. -Lisa On Dec 1, 2007 6:26 PM, Merry Choi wrote: > Are we supposed to use MNL_sendto on the receiver side to ACK packets? Or > will send_to suffice, as with TestRecv? > > > From vern at cs.berkeley.edu Sun Dec 2 21:52:16 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 02 Dec 2007 21:52:16 -0800 Subject: [ee122] summary of networking concepts Message-ID: <200712030552.lB35qL3L028807@pork.ICSI.Berkeley.EDU> We've put together the appended list of networking concepts (with particular thanks to Lisa) as a complement to the list of acronyms we sent out earlier in the semester. While there are a whole-lotta'-concepts, hopefully most of them are readily familiar; and those that aren't would make good discussion topics to bring up for section this week, or to email to me for the course review this Friday. Vern 7-Layer (really 5-Layer) Model Access point Ack-Every-Other Ack-Splitting Adaptor Additive-Increase Multiplicative-Decrease Admission Control Application Gateway Autonomous System Best Effort Delivery Bridge Broadcast Buffer overflow Bytestream Cache Poisoning Caching Carrier Sense Certificate Checksum Circuit Switching Classful Addressing Classless Interdomain Routing Client-Server Clock Recovery Collision Avoidance Collision Detection Congestion Avoidance Congestion Control Connection-oriented Connectionless Content Distribution Network Count-to-Infinity Cryptographically Strong Hash Function Cut-through Data Plane vs. Control Plane Datagram Delayed Acknowledgment Demultiplexing Denial-of-Service DiffServ Distance Vector Routing Distributed Denial-of-Service Distributed Hash Table Domain Name Drop-Tail Queueing Duplicate ACK End-to-End Principle Explicit Congestion Notification Exponential Backoff Exposed Terminal Fair Queueing Fast Recovery Fast Retransmission Fate Sharing Firewall Flow Control Fragmentation Frame Gateway Head-of-Line Blocking Hidden Terminal Hierarchical naming Hub IP Address vs. MAC Address Initial Sequence Number Input-queued router IntServ Interdomain Intradomain Iterative query Layering Link State Routing Little's Theorem Local Area Network Longest-Prefix-Matching Forwarding Manchester Encoding Marshalling Max-Min Fairness Media Access Meta-data Middlebox Multiple Access Multiplexing Narrow Waist/Internet Hourglass Negative Acknowledgment Negative Caching Network Address Translation Network Neutrality Network Prefix Non-repudiation Output-queued router Overlay PMTU Discovery Packet-Switching Parity Peer-to-Peer Persistent HTTP Pipelined HTTP Point-to-Point Poisoned Reverse Port Preamble Private Address Public Key Infrastructure Public-Key Cryptography Quality of Service Random Early Detection Recursive Query Reliable Transfer Reverse Lookup (DNS) Revocation Router Scalability Segment Selective Acknowledgment Self-Clocking Sentinel Sequence Number Sliding Window Slotted Aloha Slow Start Socket Soft State Spanning Tree Stateless Operation Statistical Multiplexing Stop-and-Wait Store-and-Forward Subnet Mask Switch Symmetric Key Cryptography TCP Throughput Equation Three-Way Handshake Time-Sequence Plot Time-To-Live Token Bucket Tunneling Wide Area Network Window Scaling From huntingtonsurfca at gmail.com Mon Dec 3 23:31:32 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Mon, 3 Dec 2007 23:31:32 -0800 Subject: [ee122] HW4 P6.8 Message-ID: In this scenario, can one node send a message and the adjacent node recieve the message in the same time slot? Or does it have to sit silently, then recieve on the next time slot? Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071203/f1c65a04/attachment.html From jortiz at cs.berkeley.edu Tue Dec 4 11:24:35 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Tue, 4 Dec 2007 11:24:35 -0800 Subject: [ee122] HW4 P6.8 In-Reply-To: References: Message-ID: On Dec 3, 2007 11:31 PM, Richard Schmidt wrote: > In this scenario, can one node send a message and the adjacent node recieve > the message in the same time slot? Or does it have to sit silently, then > recieve on the next time slot? This would cause a collision because it implies that two nodes are sending to the same node at the same time. Jorge > > Thanks, > Rick > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From ericcheung at berkeley.edu Tue Dec 4 16:42:05 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Tue, 04 Dec 2007 16:42:05 -0800 Subject: [ee122] Given files to transfer? Message-ID: <4755F3DD.3040403@berkeley.edu> The spec says we are to test our protocol "transferring files of varying sizes (also provided to you)". However, these files don't seem to be online yet. Are we supposed to use our own files? Thanks - Eric From fowler at eecs.berkeley.edu Tue Dec 4 16:46:33 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 4 Dec 2007 16:46:33 -0800 Subject: [ee122] Given files to transfer? In-Reply-To: <4755F3DD.3040403@berkeley.edu> References: <4755F3DD.3040403@berkeley.edu> Message-ID: <330471bf0712041646i4bc7e660m20e4039aad0ffa11@mail.gmail.com> These will be online tonight and I'll send out a note when they're ready. -Lisa On Dec 4, 2007 4:42 PM, Eric Cheung wrote: > The spec says we are to test our protocol "transferring files of varying > sizes (also provided to you)". However, these files don't seem to be > online yet. Are we supposed to use our own files? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From ericcheung at berkeley.edu Tue Dec 4 17:22:22 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Tue, 04 Dec 2007 17:22:22 -0800 Subject: [ee122] Changes from initial design Message-ID: <4755FD4E.7040900@berkeley.edu> If some aspects of our implementation differ from our initial design, should we make note of this in the README? Thanks - Eric From fowler at eecs.berkeley.edu Tue Dec 4 17:31:02 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 4 Dec 2007 17:31:02 -0800 Subject: [ee122] Changes from initial design In-Reply-To: <4755FD4E.7040900@berkeley.edu> References: <4755FD4E.7040900@berkeley.edu> Message-ID: <330471bf0712041731q4c9c5041ld6844c0ad6445448@mail.gmail.com> You should describe the design that appears in your final submission, regardless of what you proposed in your initial design. -Lisa On Dec 4, 2007 5:22 PM, Eric Cheung wrote: > If some aspects of our implementation differ from our initial design, > should we make note of this in the README? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From phamductri at berkeley.edu Tue Dec 4 21:07:15 2007 From: phamductri at berkeley.edu (phamductri at berkeley.edu) Date: Tue, 4 Dec 2007 21:07:15 -0800 (PST) Subject: [ee122] Project 2 Question regarding MNL and the extra 2 bytes for the port. Message-ID: <59828.169.229.55.37.1196831235.squirrel@calmail.berkeley.edu> Hello. So I'm having an issue with MNL and grabbing the port of the sender to be able to send ACKs back to the receiver. I have stop and wait working just fine with different files for plain vanilla UDP. Now, for background info for my question.. The spec says that when we use MNLSendto() that the first two bytes that we get from recvfrom() will contain the port number of the sender, because the struct sockaddr_in populated from the recvfrom() call will refer to the port that the MNLDaemon is running on... r So far our project is abracted to have a packet class, and each packet can send and receive itself (more or less). I have statements in both send and recv (in the packet class) before the call to MNLSendto(), and after the call from recvfrom() respectively to print out the length of the buffer being sent/received. They report the exact same length. Why isn't the extra 2 bytes being padded to provide the port? Am I missing something? Also, in TestRecv.c, there is no conversion from network order to host order. Shouldn't that also be a concern? I'm referring to the newest version of MNL btw. Version B. Thanks very much for your time. Anthony Kilman From ericcheung at berkeley.edu Tue Dec 4 21:11:36 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Tue, 04 Dec 2007 21:11:36 -0800 Subject: [ee122] Project 2 Question regarding MNL and the extra 2 bytes for the port. In-Reply-To: <59828.169.229.55.37.1196831235.squirrel@calmail.berkeley.edu> References: <59828.169.229.55.37.1196831235.squirrel@calmail.berkeley.edu> Message-ID: <47563308.8060303@berkeley.edu> The two bytes for the port are added by TestSend.c; they aren't provided by MNL. You'll have to add the port number yourself in your packets. - Eric phamductri at berkeley.edu wrote: > Hello. So I'm having an issue with MNL and grabbing the port of the sender > to be able to send ACKs back to the receiver. I have stop and wait working > just fine with different files for plain vanilla UDP. > > Now, for background info for my question.. The spec says that when we use > MNLSendto() that the first two bytes that we get from recvfrom() will > contain the port number of the sender, because the struct sockaddr_in > populated from the recvfrom() call will refer to the port that the > MNLDaemon is running on... r > > So far our project is abracted to have a packet class, and each packet can > send and receive itself (more or less). I have statements in both send and > recv (in the packet class) before the call to MNLSendto(), and after the > call from recvfrom() respectively to print out the length of the buffer > being sent/received. They report the exact same length. > > Why isn't the extra 2 bytes being padded to provide the port? Am I missing > something? > > Also, in TestRecv.c, there is no conversion from network order to host > order. Shouldn't that also be a concern? > > I'm referring to the newest version of MNL btw. Version B. > > Thanks very much for your time. > > Anthony Kilman > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 From fowler at eecs.berkeley.edu Tue Dec 4 21:35:06 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 4 Dec 2007 21:35:06 -0800 Subject: [ee122] Project 2 Question regarding MNL and the extra 2 bytes for the port. In-Reply-To: <59828.169.229.55.37.1196831235.squirrel@calmail.berkeley.edu> References: <59828.169.229.55.37.1196831235.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0712042135y2cd2ad5fkf44b4b56463154e9@mail.gmail.com> On Dec 4, 2007 9:07 PM, wrote: > Hello. So I'm having an issue with MNL and grabbing the port of the sender > to be able to send ACKs back to the receiver. I have stop and wait working > just fine with different files for plain vanilla UDP. > > > Why isn't the extra 2 bytes being padded to provide the port? Am I missing > something? See my post to the list on Nov 25 "[ee122] gathering info with random unused ports (sin_port == 0)" You should be writing in those 2B yourself (see the code in TestSend.c line 137). It isn't done automatically. > Also, in TestRecv.c, there is no conversion from network order to host > order. Shouldn't that also be a concern? Good catch. Yes it is a concern if TestSend and TestRecv are compiled on different machines that represent uint16_t's differently. You should take care of this in your program. -Lisa From huntingtonsurfca at gmail.com Tue Dec 4 23:14:51 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Tue, 4 Dec 2007 23:14:51 -0800 Subject: [ee122] HW4 Q2 Message-ID: When trying to figure out throughput, we use the statistic that 0.5% of packets are dropped. Is it important to know the packet size for this, or should we give some theoretical result (since the statistic was based on packets and not data) where the throughput is described by packets per second? Or perhaps there's a totally different throughput equation we're supposed to utilize? :( Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071204/76af0041/attachment.html From vern at cs.berkeley.edu Tue Dec 4 23:40:08 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 04 Dec 2007 23:40:08 -0800 Subject: [ee122] HW4 Q2 In-Reply-To: (Tue, 04 Dec 2007 23:14:51 PST). Message-ID: <200712050740.lB57eDb9015748@pork.ICSI.Berkeley.EDU> > When trying to figure out throughput, we use the statistic that 0.5% of > packets are dropped. Is it important to know the packet size for this, or > should we give some theoretical result (since the statistic was based on > packets and not data) where the throughput is described by packets per > second? You can do this abstractly in terms of packets of size M bytes. Vern From vern at cs.berkeley.edu Wed Dec 5 00:02:29 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 05 Dec 2007 00:02:29 -0800 Subject: [ee122] extension for Project #2 Message-ID: <200712050802.lB582Yt3015957@pork.ICSI.Berkeley.EDU> I've extended the deadline for Project #2 until Monday Dec 10 at 11PM. (Please note that this for sure will be the only extension!) Vern From fowler at eecs.berkeley.edu Wed Dec 5 12:38:57 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 5 Dec 2007 12:38:57 -0800 Subject: [ee122] Given files to transfer? In-Reply-To: <330471bf0712041646i4bc7e660m20e4039aad0ffa11@mail.gmail.com> References: <4755F3DD.3040403@berkeley.edu> <330471bf0712041646i4bc7e660m20e4039aad0ffa11@mail.gmail.com> Message-ID: <330471bf0712051238j40bf050en320c7c3017a27f9c@mail.gmail.com> "tonight" was off by a few hours, but I reduced the number of tests that you had to do. The files are online now. YOU MUST READ THE README. Enjoy and let me know if you have any questions. Lisa On Dec 4, 2007 4:46 PM, Lisa Fowler wrote: > These will be online tonight and I'll send out a note when they're ready. > > -Lisa > > > On Dec 4, 2007 4:42 PM, Eric Cheung wrote: > > The spec says we are to test our protocol "transferring files of varying > > sizes (also provided to you)". However, these files don't seem to be > > online yet. Are we supposed to use our own files? > > > > Thanks > > - Eric > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > From fowler at eecs.berkeley.edu Wed Dec 5 12:46:02 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 5 Dec 2007 12:46:02 -0800 Subject: [ee122] Reminder - Check the FAQ Message-ID: <330471bf0712051246i44692b36pb8fd8d76333f43d@mail.gmail.com> http://www.eecs.berkeley.edu/~fowler/ee122/fa07/proj2faq.html -Lisa From joshua.hunt at berkeley.edu Wed Dec 5 14:49:36 2007 From: joshua.hunt at berkeley.edu (Josh Hunt) Date: Wed, 5 Dec 2007 14:49:36 -0800 Subject: [ee122] hw4 #5 Message-ID: <130a655e0712051449o544f7961mb1778582ff591955@mail.gmail.com> Are we allowed to use a tool, like tcptrace, to construct the time-sequence plots? If so, are there any suggested tools to use? Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071205/437ee56a/attachment.html From jortiz at cs.berkeley.edu Wed Dec 5 15:28:45 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Wed, 5 Dec 2007 15:28:45 -0800 Subject: [ee122] hw4 #5 In-Reply-To: <130a655e0712051449o544f7961mb1778582ff591955@mail.gmail.com> References: <130a655e0712051449o544f7961mb1778582ff591955@mail.gmail.com> Message-ID: I'm not familiar with that tool, but if you can get good plots from it, sure. I would simply use perl and gnuplot to get the plots done, but you can use whatever tool you feel most comfortable with. jorge On Dec 5, 2007 2:49 PM, Josh Hunt wrote: > Are we allowed to use a tool, like tcptrace, to construct the time-sequence > plots? If so, are there any suggested tools to use? > > Josh > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From joshua.hunt at berkeley.edu Wed Dec 5 15:32:03 2007 From: joshua.hunt at berkeley.edu (Josh Hunt) Date: Wed, 5 Dec 2007 15:32:03 -0800 Subject: [ee122] hw4 #5 In-Reply-To: References: <130a655e0712051449o544f7961mb1778582ff591955@mail.gmail.com> Message-ID: <130a655e0712051532v19e3509eq3a35613c1b62cccc@mail.gmail.com> How are the plots used in lecture made? On Dec 5, 2007 3:28 PM, Jorge Ortiz wrote: > I'm not familiar with that tool, but if you can get good plots from > it, sure. I would simply use perl and gnuplot to get the plots done, > but you can use whatever tool you feel most comfortable with. > > jorge > > > On Dec 5, 2007 2:49 PM, Josh Hunt wrote: > > Are we allowed to use a tool, like tcptrace, to construct the > time-sequence > > plots? If so, are there any suggested tools to use? > > > > Josh > > > > _______________________________________________ > > 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/20071205/6417c804/attachment.html From vern at cs.berkeley.edu Wed Dec 5 15:37:40 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 05 Dec 2007 15:37:40 -0800 Subject: [ee122] hw4 #5 In-Reply-To: <130a655e0712051532v19e3509eq3a35613c1b62cccc@mail.gmail.com> (Wed, 05 Dec 2007 15:32:03 PST). Message-ID: <200712052337.lB5Nbj7H001414@pork.ICSI.Berkeley.EDU> > How are the plots used in lecture made? I generated those plots in a custom environment that I'm not able to export to the instructional machines. Vern From amitmatani at berkeley.edu Wed Dec 5 21:01:34 2007 From: amitmatani at berkeley.edu (Amit Matani) Date: Wed, 5 Dec 2007 21:01:34 -0800 Subject: [ee122] flow control for project 2 Message-ID: <6b68cbc40712052101i16479a65oce2d0508b07d7718@mail.gmail.com> So I am kind of confused on how to properly implement flow control with the new changes to the spec. Since we are not using threading and passing control of the program to the my_recv function, we do not have a thread that fills a staging buffer which is then processed by a processor thread. All of this instead happens in order, we get a packet from the kernel using the recvfrom function. Then we ack if necessary and put the packet in its proper place. In this way we never will have a buffer that overflows because we process as we receive and we will never have to readjust the advertised window size. I have thought of ways to artificially reduce the window size if we receive too many out of order packets because we save those in a buffer, but I am not sure if I am missing something. So my question is, in what cases will we have to reduce the size of the advertised window for flow control? -Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071205/f1a39c35/attachment.html From vern at cs.berkeley.edu Wed Dec 5 21:38:53 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 05 Dec 2007 21:38:53 -0800 Subject: [ee122] flow control for project 2 In-Reply-To: <6b68cbc40712052101i16479a65oce2d0508b07d7718@mail.gmail.com> (Wed, 05 Dec 2007 21:01:34 PST). Message-ID: <200712060538.lB65cwvw005610@pork.ICSI.Berkeley.EDU> > Since we are not using threading and passing > control of the program to the my_recv function, we do not have a thread that > fills a staging buffer which is then processed by a processor thread. That's not quite what we framed. Rather, we framed that (1) you don't need to worry about concurrent connections, and (2) the *sender* application can give the entire file to the transport protocol for transmission as a single unit. However, your receiver should still be layered with one layer that deals with recovering the bytestream transmitted by the receiver, and another layer that consumes this bytestream at the application layer. Thus, your receiver-side application repeatedly calls my_recv() to consume more of the bytestream until my_recv() finally indicates the connection has been closed. (Accordingly, your thread of execution on the receiver side for the most part sits inside my_recv().) Because your transport layer at the receiver end needs to buffer up data and then return it to the my_recv() caller, it has to deal with a finite buffer size - and hence you need flow control. Vern From amitmatani at berkeley.edu Wed Dec 5 22:08:47 2007 From: amitmatani at berkeley.edu (Amit Matani) Date: Wed, 5 Dec 2007 22:08:47 -0800 Subject: [ee122] flow control for project 2 In-Reply-To: <200712060538.lB65cwvw005610@pork.ICSI.Berkeley.EDU> References: <6b68cbc40712052101i16479a65oce2d0508b07d7718@mail.gmail.com> <200712060538.lB65cwvw005610@pork.ICSI.Berkeley.EDU> Message-ID: <6b68cbc40712052208l51090434v5bf6d6c29f68bf80@mail.gmail.com> Oh okay. Still slightly confused, though. You said: "(Accordingly, your thread of execution on the receiver side for the most part sits inside my_recv().)" so I am assuming that we block on calls to my_recv and we only have one thread of execution. If this is the case, and for example a call to my_recv asks for say 500 bytes. Then the transport layer could pass the packets it receives directly to the buffer passed in by my_recv until it got 500 bytes and then pass control of execution back to the receiving program. Then the program could do the same thing for another 500 bytes etc. until the close of connection is reported. So should we have a seperate thread to fill a buffer and when calling my_recv only transfer what we have in the buffer over to the calling program? Thanks -Amit On Dec 5, 2007 9:38 PM, wrote: > > Since we are not using threading and passing > > control of the program to the my_recv function, we do not have a thread > that > > fills a staging buffer which is then processed by a processor thread. > > That's not quite what we framed. Rather, we framed that (1) you don't > need to worry about concurrent connections, and (2) the *sender* > application > can give the entire file to the transport protocol for transmission as > a single unit. However, your receiver should still be layered with one > layer that deals with recovering the bytestream transmitted by the > receiver, > and another layer that consumes this bytestream at the application layer. > > Thus, your receiver-side application repeatedly calls my_recv() to consume > more of the bytestream until my_recv() finally indicates the connection > has been closed. (Accordingly, your thread of execution on the receiver > side for the most part sits inside my_recv().) Because your transport > layer at the receiver end needs to buffer up data and then return it to > the my_recv() caller, it has to deal with a finite buffer size - and hence > > you need flow control. > > Vern > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071205/7dca2201/attachment.html From fowler at eecs.berkeley.edu Wed Dec 5 22:15:56 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 5 Dec 2007 22:15:56 -0800 Subject: [ee122] flow control for project 2 In-Reply-To: <6b68cbc40712052208l51090434v5bf6d6c29f68bf80@mail.gmail.com> References: <6b68cbc40712052101i16479a65oce2d0508b07d7718@mail.gmail.com> <200712060538.lB65cwvw005610@pork.ICSI.Berkeley.EDU> <6b68cbc40712052208l51090434v5bf6d6c29f68bf80@mail.gmail.com> Message-ID: <330471bf0712052215i547f3439v41067d498156a550@mail.gmail.com> for example, file_recv would have a method that essentially does "receive and save until disconnected". That method is at the app-level. In the "receive and save until disconnected" method, you loop on exactly that: receive and save, until disconnected, where "receive" in this case is a method that calls into your protocol's "receive x bytes" function. When entering the "receive x bytes", the size of x is the size of your receiver window. Your protocol will then receive and ACK up to x bytes, returning x bytes or less/something else if it was disconnected while trying to receive x bytes. It returns those bytes to the "receive and save until disconnected" method, which then saves, or returns upon disconnection. Behind the scenes: The incoming packets from the sender will queue in the UDP socket until "receive x bytes" is called again, and thus will not be ACKed until "receive and save until disconnected" loops again, and enters "receive x bytes". Does that help? Don't use threads. You don't need to. -Lisa On Dec 5, 2007 10:08 PM, Amit Matani wrote: > Oh okay. Still slightly confused, though. You said: "(Accordingly, your > thread of execution on the receiver side for the most part sits inside > my_recv().)" so I am assuming that we block on calls to my_recv and we only > have one thread of execution. If this is the case, and for example a call > to my_recv asks for say 500 bytes. Then the transport layer could pass the > packets it receives directly to the buffer passed in by my_recv until it got > 500 bytes and then pass control of execution back to the receiving program. > Then the program could do the same thing for another 500 bytes etc. until > the close of connection is reported. > > So should we have a seperate thread to fill a buffer and when calling > my_recv only transfer what we have in the buffer over to the calling > program? > > Thanks > -Amit > > > > On Dec 5, 2007 9:38 PM, < vern at cs.berkeley.edu> wrote: > > > > > Since we are not using threading and passing > > > control of the program to the my_recv function, we do not have a thread > that > > > fills a staging buffer which is then processed by a processor thread. > > > > That's not quite what we framed. Rather, we framed that (1) you don't > > need to worry about concurrent connections, and (2) the *sender* > application > > can give the entire file to the transport protocol for transmission as > > a single unit. However, your receiver should still be layered with one > > layer that deals with recovering the bytestream transmitted by the > receiver, > > and another layer that consumes this bytestream at the application layer. > > > > Thus, your receiver-side application repeatedly calls my_recv() to consume > > more of the bytestream until my_recv() finally indicates the connection > > has been closed. (Accordingly, your thread of execution on the receiver > > side for the most part sits inside my_recv().) Because your transport > > layer at the receiver end needs to buffer up data and then return it to > > the my_recv() caller, it has to deal with a finite buffer size - and hence > > you need flow control. > > > > Vern > > > > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From amitmatani at berkeley.edu Wed Dec 5 22:20:54 2007 From: amitmatani at berkeley.edu (Amit Matani) Date: Wed, 5 Dec 2007 22:20:54 -0800 Subject: [ee122] flow control for project 2 In-Reply-To: <330471bf0712052215i547f3439v41067d498156a550@mail.gmail.com> References: <6b68cbc40712052101i16479a65oce2d0508b07d7718@mail.gmail.com> <200712060538.lB65cwvw005610@pork.ICSI.Berkeley.EDU> <6b68cbc40712052208l51090434v5bf6d6c29f68bf80@mail.gmail.com> <330471bf0712052215i547f3439v41067d498156a550@mail.gmail.com> Message-ID: <6b68cbc40712052220t1c887a3cue075ec0174864d99@mail.gmail.com> I totally get that, but by doing it this way, how is the receiver's buffer ever going to get overwhelmed in such a way that I have to reduce the advertised window? Since I let UDP queue up the packets in the kernel, I have no idea what the strain is on the system and if UDP's queue is getting overloaded. I am just taking packets from the queue and putting them in the buffer passed in from my_recv. -Amit On Dec 5, 2007 10:15 PM, Lisa Fowler wrote: > for example, file_recv would have a method that essentially does > "receive and save until disconnected". That method is at the > app-level. > > In the "receive and save until disconnected" method, you loop on > exactly that: receive and save, until disconnected, where "receive" > in this case is a method that calls into your protocol's "receive x > bytes" function. > > When entering the "receive x bytes", the size of x is the size of your > receiver window. Your protocol will then receive and ACK up to x > bytes, returning x bytes or less/something else if it was disconnected > while trying to receive x bytes. It returns those bytes to the > "receive and save until disconnected" method, which then saves, or > returns upon disconnection. > > Behind the scenes: The incoming packets from the sender will queue in > the UDP socket until "receive x bytes" is called again, and thus will > not be ACKed until "receive and save until disconnected" loops again, > and enters "receive x bytes". > > Does that help? > > Don't use threads. You don't need to. > > -Lisa > > On Dec 5, 2007 10:08 PM, Amit Matani wrote: > > Oh okay. Still slightly confused, though. You said: "(Accordingly, > your > > thread of execution on the receiver side for the most part sits inside > > my_recv().)" so I am assuming that we block on calls to my_recv and we > only > > have one thread of execution. If this is the case, and for example a > call > > to my_recv asks for say 500 bytes. Then the transport layer could pass > the > > packets it receives directly to the buffer passed in by my_recv until it > got > > 500 bytes and then pass control of execution back to the receiving > program. > > Then the program could do the same thing for another 500 bytes etc. > until > > the close of connection is reported. > > > > So should we have a seperate thread to fill a buffer and when calling > > my_recv only transfer what we have in the buffer over to the calling > > program? > > > > Thanks > > -Amit > > > > > > > > On Dec 5, 2007 9:38 PM, < vern at cs.berkeley.edu> wrote: > > > > > > > Since we are not using threading and passing > > > > control of the program to the my_recv function, we do not have a > thread > > that > > > > fills a staging buffer which is then processed by a processor > thread. > > > > > > That's not quite what we framed. Rather, we framed that (1) you don't > > > need to worry about concurrent connections, and (2) the *sender* > > application > > > can give the entire file to the transport protocol for transmission as > > > a single unit. However, your receiver should still be layered with > one > > > layer that deals with recovering the bytestream transmitted by the > > receiver, > > > and another layer that consumes this bytestream at the application > layer. > > > > > > Thus, your receiver-side application repeatedly calls my_recv() to > consume > > > more of the bytestream until my_recv() finally indicates the > connection > > > has been closed. (Accordingly, your thread of execution on the > receiver > > > side for the most part sits inside my_recv().) Because your transport > > > layer at the receiver end needs to buffer up data and then return it > to > > > the my_recv() caller, it has to deal with a finite buffer size - and > hence > > > you need flow control. > > > > > > Vern > > > > > > > > > _______________________________________________ > > 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/20071205/de0d1967/attachment.html From vern at cs.berkeley.edu Wed Dec 5 22:22:38 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 05 Dec 2007 22:22:38 -0800 Subject: [ee122] flow control for project 2 In-Reply-To: <6b68cbc40712052220t1c887a3cue075ec0174864d99@mail.gmail.com> (Wed, 05 Dec 2007 22:20:54 PST). Message-ID: <200712060622.lB66Mhjl006141@pork.ICSI.Berkeley.EDU> > I am just taking packets from the queue and putting them in the buffer > passed in from my_recv. You should not put them in the buffer passed in to my_recv() unless the data is in-order. That is, your transport protocol needs to manage its own buffer (for possibly out-of-order arrivals) and only transfers the in-sequence bytestream to the buffer passed in. Vern From haley.ng at gmail.com Thu Dec 6 14:04:42 2007 From: haley.ng at gmail.com (Haley Nguyen) Date: Thu, 6 Dec 2007 14:04:42 -0800 Subject: [ee122] address family not supported by protocol family Message-ID: <95aaa0710712061404iab7d262u9162638a360ebd42@mail.gmail.com> Hi, I wrote a sender and a receiver. The sender sends then waits for receiver from the receiver. The receiver waits for receive then send back and ack. This is my socket call: socket(PF_INET, SOCK_DGRAM, 0) Then I set AF_INET for my sockaddr_in as the Beej suggested. I tested on localhost instead of ilinux3 The receiver runs on ilinux3 (the network is localhost), and a macbook, but it doesn't run on c199. The error returned was: Address family not supported by protocol family. The sender runs fine. I tried to use AF_INET for the socket() and AF_INET for sockaddr_in, the problem is the same. Can anyone tell me what the problem is? On Dec 5, 2007 10:22 PM, wrote: > > I am just taking packets from the queue and putting them in the buffer > > passed in from my_recv. > > You should not put them in the buffer passed in to my_recv() unless the > data is in-order. That is, your transport protocol needs to manage its > own buffer (for possibly out-of-order arrivals) and only transfers the > in-sequence bytestream to the buffer passed in. > > Vern > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > -- Haley Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071206/18a9b5b0/attachment.html From fowler at eecs.berkeley.edu Thu Dec 6 14:13:31 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 6 Dec 2007 14:13:31 -0800 Subject: [ee122] address family not supported by protocol family In-Reply-To: <95aaa0710712061404iab7d262u9162638a360ebd42@mail.gmail.com> References: <95aaa0710712061404iab7d262u9162638a360ebd42@mail.gmail.com> Message-ID: <330471bf0712061413w48c0e640m4705e9a429afe83b@mail.gmail.com> On Dec 6, 2007 2:04 PM, Haley Nguyen wrote: > Hi, > > I wrote a sender and a receiver. The sender sends then waits for receiver > from the receiver. The receiver waits for receive then send back and ack. > > This is my socket call: socket(PF_INET, SOCK_DGRAM, 0) > Then I set AF_INET for my sockaddr_in as the Beej suggested. > > I tested on localhost instead of ilinux3 > > The receiver runs on ilinux3 (the network is localhost), and a macbook, but > it doesn't run on c199. The error returned was: Address family not supported > by protocol family. > > The sender runs fine. > > I tried to use AF_INET for the socket() and AF_INET for sockaddr_in, the > problem is the same. > > Can anyone tell me what the problem is? That generally is indicative of the sockaddr struct not being passed properly to the syscall. Double check that you're correctly sending a struct sockaddr* and not something else. If you still have problems, you can send me a code snippet off-list. -Lisa From fowler at eecs.berkeley.edu Thu Dec 6 17:27:10 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 6 Dec 2007 17:27:10 -0800 Subject: [ee122] Lisa's availability this weekend Message-ID: <330471bf0712061727o256cfe71w7d22940f6e453675@mail.gmail.com> Dear hardworking students, I hope that you will be able to take full advantage of the Project 2 extension this weekend! I hope that you are speedily moving forward. Please note, I had planned on the project being due on Friday and thus allowed myself to be unavailable this weekend. I will not have ready access to email so I will not be able to provide prompt 8am-1am assistance like I've aimed for over the last couple weeks. I will do my best to respond to you within 24 hours, but please keep in mind that is a loose guarantee. Many of your questions will be answered in the proj2faq linked off my section page. I will hold extended office hours tomorrow, so please stop by if you can! Also, please be advised that Prof Paxson's availability this weekend is also limited, so I encourage you to ask your questions sooner rather than later! Thanks, Lisa From jkwang at berkeley.edu Thu Dec 6 18:44:23 2007 From: jkwang at berkeley.edu (Jeffrey Wang) Date: Thu, 6 Dec 2007 18:44:23 -0800 Subject: [ee122] UDP breaking up our packets Message-ID: <1C698743-D264-4CA7-8E31-537E756DE40D@berkeley.edu> Do we have to worry UDP breaking up our packet into across many different UDP packets, even if our protocol size limit doesn't exceed the UDP size limit? From fowler at eecs.berkeley.edu Thu Dec 6 18:54:57 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 6 Dec 2007 18:54:57 -0800 Subject: [ee122] UDP breaking up our packets In-Reply-To: <1C698743-D264-4CA7-8E31-537E756DE40D@berkeley.edu> References: <1C698743-D264-4CA7-8E31-537E756DE40D@berkeley.edu> Message-ID: <330471bf0712061854i1e8694f0o47b6c5472d82cde4@mail.gmail.com> As long as you stay within reasonable values as dictated by common MTUs, no. Keep your MSS resonable.... 1024B is a nice number :) And in fact, for testing, it needs to be 500-512B. -Lisa On Dec 6, 2007 6:44 PM, Jeffrey Wang wrote: > Do we have to worry UDP breaking up our packet into across many > different UDP packets, even if our protocol size limit doesn't exceed > the UDP size limit? > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Thu Dec 6 18:59:27 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Thu, 06 Dec 2007 18:59:27 -0800 Subject: [ee122] UDP breaking up our packets In-Reply-To: <1C698743-D264-4CA7-8E31-537E756DE40D@berkeley.edu> (Thu, 06 Dec 2007 18:44:23 PST). Message-ID: <200712070259.lB72xWcI028402@pork.ICSI.Berkeley.EDU> > Do we have to worry UDP breaking up our packet into across many > different UDP packets, even if our protocol size limit doesn't exceed > the UDP size limit? Along with Lisa's comments, another reason you don't have to worry about this is that you are implementing your protocol at user level; so even if you wind up sending very large UDP packets that get fragmented, they will only be delivered at the other side if all the fragments arrive and the kernel is able to reassemble thme. However, per Lisa's note, keep the MTU small so that this isn't an issue in any case. Vern From a_kilman at berkeley.edu Thu Dec 6 20:33:17 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Thu, 06 Dec 2007 20:33:17 -0800 Subject: [ee122] More questions for the project... Message-ID: <1197001997.12867.5.camel@zero.cool> Are we no longer required to support persistent connections? I assumed so since the spec was simplified, but I just wanted to make sure. Also, for the format of the README, can we turn in a PDF format? I wanted to include revamps to the original design, and exported LaTeX is much better looking than text. From fowler at eecs.berkeley.edu Thu Dec 6 20:46:48 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 6 Dec 2007 20:46:48 -0800 Subject: [ee122] More questions for the project... In-Reply-To: <1197001997.12867.5.camel@zero.cool> References: <1197001997.12867.5.camel@zero.cool> Message-ID: <330471bf0712062046g192e74c0u8629edb8ef0faf20@mail.gmail.com> On Dec 6, 2007 8:33 PM, Anthony Kilman wrote: > Are we no longer required to support persistent connections? I assumed > so since the spec was simplified, but I just wanted to make sure. See the Nov 20 email to the list with subject "my connect". > Also, for the format of the README, can we turn in a PDF format? I > wanted to include revamps to the original design, and exported LaTeX is > much better looking than text. I agree, however I'd prefer text so that I can read it directly on c199 without having to scp anything anywhere, but if you want to ALSO include a PDF revision to your original doc, you may, though it's not guaranteed that I'll read it. -Lisa From ericcheung at berkeley.edu Thu Dec 6 20:57:56 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Thu, 06 Dec 2007 20:57:56 -0800 Subject: [ee122] More questions for the project... In-Reply-To: <330471bf0712062046g192e74c0u8629edb8ef0faf20@mail.gmail.com> References: <1197001997.12867.5.camel@zero.cool> <330471bf0712062046g192e74c0u8629edb8ef0faf20@mail.gmail.com> Message-ID: <4758D2D4.4050205@berkeley.edu> Do we have to support persistent connections in terms of the http client and server? Thanks - Eric Lisa Fowler wrote: > On Dec 6, 2007 8:33 PM, Anthony Kilman wrote: >> Are we no longer required to support persistent connections? I assumed >> so since the spec was simplified, but I just wanted to make sure. > > See the Nov 20 email to the list with subject "my connect". > >> Also, for the format of the README, can we turn in a PDF format? I >> wanted to include revamps to the original design, and exported LaTeX is >> much better looking than text. > > I agree, however I'd prefer text so that I can read it directly on > c199 without having to scp anything anywhere, but if you want to ALSO > include a PDF revision to your original doc, you may, though it's not > guaranteed that I'll read it. > > -Lisa > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 From fowler at eecs.berkeley.edu Thu Dec 6 20:58:14 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 6 Dec 2007 20:58:14 -0800 Subject: [ee122] More questions for the project... In-Reply-To: <4758D2D4.4050205@berkeley.edu> References: <1197001997.12867.5.camel@zero.cool> <330471bf0712062046g192e74c0u8629edb8ef0faf20@mail.gmail.com> <4758D2D4.4050205@berkeley.edu> Message-ID: <330471bf0712062058g2edff1e8l9fc7d7ca49c9f0b3@mail.gmail.com> If you are building the optional extra credit HTTP server and client, no. -Lisa On Dec 6, 2007 8:57 PM, Eric Cheung wrote: > Do we have to support persistent connections in terms of the http client > and server? > > Thanks > - Eric > > > Lisa Fowler wrote: > > On Dec 6, 2007 8:33 PM, Anthony Kilman wrote: > >> Are we no longer required to support persistent connections? I assumed > >> so since the spec was simplified, but I just wanted to make sure. > > > > See the Nov 20 email to the list with subject "my connect". > > > >> Also, for the format of the README, can we turn in a PDF format? I > >> wanted to include revamps to the original design, and exported LaTeX is > >> much better looking than text. > > > > I agree, however I'd prefer text so that I can read it directly on > > c199 without having to scp anything anywhere, but if you want to ALSO > > include a PDF revision to your original doc, you may, though it's not > > guaranteed that I'll read it. > > > > -Lisa > > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From haley.ng at gmail.com Thu Dec 6 21:14:40 2007 From: haley.ng at gmail.com (Haley Nguyen) Date: Thu, 6 Dec 2007 21:14:40 -0800 Subject: [ee122] weird error, possibly stack corruption, need expert Message-ID: <95aaa0710712062114t7277954dla484549b8085ffd5@mail.gmail.com> This is a follow-up of another post with the title "address family not supported by protocol family." I couldn't quite solve the problem, but I discover another problem that may cause the problem in the above post. In a nutshell, I have a receiver program which waits to receive data from a sender program, and send an ack back. Because I couldn't solve the above problem, I reduced the program to an earlier version that worked and traced my code additions, and I got this: the simple receiver was working, then I added a declaration of a dummy variable in the main function, and the program stopped working. The error was thrown in another function whose caller's caller's is called by main. The error is thrown by a sendto(), and it was "Invalid argument". Since there was a post from the last project about "segfault madness" in which a segfault appeared after a declaration of a dummy variable, I followed the suggestions in that post. Therefore, I compiled my code with -g -Wall, and got a bunch of warnings about unused variables, and several print functions where I didn't print with the right flags (e.g. print void* with %x or %c, or something else with %ld, can this be the issue?). I ignored the warnings and ran the program with gdb. Since the error was invalid arguments, I checked the argument passed to sendto() namely the socket file descriptor, the sockaddr_in and the addrlen (didn't check the buffer and its size closely, but the buffer is not null, and the size is the right non-zero number). By printing these variables with gdb (and gdb on my computer let me see the content of the variable in a nice format with all the field names in front of the data), I can visually verify that the data passed to sendto() is the same data that was returned by the recvfrom() in main(). (Recall that the receiver receives something then send and ack.) At this point, I'm stuck because the arguments appear valid to me. Any clue about how to debug this thing or where the bug can be would be much appreciated. -- Haley Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071206/61fcfd61/attachment-0001.html From vern at cs.berkeley.edu Thu Dec 6 21:29:14 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Thu, 06 Dec 2007 21:29:14 -0800 Subject: [ee122] weird error, possibly stack corruption, need expert In-Reply-To: <95aaa0710712062114t7277954dla484549b8085ffd5@mail.gmail.com> (Thu, 06 Dec 2007 21:14:40 PST). Message-ID: <200712070529.lB75TJKV029811@pork.ICSI.Berkeley.EDU> > ... the simple receiver was working, then I > added a declaration of a dummy variable in the main function, and the > program stopped working. That symptom almost always means that you either have a bug in which you're reading uninitialized memory off of the stack (and the contents of that memory have changed now that the stack layout has changed) or you are overwriting a buffer on the stack (and now the exact effects of that have altered since, again, the stack layout has changed). > -Wall, and got a bunch of warnings about unused variables, and several print > functions where I didn't print with the right flags (e.g. print void* with > %x or %c, or something else with %ld, can this be the issue?). *Do* fix those. The particular ones you mention won't have caused this problem, but other similar warnings certainly can. > I checked the argument passed to sendto() namely the > socket file descriptor, the sockaddr_in and the addrlen (didn't check the > buffer and its size closely, but the buffer is not null, and the size is the > right non-zero number). By printing these variables with gdb (and gdb on my > computer let me see the content of the variable in a nice format with all > the field names in front of the data), I can visually verify that the data > passed to sendto() is the same data that was returned by the recvfrom() in > main(). That may simply mean that the you're indeed reading the same area in memory that your program overwrote earlier - there still could be a bug in your sizing of variables (e.g., using sockaddr when you need sockaddr_in, or having a pointer that you haven't initialized but happens to point somewhere into the stack). > Any clue about how to debug this thing or where the bug can be would be much > appreciated. Some first steps are to fix the warnings and carefully inspect your initialization of variables, especially those that are used to return data from library or system calls (such as strcpy(), recv() or getsockname()). Vern From sylvainla at berkeley.edu Thu Dec 6 23:08:39 2007 From: sylvainla at berkeley.edu (Sylvain La) Date: Thu, 6 Dec 2007 23:08:39 -0800 Subject: [ee122] Fast recovery homework question Message-ID: <22fb9d800712062308n20a3aa1eo5a19bd66b9ca9ad4@mail.gmail.com> > > > Just to clarify, what is fast recovery? Online definitions mention inflating the CWND size, but this is somewhat confusing. I am interpreting this to mean that on the fourth DUP and beyond, the sender would continue sending packets despite not having received any ACKs for new data. Thanks, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071206/ea9419e9/attachment.html From vern at cs.berkeley.edu Thu Dec 6 23:23:13 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Thu, 06 Dec 2007 23:23:13 -0800 Subject: [ee122] Fast recovery homework question In-Reply-To: <22fb9d800712062308n20a3aa1eo5a19bd66b9ca9ad4@mail.gmail.com> (Thu, 06 Dec 2007 23:08:39 PST). Message-ID: <200712070723.lB77NIBu031202@pork.ICSI.Berkeley.EDU> > Just to clarify, what is fast recovery? Online definitions mention inflating > the CWND size, but this is somewhat confusing. I am interpreting this > to mean that on the fourth DUP and beyond, the sender would continue > sending packets despite not having received any ACKs > for new data. That's the flavor of it. In particular, additional dups eventually result in transmission of additional packets. The actual mechanism used is a bit tricky - see RFC 2581 if you want details. For our purposes, the key things to know about it are: (1) It starts off the same as Fast Retransmit (2) It can send additional packets if enough dups arrive (3) It implements true AIMD - when the lost packet has been successfully retransmitted, the sender continues with CWND = half the value it had prior to loss (whereas Fast Retransmit enters Slow Start at this point) (4) Like Fast Retransmit, if more than one packet is lost in a single flight, it will in general wind up recovering via a Timeout followed by Slow Start (unless the TCP also uses SACK) - Vern From ericcheung at berkeley.edu Fri Dec 7 01:18:46 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Fri, 07 Dec 2007 01:18:46 -0800 Subject: [ee122] Proj 2 file transfer output Message-ID: <47590FF6.6090304@berkeley.edu> Is all we need to do is submit the .csv files or do we need to interpret them in our README file (e.g. point out where it's timing out, fast retransmitting, etc.)? Also, mnl_conf_4a_r.txt specifies to drop some packets that our protocol never sends because file4.txt is only 10000 bytes (i.e. it never sends over 40 packets). Was this the intended behavior of the config file? Thanks - Eric From fowler at eecs.berkeley.edu Fri Dec 7 01:26:54 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 7 Dec 2007 01:26:54 -0800 Subject: [ee122] Proj 2 file transfer output In-Reply-To: <47590FF6.6090304@berkeley.edu> References: <47590FF6.6090304@berkeley.edu> Message-ID: <330471bf0712070126p769c88a6h15f4801b367bc2a6@mail.gmail.com> On Dec 7, 2007 1:18 AM, Eric Cheung wrote: > Is all we need to do is submit the .csv files or do we need to interpret > them in our README file (e.g. point out where it's timing out, fast > retransmitting, etc.)? If you think that would help my interpretation, go for it. Otherwise, it's not necessary. > Also, mnl_conf_4a_r.txt specifies to drop some packets that our protocol > never sends because file4.txt is only 10000 bytes (i.e. it never sends > over 40 packets). Was this the intended behavior of the config file? Ah, sorry, I'll get that fixed. 4a should be paired with a larger file. -Lisa From fowler at eecs.berkeley.edu Fri Dec 7 01:32:05 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 7 Dec 2007 01:32:05 -0800 Subject: [ee122] Proj 2 file transfer output In-Reply-To: <330471bf0712070126p769c88a6h15f4801b367bc2a6@mail.gmail.com> References: <47590FF6.6090304@berkeley.edu> <330471bf0712070126p769c88a6h15f4801b367bc2a6@mail.gmail.com> Message-ID: <330471bf0712070132i355f8878s3c02af38239260d2@mail.gmail.com> > > Also, mnl_conf_4a_r.txt specifies to drop some packets that our protocol > > never sends because file4.txt is only 10000 bytes (i.e. it never sends > > over 40 packets). Was this the intended behavior of the config file? > > Ah, sorry, I'll get that fixed. 4a should be paired with a larger file. The changes should be live soon, but until then, the changes were: Rename mnl_conf_4a* to mnl_conf_3b*, pair mnl_conf_3b* with file3.ppt Move mnl_conf_4c* to mnl_conf_4a* Update IMPORTANT.README to reflect the above -Lisa From vern at cs.berkeley.edu Fri Dec 7 07:36:11 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 07 Dec 2007 07:36:11 -0800 Subject: [ee122] Proj 2 file transfer output In-Reply-To: <330471bf0712070132i355f8878s3c02af38239260d2@mail.gmail.com> (Fri, 07 Dec 2007 01:32:05 PST). Message-ID: <200712071536.lB7FaGBZ008004@pork.ICSI.Berkeley.EDU> > The changes should be live soon, but until then, the changes were: It's now live. Vern From vern at cs.berkeley.edu Fri Dec 7 11:11:48 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 07 Dec 2007 11:11:48 -0800 Subject: [ee122] updated acronym & concept lists Message-ID: <200712071911.lB7JBrAt011363@pork.ICSI.Berkeley.EDU> I've added a few more acronyms and concepts to the lists. Here are the differences - next two messages are the updated versions of the complete lists. Vern Index: Acronyms.txt =================================================================== --- Acronyms.txt (revision 287) +++ Acronyms.txt (revision 291) @@ -1,17 +1,21 @@ If no pronunciation is given, then it is each letter individually, e.g., TCP = "tee-sea-pea". -Acronyms we'll cover up to the MidTerm +Acronyms we'll cover up to the MidTerm (and some covered later) -------------------------------------- ACK pronounced as spelled +AES ARP pronounced as spelled ARQ +CA CDN CIDR pronounced "cider" CNAME pronounced "See-name" CRC CSMA CSMA/CD +CTS sometimes pronounced as its full name, "Clear To Send" +DES pronounced either "dee-ee-ess" or "dez" DF This is the only IPv4 header bit that people commonly talked about. DNS FDM not in fact widely used @@ -27,7 +31,9 @@ IPv6 ISP LAN pronounced as spelled; local area network +MACA pronounced "macaw" MAC pronounced as spelled; often combined to "MAC address" +MD5 MIME pronounced as spelled MTU MX @@ -41,14 +47,19 @@ RFC RIR RR +RSA +RTS sometimes pronounced as its full name, "Request To Send" RTT SACK pronounced as spelled +SHA-1 pronounced "shah-one" SMTP SONET pronounced "sonnet" +SSL TCP TDM TDMA TLD +TLS TOS pronounced "toss" TTL UDP Index: Concepts.txt =================================================================== --- Concepts.txt (revision 287) +++ Concepts.txt (revision 291) @@ -6,8 +6,13 @@ Additive-Increase Multiplicative-Decrease Admission Control Application Gateway +Authentication +Authorization Autonomous System +Availability Best Effort Delivery +Bot +Botnet Bridge Broadcast Buffer overflow @@ -15,7 +20,7 @@ Cache Poisoning Caching Carrier Sense -Certificate +Certificate (sometimes abbreviated as "cert") Checksum Circuit Switching Classful Addressing @@ -24,11 +29,13 @@ Clock Recovery Collision Avoidance Collision Detection +Confidentiality Congestion Avoidance Congestion Control Connection-oriented Connectionless Content Distribution Network +Cookie Count-to-Infinity Cryptographically Strong Hash Function Cut-through @@ -65,6 +72,7 @@ Initial Sequence Number Input-queued router IntServ +Integrity Interdomain Intradomain Iterative query @@ -88,8 +96,10 @@ Network Neutrality Network Prefix Non-repudiation +Nonce Output-queued router Overlay +Overprovision PMTU Discovery Packet-Switching Parity @@ -116,6 +126,7 @@ Self-Clocking Sentinel Sequence Number +Session Key Sliding Window Slotted Aloha Slow Start @@ -137,3 +148,4 @@ Tunneling Wide Area Network Window Scaling +Worm From vern at cs.berkeley.edu Fri Dec 7 11:12:01 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 07 Dec 2007 11:12:01 -0800 Subject: [ee122] updated Acronym list Message-ID: <200712071912.lB7JC6iQ011374@pork.ICSI.Berkeley.EDU> If no pronunciation is given, then it is each letter individually, e.g., TCP = "tee-sea-pea". Acronyms we'll cover up to the MidTerm (and some covered later) -------------------------------------- ACK pronounced as spelled AES ARP pronounced as spelled ARQ CA CDN CIDR pronounced "cider" CNAME pronounced "See-name" CRC CSMA CSMA/CD CTS sometimes pronounced as its full name, "Clear To Send" DES pronounced either "dee-ee-ess" or "dez" 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 MACA pronounced "macaw" MAC pronounced as spelled; often combined to "MAC address" MD5 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 RSA RTS sometimes pronounced as its full name, "Request To Send" RTT SACK pronounced as spelled SHA-1 pronounced "shah-one" SMTP SONET pronounced "sonnet" SSL TCP TDM TDMA TLD TLS 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" 802.3 pronounced "eight-oh-two-dot-three"; the IEEE standardization of Ethernet Acronyms we'll cover after the Mid-Term --------------------------------------- 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" 802.11 pronounced "eight-oh-two-dot-eleven"; the IEEE family of wireless protocol standards such as "Wavelan" 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 ADDL pronounced as spelled; the DNS "additional" RRs ATM 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 WEP pronounced as spelled; Wired Equivalent Privacy or Wireless Encryption Protocol WiMAX pronounced "why-max"; Worldwide Interoperability for Microwave Access WPA Wi-Fi Protected Access From vern at cs.berkeley.edu Fri Dec 7 11:12:11 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 07 Dec 2007 11:12:11 -0800 Subject: [ee122] updated Concepts list Message-ID: <200712071912.lB7JCGJ7011379@pork.ICSI.Berkeley.EDU> 7-Layer (really 5-Layer) Model Access point Ack-Every-Other Ack-Splitting Adaptor Additive-Increase Multiplicative-Decrease Admission Control Application Gateway Authentication Authorization Autonomous System Availability Best Effort Delivery Bot Botnet Bridge Broadcast Buffer overflow Bytestream Cache Poisoning Caching Carrier Sense Certificate (sometimes abbreviated as "cert") Checksum Circuit Switching Classful Addressing Classless Interdomain Routing Client-Server Clock Recovery Collision Avoidance Collision Detection Confidentiality Congestion Avoidance Congestion Control Connection-oriented Connectionless Content Distribution Network Cookie Count-to-Infinity Cryptographically Strong Hash Function Cut-through Data Plane vs. Control Plane Datagram Delayed Acknowledgment Demultiplexing Denial-of-Service DiffServ Distance Vector Routing Distributed Denial-of-Service Distributed Hash Table Domain Name Drop-Tail Queueing Duplicate ACK End-to-End Principle Explicit Congestion Notification Exponential Backoff Exposed Terminal Fair Queueing Fast Recovery Fast Retransmission Fate Sharing Firewall Flow Control Fragmentation Frame Gateway Head-of-Line Blocking Hidden Terminal Hierarchical naming Hub IP Address vs. MAC Address Initial Sequence Number Input-queued router IntServ Integrity Interdomain Intradomain Iterative query Layering Link State Routing Little's Theorem Local Area Network Longest-Prefix-Matching Forwarding Manchester Encoding Marshalling Max-Min Fairness Media Access Meta-data Middlebox Multiple Access Multiplexing Narrow Waist/Internet Hourglass Negative Acknowledgment Negative Caching Network Address Translation Network Neutrality Network Prefix Non-repudiation Nonce Output-queued router Overlay Overprovision PMTU Discovery Packet-Switching Parity Peer-to-Peer Persistent HTTP Pipelined HTTP Point-to-Point Poisoned Reverse Port Preamble Private Address Public Key Infrastructure Public-Key Cryptography Quality of Service Random Early Detection Recursive Query Reliable Transfer Reverse Lookup (DNS) Revocation Router Scalability Segment Selective Acknowledgment Self-Clocking Sentinel Sequence Number Session Key Sliding Window Slotted Aloha Slow Start Socket Soft State Spanning Tree Stateless Operation Statistical Multiplexing Stop-and-Wait Store-and-Forward Subnet Mask Switch Symmetric Key Cryptography TCP Throughput Equation Three-Way Handshake Time-Sequence Plot Time-To-Live Token Bucket Tunneling Wide Area Network Window Scaling Worm From a_kilman at berkeley.edu Fri Dec 7 14:15:38 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Fri, 07 Dec 2007 14:15:38 -0800 Subject: [ee122] test files Message-ID: <1197065738.29502.1.camel@zero.cool> file2.flv is just awesome From vern at cs.berkeley.edu Fri Dec 7 17:58:04 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 07 Dec 2007 17:58:04 -0800 Subject: [ee122] office hours next week Message-ID: <200712080158.lB81w9kk017055@pork.ICSI.Berkeley.EDU> Here's a summary: Vern: by appointment. I'm hoping to have my usual Fri 3-4 but won't know until shortly beforehand. Also, let me know if you'd like an appointment on Mon Dec 17. Lisa: Fri 10-11 (usual) and by appointment Jorge: Mon 12-1 Daniel: Wed 12-1 (usual) and by appointment - Vern From drewlustro at gmail.com Sat Dec 8 00:50:10 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Sat, 8 Dec 2007 00:50:10 -0800 Subject: [ee122] proto_parser libraries for home compiling?? Message-ID: <06EBF809-2A13-4077-BE73-C8DCA4B8E589@gmail.com> I couldnt compile the sample proto_parser obtained off the /projects/ directory.. then I noticed that the makefile includes the lib/include directories at /usr/sww/lib and /usr/sww/include What can I do to try to compile and extend the proto_parser at home to work with our protocol? g++ reports: g++ -O0 -g3 -Wall -c -fmessage-length=0 -osrc/proto-parser.o ../src/ proto-parser.cpp g++ -o proto-parser src/proto-parser.o Undefined symbols: "_pcap_next", referenced from: _main in proto-parser.o "_pcap_open_offline", referenced from: _main in proto-parser.o ld: symbol(s) not found collect2: ld returned 1 exit status Build error occurred, build is stopped Clearly I do not have the pcap libs. I tried downloading the whole directory (/usr/sww/include and /usr/sww/lib), but then got permission errors and gave up. Thanks Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071208/6da04eea/attachment.html From fowler at eecs.berkeley.edu Sat Dec 8 01:03:05 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sat, 8 Dec 2007 01:03:05 -0800 Subject: [ee122] proto_parser libraries for home compiling?? In-Reply-To: <06EBF809-2A13-4077-BE73-C8DCA4B8E589@gmail.com> References: <06EBF809-2A13-4077-BE73-C8DCA4B8E589@gmail.com> Message-ID: <330471bf0712080103n7cb848a3gce648b35bff7af96@mail.gmail.com> You need to install libpcap, and how you would do so depends on your system. If you're using cygwin, you should download and install winpcap, but your mileage may vary. It will likely be much more worth your time to handle this on c199... -Lisa On Dec 8, 2007 12:50 AM, Drew Lustro wrote: > I couldnt compile the sample proto_parser obtained off the /projects/ > directory.. then I noticed that the makefile includes the lib/include > directories at /usr/sww/lib and /usr/sww/include > > What can I do to try to compile and extend the proto_parser at home to work > with our protocol? g++ reports: > > > g++ -O0 -g3 -Wall -c -fmessage-length=0 -osrc/proto-parser.o > ../src/proto-parser.cpp > g++ -o proto-parser src/proto-parser.o > Undefined symbols: > "_pcap_next", referenced from: > _main in proto-parser.o > "_pcap_open_offline", referenced from: > _main in proto-parser.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > Build error occurred, build is stopped > > Clearly I do not have the pcap libs. I tried downloading the whole directory > (/usr/sww/include and /usr/sww/lib), but then got permission errors and gave > up. > > Thanks > > Drew > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From vern at cs.berkeley.edu Sat Dec 8 09:42:46 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sat, 08 Dec 2007 09:42:46 -0800 Subject: [ee122] proto_parser libraries for home compiling?? In-Reply-To: <06EBF809-2A13-4077-BE73-C8DCA4B8E589@gmail.com> (Sat, 08 Dec 2007 00:50:10 PST). Message-ID: <200712081742.lB8HgpGx029836@pork.ICSI.Berkeley.EDU> The basic source for libpcap is www.tcpdump.org. Winpcap for Windows is at www.winpcap.org. Vern From drewlustro at gmail.com Sat Dec 8 17:56:29 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Sat, 8 Dec 2007 17:56:29 -0800 Subject: [ee122] Example / Format of CSV file? Message-ID: <756F948A-84FB-4285-B59B-9166A6542953@gmail.com> I understand that CSV = comma separated value file... but how exactly would the TAs like it formatted? Like which data fields as the header / what labels? Or easier: could we just get an example of an OK .csv file in the project directory (for just UDP and then let us know what extra data you'd like there)? Thanks Drew From sylvainla at berkeley.edu Sat Dec 8 18:36:45 2007 From: sylvainla at berkeley.edu (Sylvain La) Date: Sat, 8 Dec 2007 18:36:45 -0800 Subject: [ee122] Strange Packets from Strange Sources? Message-ID: <22fb9d800712081836j715788a0t8877e4341b9499d0@mail.gmail.com> For the project, how much "other traffic" do we have to deal with. That is, while sender and receiver are talking: -Will there be other clients sending to the same UDP ports they are using? -Will there be packets from the correct IP/Port pair, but are complete nonsense (spoofed)? Thanks, sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071208/be851d93/attachment.html From fowler at eecs.berkeley.edu Sat Dec 8 20:25:34 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sat, 8 Dec 2007 20:25:34 -0800 Subject: [ee122] Example / Format of CSV file? In-Reply-To: <756F948A-84FB-4285-B59B-9166A6542953@gmail.com> References: <756F948A-84FB-4285-B59B-9166A6542953@gmail.com> Message-ID: <330471bf0712082025j1c151314m49099ed191dc8363@mail.gmail.com> Everyone has different headers and protocol features, so I am not looking for anything *specific*. However, that being said, you MUST include enough information such that I will be able to understand your congestion control mechanism, by, for example, taking your data and generating plots like you did in HW4. Clearly since everyone has a different design, I can't ask for standardized column headers, but please do make it easy and obvious for me. So, a barebones example could be: Timestamp,Seq/Ack Num,Ack 1193858975.849670,234678934,0 1193858975.863554,234678950,1 1193858976.366596,234678950,0 -Lisa On Dec 8, 2007 5:56 PM, Drew Lustro wrote: > I understand that CSV = comma separated value file... but how exactly > would the TAs like it formatted? Like which data fields as the > header / what labels? > > Or easier: could we just get an example of an OK .csv file in the > project directory (for just UDP and then let us know what extra data > you'd like there)? > > Thanks > > Drew > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From fowler at eecs.berkeley.edu Sat Dec 8 20:26:31 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sat, 8 Dec 2007 20:26:31 -0800 Subject: [ee122] Strange Packets from Strange Sources? In-Reply-To: <22fb9d800712081836j715788a0t8877e4341b9499d0@mail.gmail.com> References: <22fb9d800712081836j715788a0t8877e4341b9499d0@mail.gmail.com> Message-ID: <330471bf0712082026y45cb7ae8ie1eb81fa61b5721b@mail.gmail.com> On Dec 8, 2007 6:36 PM, Sylvain La wrote: > For the project, how much "other traffic" do we have to deal with. > That is, while sender and receiver are talking: > -Will there be other clients sending to the same UDP ports they are using? > -Will there be packets from the correct IP/Port pair, but are complete > nonsense (spoofed)? Yes, you do need to handle those cases. -Lisa From haley.ng at gmail.com Sat Dec 8 20:36:27 2007 From: haley.ng at gmail.com (Haley Nguyen) Date: Sat, 8 Dec 2007 20:36:27 -0800 Subject: [ee122] MNL doesn't transmit Ack Message-ID: <95aaa0710712082036l4e3d1feeue9b05cfa718309f8@mail.gmail.com> I have a receiver and a sender running. The sender send a packet to the receiver, and the receiver sends an Ack back. My program runs ok with UDP sendto(), but after I change it to use MNL_sendto(), only the receiver receive the packet from sender, but the sender doesn't get the ack. In the MNLDaemon, it shows that the ack was transmitted just like the data, but the receiver hung waiting for the ack. I don't know what I do wrong. -- Haley Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071208/12f09707/attachment.html From merry_c at berkeley.edu Sat Dec 8 20:56:01 2007 From: merry_c at berkeley.edu (Merry Choi) Date: Sat, 8 Dec 2007 20:56:01 -0800 Subject: [ee122] csv file Message-ID: What's the difference between cc_send and cc_recv? 1. Are we supposed to capture packets coming in on the sender/receiver side? 2. or capture packets going out of the sender/receiver side? 3. Or are we supposed to filter just the packets coming into the sender for cc_send, and filter just the packets coming into the receiver for cc_recv? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071208/002681e5/attachment.html From drewlustro at gmail.com Sat Dec 8 21:14:27 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Sat, 8 Dec 2007 21:14:27 -0800 Subject: [ee122] MNLDaemon fails to compile on c199 Message-ID: library path and stuff is set... any help? c199 [19] ~/proj2/MNL_src_0_1b > c199 [19] ~/proj2/MNL_src_0_1b > set LD_LIBRARY_PATH=/home/ff/ee122/ lib:/usr/sww/lib/ c199 [20] ~/proj2/MNL_src_0_1b > echo $LD_LIBRARY_PATH /home/ff/ee122/lib:/usr/sww/lib/ c199 [21] ~/proj2/MNL_src_0_1b > gmake clean rm *.o MNLDaemon MNLDaemon: No such file or directory gmake: *** [clean] Error 2 c199 [22] ~/proj2/MNL_src_0_1b > gmake g++ -g -c -o TimeFns.o TimeFns.cpp g++ -g -c -o PacketDropper.o PacketDropper.cpp g++ -g -c -o SpecificPacketDropper.o SpecificPacketDropper.cpp g++ -g -c -o PeriodicPacketDropper.o PeriodicPacketDropper.cpp g++ -g -c -o ProbabilisticPacketDropper.o ProbabilisticPacketDropper.cpp g++ -g -c -o SendQueue.o SendQueue.cpp g++ -g -c -o PacketBuf.o PacketBuf.cpp g++ -g -c -o PacketBufComparator.o PacketBufComparator.cpp g++ -g -c -o MNLDaemon.o MNLDaemon.cpp g++ -g -o MNLDaemon main.cpp TimeFns.o PacketDropper.o SpecificPacketDropper.o PeriodicPacketDropper.o ProbabilisticPacketDropper.o SendQueue.o PacketBuf.o PacketBufComparator.o MNLDaemon.o Undefined first referenced symbol in file __xnet_sendto SendQueue.o __xnet_socket SendQueue.o getsockname MNLDaemon.o setsockopt SendQueue.o recvfrom MNLDaemon.o inet_ntoa SendQueue.o __xnet_bind SendQueue.o ld: fatal: Symbol referencing errors. No output written to MNLDaemon collect2: ld returned 1 exit status gmake: *** [MNLDaemon] Error 1 c199 [23] ~/proj2/MNL_src_0_1b > From apolloellis at berkeley.edu Sat Dec 8 21:28:07 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Sat, 8 Dec 2007 21:28:07 -0800 (PST) Subject: [ee122] tracing Message-ID: <49554.128.32.35.231.1197178087.squirrel@calmail.berkeley.edu> hi all i am having a problem using tshark or tcpdump to capture udp on a specified port. i run the mnldaemon then i run testrecv 6000 and either tshark or tcpdump with a filter like "host c199.eecs.berkeley.edu and udp port 6000" then i run testsend 6000. we have tried many filter variations with both tshark and tcpdump but get no captures. please anyone i would like to move on. i need to debug the actual project someday. Apollo From vern at cs.berkeley.edu Sat Dec 8 21:29:53 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sat, 08 Dec 2007 21:29:53 -0800 Subject: [ee122] MNLDaemon fails to compile on c199 In-Reply-To: (Sat, 08 Dec 2007 21:14:27 PST). Message-ID: <200712090529.lB95TwHi005536@pork.ICSI.Berkeley.EDU> > library path and stuff is set... any help? It works fine for me, per the appended. This is from freshly unpacking it. Vern c199 9 % make -f Makefile.MNL gcc -g -c -o TestSend.o TestSend.c gcc -g -c -o MNLClient.o MNLClient.c gcc -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o gcc -g -c -o TestRecv.o TestRecv.c gcc -g -lsocket -lnsl -lresolv -o TestRecv TestRecv.o c199 10 % ls DATE.txt MNLClient.o README.txt TestRecv.o TestSend.o MNLClient.c MNL_src_0_1b/ TestRecv* TestSend* samplecfg/ MNLClient.h Makefile.MNL TestRecv.c TestSend.c c199 11 % cd MNL_src_0_1b/ c199 12 % make g++ -g -c -o TimeFns.o TimeFns.cpp g++ -g -c -o PacketDropper.o PacketDropper.cpp g++ -g -c -o SpecificPacketDropper.o SpecificPacketDropper.cpp g++ -g -c -o PeriodicPacketDropper.o PeriodicPacketDropper.cpp g++ -g -c -o ProbabilisticPacketDropper.o ProbabilisticPacketDropper.cpp g++ -g -c -o SendQueue.o SendQueue.cpp g++ -g -c -o PacketBuf.o PacketBuf.cpp g++ -g -c -o PacketBufComparator.o PacketBufComparator.cpp g++ -g -c -o MNLDaemon.o MNLDaemon.cpp g++ -g -lsocket -lnsl -lresolv -o MNLDaemon main.cpp TimeFns.o PacketDropper.o SpecificPacketDropper.o PeriodicPacketDropper.o ProbabilisticPacketDropper.o SendQueue.o PacketBuf.o PacketBufComparator.o MNLDaemon.o g++ -g -g -c -o TestSend.o TestSend.c g++ -g -g -c -o MNLClient.o MNLClient.c g++ -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o g++ -g -g -c -o TestRecv.o TestRecv.c g++ -g -lsocket -lnsl -lresolv -o TestRecv TestRecv.o From haley.ng at gmail.com Sat Dec 8 21:43:35 2007 From: haley.ng at gmail.com (Haley Nguyen) Date: Sat, 8 Dec 2007 21:43:35 -0800 Subject: [ee122] MNL doesn't transmit Ack In-Reply-To: <95aaa0710712082036l4e3d1feeue9b05cfa718309f8@mail.gmail.com> References: <95aaa0710712082036l4e3d1feeue9b05cfa718309f8@mail.gmail.com> Message-ID: <95aaa0710712082143jf232a0anc56d019fd0daa47e@mail.gmail.com> I use MNL_sendto() to send the ack, but I noticed TestRecv use sendto() to send the reply. Is there is reason that TestRecv use sendto() and not MNL_sendto()? On Dec 8, 2007 8:36 PM, Haley Nguyen wrote: > I have a receiver and a sender running. The sender send a packet to the > receiver, and the receiver sends an Ack back. > > My program runs ok with UDP sendto(), but after I change it to use > MNL_sendto(), only the receiver receive the packet from sender, but the > sender doesn't get the ack. In the MNLDaemon, it shows that the ack was > transmitted just like the data, but the receiver hung waiting for the ack. I > don't know what I do wrong. > > -- > Haley Nguyen -- Haley Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071208/d42fe4d3/attachment.html From drewlustro at gmail.com Sat Dec 8 21:44:40 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Sat, 8 Dec 2007 21:44:40 -0800 Subject: [ee122] MNLDaemon fails to compile on c199 In-Reply-To: <200712090529.lB95TwHi005536@pork.ICSI.Berkeley.EDU> References: <200712090529.lB95TwHi005536@pork.ICSI.Berkeley.EDU> Message-ID: <99972989-473B-4175-9332-62F6E6EA3891@gmail.com> Hm weird. Compiling the MNLDaemon required gmake instead of make? using make just reports errors with the .o files.... Anyhow solved now. Thanks. Drew On Dec 8, 2007, at 9:29 PM, vern at cs.berkeley.edu wrote: >> library path and stuff is set... any help? > > It works fine for me, per the appended. This is from freshly > unpacking it. > > Vern > > > c199 9 % make -f Makefile.MNL > gcc -g -c -o TestSend.o TestSend.c > gcc -g -c -o MNLClient.o MNLClient.c > gcc -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o > gcc -g -c -o TestRecv.o TestRecv.c > gcc -g -lsocket -lnsl -lresolv -o TestRecv TestRecv.o > c199 10 % ls > DATE.txt MNLClient.o README.txt TestRecv.o TestSend.o > MNLClient.c MNL_src_0_1b/ TestRecv* TestSend* samplecfg/ > MNLClient.h Makefile.MNL TestRecv.c TestSend.c > c199 11 % cd MNL_src_0_1b/ > c199 12 % make > g++ -g -c -o TimeFns.o TimeFns.cpp > g++ -g -c -o PacketDropper.o PacketDropper.cpp > g++ -g -c -o SpecificPacketDropper.o SpecificPacketDropper.cpp > g++ -g -c -o PeriodicPacketDropper.o PeriodicPacketDropper.cpp > g++ -g -c -o ProbabilisticPacketDropper.o > ProbabilisticPacketDropper.cpp > g++ -g -c -o SendQueue.o SendQueue.cpp > g++ -g -c -o PacketBuf.o PacketBuf.cpp > g++ -g -c -o PacketBufComparator.o PacketBufComparator.cpp > g++ -g -c -o MNLDaemon.o MNLDaemon.cpp > g++ -g -lsocket -lnsl -lresolv -o MNLDaemon main.cpp TimeFns.o > PacketDropper.o SpecificPacketDropper.o PeriodicPacketDropper.o > ProbabilisticPacketDropper.o SendQueue.o PacketBuf.o > PacketBufComparator.o MNLDaemon.o > g++ -g -g -c -o TestSend.o TestSend.c > g++ -g -g -c -o MNLClient.o MNLClient.c > g++ -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o > g++ -g -g -c -o TestRecv.o TestRecv.c > g++ -g -lsocket -lnsl -lresolv -o TestRecv TestRecv.o From waden at berkeley.edu Sat Dec 8 21:38:21 2007 From: waden at berkeley.edu (waden at berkeley.edu) Date: Sat, 8 Dec 2007 21:38:21 -0800 (PST) Subject: [ee122] (no subject) Message-ID: <2400.76.192.128.154.1197178701.squirrel@calmail.berkeley.edu> I'm getting errors trying to compile the packet_parser code on c199, it can't find the definitions for pcap functions, and is this the same as the code for the proto_parser? Thanks! From waden at berkeley.edu Sat Dec 8 22:41:44 2007 From: waden at berkeley.edu (waden at berkeley.edu) Date: Sat, 8 Dec 2007 22:41:44 -0800 (PST) Subject: [ee122] Need help with libpcap and packet_parser Message-ID: <3041.76.192.128.154.1197182504.squirrel@calmail.berkeley.edu> How do you install libpcap on c199 for use with the packet_parser skeleton, I tried looking online for instructions but Im getting permission denied. Thanks! From fowler at eecs.berkeley.edu Sat Dec 8 23:57:22 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sat, 8 Dec 2007 23:57:22 -0800 Subject: [ee122] Need help with libpcap and packet_parser In-Reply-To: <3041.76.192.128.154.1197182504.squirrel@calmail.berkeley.edu> References: <3041.76.192.128.154.1197182504.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0712082357u5c6544bbmeda4a593715bf670@mail.gmail.com> libpcap was installed and verified on c199 before we released the code to you. Are you using the Makefile? Send me any errors directly if you are still having problems. Compilation is working fine for me using the Makefile.... -Lisa On Dec 8, 2007 10:41 PM, wrote: > How do you install libpcap on c199 for use with the packet_parser > skeleton, I tried looking online for instructions but Im getting > permission denied. Thanks! > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From fowler at eecs.berkeley.edu Sun Dec 9 00:00:02 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 00:00:02 -0800 Subject: [ee122] MNL doesn't transmit Ack In-Reply-To: <95aaa0710712082143jf232a0anc56d019fd0daa47e@mail.gmail.com> References: <95aaa0710712082036l4e3d1feeue9b05cfa718309f8@mail.gmail.com> <95aaa0710712082143jf232a0anc56d019fd0daa47e@mail.gmail.com> Message-ID: <330471bf0712090000v61184034v3af86152acd66b95@mail.gmail.com> Please read the FAQ regarding MNL and port numbers. This has been discussed several times on the list as well. MNL_sendto() allows the MNL subsystem to drop packets. TestRecv doesn't care to drop ACKs so it does not use MNL_sendto(). You do need to build support for MNL_sendto() into both your receiver and your sender, but this necessitates the use of two MNLDaemons. Please see the FAQ as well. I hope this helps. -Lisa On Dec 8, 2007 9:43 PM, Haley Nguyen wrote: > I use MNL_sendto() to send the ack, but I noticed TestRecv use sendto() to > send the reply. Is there is reason that TestRecv use sendto() and not > MNL_sendto()? > > > > On Dec 8, 2007 8:36 PM, Haley Nguyen < haley.ng at gmail.com> wrote: > > I have a receiver and a sender running. The sender send a packet to the > receiver, and the receiver sends an Ack back. > > > > My program runs ok with UDP sendto(), but after I change it to use > MNL_sendto(), only the receiver receive the packet from sender, but the > sender doesn't get the ack. In the MNLDaemon, it shows that the ack was > transmitted just like the data, but the receiver hung waiting for the ack. I > don't know what I do wrong. > > > > -- > > Haley Nguyen > > > > -- > Haley Nguyen > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From fowler at eecs.berkeley.edu Sun Dec 9 00:05:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 00:05:17 -0800 Subject: [ee122] csv file In-Reply-To: References: Message-ID: <330471bf0712090005s473ab203j3f0d50361e6fae77@mail.gmail.com> On Dec 8, 2007 8:56 PM, Merry Choi wrote: > What's the difference between cc_send and cc_recv? cc_send is the data from the packet capture performed on the same machine as file_send. cc_recv is the data from the packet capture performed on the same machine as file_recv. > 1. Are we supposed to capture packets coming in on the sender/receiver side? Both. > > 2. or capture packets going out of the sender/receiver side? Both. The captures should show all incoming and outgoing packets (using your protocol) on both the file_send system and the file_recv system. > > 3. Or are we supposed to filter just the packets coming into the sender for > cc_send, and filter just the packets coming into the receiver for cc_recv? As you recall from lecture, the view of the packets exchanged differs greatly when viewed on the side of the "sending" app vs the "receiving" app. This is what I want to see to understand your congestion control mechanism. I apologize that this was not clear... -Lisa From amitmatani at berkeley.edu Sun Dec 9 13:43:18 2007 From: amitmatani at berkeley.edu (Amit Matani) Date: Sun, 9 Dec 2007 13:43:18 -0800 Subject: [ee122] weird MNL behavior Message-ID: <6b68cbc40712091343v1ba35155r9747913b2c58b10a@mail.gmail.com> So, I got the MNL system setup and working on both the receiver and sender side with the correct ports. When I run the program with the basic sample config: dnone0.txt I have issues sometimes. I am using select to wake me up on a timeout or if there is data ready to be received. Towards the end of the transfer, select returns before a timeout and FD_ISSET returns true implying that there is data to be read, so I call recvfrom which ends up blocking which would imply that there is nothing there. I read online that select does not guarantee that recvfrom wont block because the packet may have been corrupted. So I changed my socket to work in non-blocking mode. Now, though, my program goes in an infinite loop because select thinks something is reader queue but recvfrom does not returning anything. Also, since I am simulating high load, the ACK for this packet was never sent by the receiver. I also do a FD_ZERO before calling FD_SET everytime in my loop, so it could not be that there is initialization error. The program works flawlessly while running regular sendto and recvfrom commands even when I manually drop random packets and use timers to increase RTTs. Any ideas why this is happening? -Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/30d98c82/attachment.html From ofer at berkeley.edu Sun Dec 9 13:56:10 2007 From: ofer at berkeley.edu (Ofer Sadgat) Date: Sun, 9 Dec 2007 13:56:10 -0800 Subject: [ee122] lying to mnl Message-ID: <005201c83aae$52a38db0$f7eaa910$@edu> The way that I have written my program, by the time that I would call sendto, the windowsize and header length and all of that information is unavailable. I did use a sliding window protocall, but would I lose points if I plain out lied to mnl and put 0? Another problem could be that my sequence numbers are not byte addressed, it is packet addressed. And packets are variable in length so I would have to rewrite a lot of code to do it that way. Or, could I just use my sequence numbers instead? Thanks, Ofer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/f52fc7d8/attachment.html From fowler at eecs.berkeley.edu Sun Dec 9 14:11:09 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 14:11:09 -0800 Subject: [ee122] lying to mnl In-Reply-To: <005201c83aae$52a38db0$f7eaa910$@edu> References: <005201c83aae$52a38db0$f7eaa910$@edu> Message-ID: <330471bf0712091411mb20c008s36eeddb43560ec59@mail.gmail.com> Those fields are optional and for your logging purposes only. -Lisa On Dec 9, 2007 1:56 PM, Ofer Sadgat wrote: > > > > > The way that I have written my program, by the time that I would call > sendto, the windowsize and header length and all of that information is > unavailable. I did use a sliding window protocall, but would I lose points > if I plain out lied to mnl and put 0? Another problem could be that my > sequence numbers are not byte addressed, it is packet addressed. And packets > are variable in length so I would have to rewrite a lot of code to do it > that way. Or, could I just use my sequence numbers instead? > > > > Thanks, > > Ofer > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From jjariyas at gmail.com Sun Dec 9 16:29:10 2007 From: jjariyas at gmail.com (Jerry J) Date: Sun, 9 Dec 2007 16:29:10 -0800 Subject: [ee122] compile error Message-ID: <2ce058840712091629m62a30f27i1fca30f042fa1767@mail.gmail.com> I had been compiling fine until an hour ago, and I'm and getting these errors that I don't understand. Does anyone have any tips about why these are showing up? I haven't changed the way I've compiled, so I'm not sure what is going on. ld: fatal: symbol `gMNLDaemonPort' is multiply-defined: (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o type=OBJT); ld: fatal: symbol `gMNLDaemonAddr' is multiply-defined: (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o type=OBJT); ld: fatal: symbol `gToDaemonSkt' is multiply-defined: (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o type=OBJT); ld: fatal: symbol `MNLClientInit' is multiply-defined: (file /var/tmp//ccJONX7r.o type=FUNC; file /var/tmp//ccCm82bK.o type=FUNC); ld: fatal: symbol `MNL_sendto' is multiply-defined: (file /var/tmp//ccJONX7r.o type=FUNC; file /var/tmp//ccCm82bK.o type=FUNC); ld: fatal: File processing errors. No output written to listener Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/20434c48/attachment.html From fowler at eecs.berkeley.edu Sun Dec 9 16:42:19 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 16:42:19 -0800 Subject: [ee122] compile error In-Reply-To: <2ce058840712091629m62a30f27i1fca30f042fa1767@mail.gmail.com> References: <2ce058840712091629m62a30f27i1fca30f042fa1767@mail.gmail.com> Message-ID: <330471bf0712091642v749f8901ve92ff6177e3165df@mail.gmail.com> Did you change any of your #includes? Maybe adding MNL support to the receiver, which maybe it didn't have before? -Lisa On Dec 9, 2007 4:29 PM, Jerry J wrote: > I had been compiling fine until an hour ago, and I'm and getting these > errors that I don't understand. Does anyone have any tips about why these > are showing up? I haven't changed the way I've compiled, so I'm not sure > what is going on. > > > ld: fatal: symbol `gMNLDaemonPort' is multiply-defined: > (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o > type=OBJT); > ld: fatal: symbol `gMNLDaemonAddr' is multiply-defined: > (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o > type=OBJT); > ld: fatal: symbol `gToDaemonSkt' is multiply-defined: > (file /var/tmp//ccJONX7r.o type=OBJT; file /var/tmp//ccCm82bK.o > type=OBJT); > ld: fatal: symbol `MNLClientInit' is multiply-defined: > (file /var/tmp//ccJONX7r.o type=FUNC; file /var/tmp//ccCm82bK.o > type=FUNC); > ld: fatal: symbol `MNL_sendto' is multiply-defined: > (file /var/tmp//ccJONX7r.o type=FUNC; file /var/tmp//ccCm82bK.o > type=FUNC); > ld: fatal: File processing errors. No output written to listener > > > Thanks! > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From vern at cs.berkeley.edu Sun Dec 9 16:43:38 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 09 Dec 2007 16:43:38 -0800 Subject: [ee122] compile error In-Reply-To: <330471bf0712091642v749f8901ve92ff6177e3165df@mail.gmail.com> (Sun, 09 Dec 2007 16:42:19 PST). Message-ID: <200712100043.lBA0hhRn008136@pork.ICSI.Berkeley.EDU> > Did you change any of your #includes? Maybe adding MNL support to the > receiver, which maybe it didn't have before? Yeah, in general this looks like a set of inconsistent objects, and recompiling everything from scratch will likely fix it. Vern From vern at cs.berkeley.edu Sun Dec 9 16:53:47 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 09 Dec 2007 16:53:47 -0800 Subject: [ee122] weird MNL behavior In-Reply-To: <6b68cbc40712091343v1ba35155r9747913b2c58b10a@mail.gmail.com> (Sun, 09 Dec 2007 13:43:18 PST). Message-ID: <200712100053.lBA0rqA6008199@pork.ICSI.Berkeley.EDU> > I am using select to wake me up on a timeout or if there is data ready to be > received. Towards the end of the transfer, select returns before a timeout > and FD_ISSET returns true implying that there is data to be read, so I call > recvfrom which ends up blocking which would imply that there is nothing > there. In my experience, this is pretty much always some sort of bug in the use of select, though they can sometimes be very hard to find. You've already taken care of the #1 suspect, which is failing to FD_ZERO or failing to FD_SET correctly. Another possibility is that your code is structured to (somewhere internal) read from the fd that you're then later trying to read due to select(), so that now it no longer has anything to return; or you're reading with recvfrom and what you've specified doesn't match the packet that came in. If you send me your select() loop, I'll try to take a look at it. However, I'm not online much today, so I'm not sure if I'll be able to reply before tomorrow. > I read online that select does not guarantee that recvfrom wont > block because the packet may have been corrupted. That doesn't sound right to me - the kernel should make the integrity checks prior to analyzing the rest of the header, and it has to do that analysis in order to figure out which file descriptor to flag as being available for reading. (More generally, servers all over the world rely on select() not causing them to occasionally block waiting to read - so this is code that has *really* been hammered on.) > So I changed my socket to > work in non-blocking mode. Do try to avoid that. Like select(), it comes with its own subtle usage errors, and the combination can be quite confusing. It's worth stepping through the code executed by MNL for the recv to see whether in some cases it reads twice or something like that. Vern From jkwang at berkeley.edu Sun Dec 9 17:43:37 2007 From: jkwang at berkeley.edu (Jeffrey Wang) Date: Sun, 9 Dec 2007 17:43:37 -0800 Subject: [ee122] Receiving Packets Message-ID: I understand that UDP won't combine 2 packets into 1. However, do we have to follow this same guideline for our protocol? For example, the receiver is expecting packet #1 to come. However, packets #2, #3 come first, so I store it up in some queue. Once packet #1, can I give 1, 2, 3 to the application all at once? or should I only give #1 now? From vern at cs.berkeley.edu Sun Dec 9 17:46:46 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 09 Dec 2007 17:46:46 -0800 Subject: [ee122] Receiving Packets In-Reply-To: (Sun, 09 Dec 2007 17:43:37 PST). Message-ID: <200712100146.lBA1kpGS008835@pork.ICSI.Berkeley.EDU> > For example, the receiver is expecting packet #1 to come. > However, packets #2, #3 come first, so I store it up in some queue. > Once packet #1, can I give 1, 2, 3 to the application all at once? or > should I only give #1 now? The usual bytestream semantics would be to deliver as much of the bytestream as is now available, subject to the limit of how much buffer space the receiving application provided when it called recv(). However, delivering the bytestream in several pieces in such a situation isn't a big deal. Vern From jde at berkeley.edu Sun Dec 9 18:15:15 2007 From: jde at berkeley.edu (Jonathan D. Ellithorpe) Date: Sun, 09 Dec 2007 18:15:15 -0800 Subject: [ee122] Me and MNL: an awkward romance Message-ID: <475CA133.5060600@berkeley.edu> Hey guys, I was wondering two things: 1) Can I run MNL and all that jazz on Cygwin under windows? 2) c199's clogged, is it possible to run MNL on other servers? Thanks!!! Jonathan From amitmatani at berkeley.edu Sun Dec 9 18:33:39 2007 From: amitmatani at berkeley.edu (Amit Matani) Date: Sun, 9 Dec 2007 18:33:39 -0800 Subject: [ee122] weird MNL behavior In-Reply-To: <200712100053.lBA0rqA6008199@pork.ICSI.Berkeley.EDU> References: <6b68cbc40712091343v1ba35155r9747913b2c58b10a@mail.gmail.com> <200712100053.lBA0rqA6008199@pork.ICSI.Berkeley.EDU> Message-ID: <6b68cbc40712091833r476c6bccyfc144a5b40387e1d@mail.gmail.com> Wow, I found it and I am a complete idiot. My RTO estimator sometimes generated a microsecond field of greater than 1 million. This causes select to fail. Thanks for the help. -Amit On Dec 9, 2007 4:53 PM, wrote: > > I am using select to wake me up on a timeout or if there is data ready > to be > > received. Towards the end of the transfer, select returns before a > timeout > > and FD_ISSET returns true implying that there is data to be read, so I > call > > recvfrom which ends up blocking which would imply that there is nothing > > there. > > In my experience, this is pretty much always some sort of bug in the use > of select, though they can sometimes be very hard to find. You've already > taken care of the #1 suspect, which is failing to FD_ZERO or failing to > FD_SET correctly. Another possibility is that your code is structured to > (somewhere internal) read from the fd that you're then later trying to > read due to select(), so that now it no longer has anything to return; > or you're reading with recvfrom and what you've specified doesn't match > the packet that came in. > > If you send me your select() loop, I'll try to take a look at it. > However, > I'm not online much today, so I'm not sure if I'll be able to reply before > tomorrow. > > > I read online that select does not guarantee that recvfrom wont > > block because the packet may have been corrupted. > > That doesn't sound right to me - the kernel should make the integrity > checks > prior to analyzing the rest of the header, and it has to do that analysis > in order to figure out which file descriptor to flag as being available > for reading. (More generally, servers all over the world rely on select() > not causing them to occasionally block waiting to read - so this is code > that has *really* been hammered on.) > > > So I changed my socket to > > work in non-blocking mode. > > Do try to avoid that. Like select(), it comes with its own subtle usage > errors, and the combination can be quite confusing. > > It's worth stepping through the code executed by MNL for the recv to > see whether in some cases it reads twice or something like that. > > Vern > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/66bdb73b/attachment.html From fowler at eecs.berkeley.edu Sun Dec 9 20:33:30 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 20:33:30 -0800 Subject: [ee122] Me and MNL: an awkward romance Message-ID: <200712100433.lBA4X9Y4022312@gateway0.EECS.Berkeley.EDU> 1. Some massaging is necessary, and it's up to you if that's worth the effort given the time. You may try to ask a fellow cygwin-using classmate to give you a recipe. 2. Sphere.cs is friendly and referenced in the FAQ. :) -----Original Message----- From: Jonathan D. Ellithorpe Sent: Sunday, December 09, 2007 6:15 PM To: ee122 at ICSI.Berkeley.EDU Subject: [ee122] Me and MNL: an awkward romance Hey guys, I was wondering two things: 1) Can I run MNL and all that jazz on Cygwin under windows? 2) c199's clogged, is it possible to run MNL on other servers? Thanks!!! Jonathan _______________________________________________ ee122 mailing list ee122 at mailman.ICSI.Berkeley.EDU http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 From lindablus at berkeley.edu Sun Dec 9 21:11:31 2007 From: lindablus at berkeley.edu (Linda Sha) Date: Sun, 9 Dec 2007 21:11:31 -0800 Subject: [ee122] Me and MNL: an awkward romance In-Reply-To: <200712100433.lBA4X9Y4022312@gateway0.EECS.Berkeley.EDU> References: <200712100433.lBA4X9Y4022312@gateway0.EECS.Berkeley.EDU> Message-ID: <6c23caa70712092111k32ac9f65n88dd94476609d91e@mail.gmail.com> Hi all, I tried to compile MNL on sphere.cs and I got this error: sphere [10] ~/receiver > make -f Makefile.MNL gcc -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o ld: fatal: file MNLClient.o: wrong ELF machine type: EM_SPARC ld: fatal: File processing errors. No output written to TestSend collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `TestSend' Does anyone know how to fix this? Thanks a lot! -Linda On Dec 9, 2007 8:33 PM, Lisa Fowler wrote: > 1. Some massaging is necessary, and it's up to you if that's worth the > effort given the time. You may try to ask a fellow cygwin-using classmate to > give you a recipe. > > 2. Sphere.cs is friendly and referenced in the FAQ. :) > > > > -----Original Message----- > From: Jonathan D. Ellithorpe > Sent: Sunday, December 09, 2007 6:15 PM > To: ee122 at ICSI.Berkeley.EDU > Subject: [ee122] Me and MNL: an awkward romance > > Hey guys, I was wondering two things: > > 1) Can I run MNL and all that jazz on Cygwin under windows? > 2) c199's clogged, is it possible to run MNL on other servers? > > Thanks!!! > > Jonathan > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/8ea3b36f/attachment.html From fowler at eecs.berkeley.edu Sun Dec 9 21:23:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 21:23:17 -0800 Subject: [ee122] Me and MNL: an awkward romance In-Reply-To: <6c23caa70712092111k32ac9f65n88dd94476609d91e@mail.gmail.com> References: <200712100433.lBA4X9Y4022312@gateway0.EECS.Berkeley.EDU> <6c23caa70712092111k32ac9f65n88dd94476609d91e@mail.gmail.com> Message-ID: <330471bf0712092123u38a1f9abm9538ceb9c7222343@mail.gmail.com> You need to use gmake on the contents in the MNL_src_0_1b directory, not the root directory. This is listed in the FAQ... On Dec 9, 2007 9:11 PM, Linda Sha wrote: > Hi all, > > I tried to compile MNL on sphere.cs and I got this error: > > sphere [10] ~/receiver > make -f Makefile.MNL > gcc -g -lsocket -lnsl -lresolv -o TestSend TestSend.o MNLClient.o > ld: fatal: file MNLClient.o : wrong ELF machine type: EM_SPARC > ld: fatal: File processing errors. No output written to TestSend > collect2: ld returned 1 exit status > *** Error code 1 > make: Fatal error: Command failed for target `TestSend' > > Does anyone know how to fix this? > > Thanks a lot! > > -Linda > > > > On Dec 9, 2007 8:33 PM, Lisa Fowler wrote: > > 1. Some massaging is necessary, and it's up to you if that's worth the > effort given the time. You may try to ask a fellow cygwin-using classmate to > give you a recipe. > > > > 2. Sphere.cs is friendly and referenced in the FAQ. :) > > > > > > > > > > > > > > -----Original Message----- > > From: Jonathan D. Ellithorpe > > Sent: Sunday, December 09, 2007 6:15 PM > > To: ee122 at ICSI.Berkeley.EDU > > Subject: [ee122] Me and MNL: an awkward romance > > > > Hey guys, I was wondering two things: > > > > 1) Can I run MNL and all that jazz on Cygwin under windows? > > 2) c199's clogged, is it possible to run MNL on other servers? > > > > Thanks!!! > > > > Jonathan > > _______________________________________________ > > 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 huntingtonsurfca at gmail.com Sun Dec 9 20:12:09 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sun, 9 Dec 2007 20:12:09 -0800 Subject: [ee122] Getting MNL to transmit ACK's... Message-ID: "The MNLDaemon rewrites the UDP source port on all outgoing data packets. You will have to provide the source port somewhere else in your packet so that your receiver will know to which UDP port to send responses. Additionally, the MNLDaemon can only process outgoing packets, thus you will have to build support for MNL on both your sender and receiver. This means that your sender and receiver and their corresponding MNLDaemons need to be executed in different paths (e.g. in different folders, on different computers, etc.) -- *Wednesday Dec 5 12:44pm"* *Are those e.g.'s all required or are some optional? Different paths could mean different folders, or different computers... Thanks, Rick * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/105595d0/attachment.html From fowler at eecs.berkeley.edu Sun Dec 9 22:26:04 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 22:26:04 -0800 Subject: [ee122] Getting MNL to transmit ACK's... In-Reply-To: References: Message-ID: <330471bf0712092226i3977491bgfd0fbc855307dbdb@mail.gmail.com> On Dec 9, 2007 8:12 PM, Richard Schmidt wrote: > > Additionally, the MNLDaemon can only process outgoing packets, thus you will > have to build support for MNL on both your sender and receiver. This means > that your sender and receiver and their corresponding MNLDaemons need to be > executed in different paths (e.g. in different folders, on different > computers, etc.) -- Wednesday Dec 5 12:44pm" > > > Are those e.g.'s all required or are some optional? > > Different paths could mean different folders, or different computers... You'll have to use different MNLDaemons for each given config file since you can only specify one config per running MNLDaemon. Additionally, way that MNLDaemon works is that it will save its listening port number to a file (MNLDaemon.sock) -- even if you renamed MNLDaemon to something else, it still saves it in the local directory as MNLDaemon.sock . (Maybe a note for a future release of MNL) Since you can't trace on loopback, you'll have to generate the data running MNLDaemon on different computers -- and even if you're using the same directory replicated across different systems, you'll have to use a different directory. -Lisa From ccowart at berkeley.edu Sun Dec 9 23:07:29 2007 From: ccowart at berkeley.edu (Christopher Cowart) Date: Sun, 9 Dec 2007 23:07:29 -0800 Subject: [ee122] Blocking I/O Message-ID: <20071210070728.GA13717@jobe> Hey- It has occurred to me that any application-layer call to the transport-layer interface must be blocking. Let's use my_send() as an example... If my_send() were to return immediately (like it "should"), control returns to the application layer. Any logic regarding timeouts, receiving ACKs, resending packets, or queuing until the window is clear is gone. For all of this to work, my_send() has to greedily hold onto control of execution until *everything* is done and it's satisfied things are in a steady state. Is this correct, or am I missing something subtle (or glaringly obvious)? A sane approach would be to use threads to take care of the background work so that my_send() wouldn't need to block, but instead just drop the data off into a queue for some other thread to come along and work on. But threads are apparently out of scope, so I'm guessing it follows that non-blocking transport-layer calls are also out of scope. Thanks, -- Chris Cowart -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 824 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/1e2855ea/attachment.bin From vern at cs.berkeley.edu Sun Dec 9 23:12:09 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 09 Dec 2007 23:12:09 -0800 Subject: [ee122] Blocking I/O In-Reply-To: <20071210070728.GA13717@jobe> (Sun, 09 Dec 2007 23:07:29 PST). Message-ID: <200712100712.lBA7CExP012565@pork.ICSI.Berkeley.EDU> > If my_send() were to return immediately (like it "should"), control > returns to the application layer. Any logic regarding timeouts, > receiving ACKs, resending packets, or queuing until the window is clear > is gone. For all of this to work, my_send() has to greedily hold onto > control of execution until *everything* is done and it's satisfied > things are in a steady state. Is this correct, or am I missing something > subtle (or glaringly obvious)? That's correct. (This is a point that was discussed on the mailing list previously.) > A sane approach would be to use threads to take care of the background > work so that my_send() wouldn't need to block, but instead just drop the > data off into a queue for some other thread to come along and work on. > But threads are apparently out of scope Threads are not out of scope; rather, we did not want to require them, so to keep things simple we said it's okay to structure your implementation to work with a single call to my_send() that gives it the entire item to be transferred. Vern From michelleau at berkeley.edu Sun Dec 9 23:41:23 2007 From: michelleau at berkeley.edu (Michelle Au) Date: Sun, 09 Dec 2007 23:41:23 -0800 Subject: [ee122] strange recvfrom() error Message-ID: <475CEDA3.7040801@berkeley.edu> I'm getting a strange error when calling recvfrom(): This is my call: int numBytesRecv = recvfrom(socket,buffer,bufferLen,0, (struct sockaddr*)&destAddr, &destAddrLen); numBytesRecv returns -1 and I've checked the errno flag to be set to: EINVAL -- The MSG_OOB flag is set and no out-of-band data is available I have no idea why I am getting this error. If anybody could help that would be great. Thanks, Michelle From fowler at eecs.berkeley.edu Sun Dec 9 23:44:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 9 Dec 2007 23:44:17 -0800 Subject: [ee122] strange recvfrom() error In-Reply-To: <475CEDA3.7040801@berkeley.edu> References: <475CEDA3.7040801@berkeley.edu> Message-ID: <330471bf0712092344x2f703345tf9d94b63db9ff20b@mail.gmail.com> Hi Michelle- I'll answer this offlist. -Lisa On Dec 9, 2007 11:41 PM, Michelle Au wrote: > I'm getting a strange error when calling recvfrom(): > > This is my call: > int numBytesRecv = recvfrom(socket,buffer,bufferLen,0, > (struct sockaddr*)&destAddr, &destAddrLen); > > numBytesRecv returns -1 and I've checked the errno flag to be set to: > EINVAL -- The MSG_OOB flag is set and no out-of-band data is available > > I have no idea why I am getting this error. If anybody could help that > would be great. > > Thanks, > Michelle > > From kristianlyngbaek at berkeley.edu Mon Dec 10 00:25:36 2007 From: kristianlyngbaek at berkeley.edu (Kristian Lyngbaek) Date: Mon, 10 Dec 2007 00:25:36 -0800 Subject: [ee122] proto_parser csv Message-ID: <8d5ba94f0712100025uc52fcbcm2139f1e6b0fc45af@mail.gmail.com> I am very confused about how the proto_parser relates to the csv files. Is proto_parser supposed to generate the 2 (sender+receiver) csv files so the reader can run it. ? Or is the proto_parse supposed to print the data to standard out and are we supposed to generate the csv files before hand and turn them in with out submission? Thanks, Kristian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071210/0cea9179/attachment.html From fowler at eecs.berkeley.edu Mon Dec 10 00:29:13 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 00:29:13 -0800 Subject: [ee122] proto_parser csv In-Reply-To: <8d5ba94f0712100025uc52fcbcm2139f1e6b0fc45af@mail.gmail.com> References: <8d5ba94f0712100025uc52fcbcm2139f1e6b0fc45af@mail.gmail.com> Message-ID: <330471bf0712100029g7d393cc5pd99e51846295cbae@mail.gmail.com> On Dec 10, 2007 12:25 AM, Kristian Lyngbaek wrote: > I am very confused about how the proto_parser relates to the csv files. > > Is proto_parser supposed to generate the 2 (sender+receiver) csv files so > the reader can run it. ? > Or is the proto_parse supposed to print the data to standard out and are we > supposed to generate the csv files before hand and turn them in with out > submission? The proto_parser is a tool for you to generate CSV files. If you want the proto_parser output to be a CSV file, then that's a fab idea. If you'd rather do some twiddling later to get the output to turn into a CSV, that's also up to you. You are REQUIRED to turn in those CSVs, so however you get there is fine with me. -Lisa From fowler at eecs.berkeley.edu Mon Dec 10 00:36:07 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 00:36:07 -0800 Subject: [ee122] proto_parser csv In-Reply-To: <330471bf0712100029g7d393cc5pd99e51846295cbae@mail.gmail.com> References: <8d5ba94f0712100025uc52fcbcm2139f1e6b0fc45af@mail.gmail.com> <330471bf0712100029g7d393cc5pd99e51846295cbae@mail.gmail.com> Message-ID: <330471bf0712100036n3f866379rdf8c651f97ae1b46@mail.gmail.com> On Dec 10, 2007 12:29 AM, Lisa Fowler wrote: > On Dec 10, 2007 12:25 AM, Kristian Lyngbaek > > wrote: > > I am very confused about how the proto_parser relates to the csv files. > > > > Is proto_parser supposed to generate the 2 (sender+receiver) csv files so > > the reader can run it. ? > > Or is the proto_parse supposed to print the data to standard out and are we > > supposed to generate the csv files before hand and turn them in with out > > submission? > > The proto_parser is a tool for you to generate CSV files. If you want > the proto_parser output to be a CSV file, then that's a fab idea. If > you'd rather do some twiddling later to get the output to turn into a > CSV, that's also up to you. You are REQUIRED to turn in those CSVs, > so however you get there is fine with me. Let me make an addendum to this - I, your Proj 2 grader, will be running additional tests alongside what you will have given me. I would really love to be able to give you credit for your work. Therefore, you must give me descriptive output and/or a functioning custom proto_parser. The more straightforward the better. A happy grader is a happy grader :) -Lisa From fowler at eecs.berkeley.edu Mon Dec 10 00:39:52 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 00:39:52 -0800 Subject: [ee122] proto_parser csv In-Reply-To: <330471bf0712100036n3f866379rdf8c651f97ae1b46@mail.gmail.com> References: <8d5ba94f0712100025uc52fcbcm2139f1e6b0fc45af@mail.gmail.com> <330471bf0712100029g7d393cc5pd99e51846295cbae@mail.gmail.com> <330471bf0712100036n3f866379rdf8c651f97ae1b46@mail.gmail.com> Message-ID: <330471bf0712100039i79dd2817g4093745a4b95857@mail.gmail.com> On Dec 10, 2007 12:36 AM, Lisa Fowler wrote: > > The proto_parser is a tool for you to generate CSV files. If you want > > the proto_parser output to be a CSV file, then that's a fab idea. If > > you'd rather do some twiddling later to get the output to turn into a > > CSV, that's also up to you. You are REQUIRED to turn in those CSVs, > > so however you get there is fine with me. > > Let me make an addendum to this - I, your Proj 2 grader, will be > running additional tests alongside what you will have given me. I > would really love to be able to give you credit for your work. > Therefore, you must give me descriptive output and/or a functioning > custom proto_parser. The more straightforward the better. A happy > grader is a happy grader :) Addendum part deux: Remember the customized proto parser is worth 15 points. Thanks... -Lisa From waden at berkeley.edu Mon Dec 10 09:49:55 2007 From: waden at berkeley.edu (waden at berkeley.edu) Date: Mon, 10 Dec 2007 09:49:55 -0800 (PST) Subject: [ee122] Extracting our datagram from packet_parser Message-ID: <57340.76.192.128.154.1197308995.squirrel@calmail.berkeley.edu> Hi, right now Im working on the packet_parser and I just wanted to make sure that our full UDP datagram with payload is encapsulated within the real UDP/IP/ETHERNET headers. Second, that the capture_len variable refers to the length in bytes of the "packet" argument, because when I printf the variable at the beginning of the function its only between like 50 and 80. Thanks! From fowler at eecs.berkeley.edu Mon Dec 10 10:05:05 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 10:05:05 -0800 Subject: [ee122] Extracting our datagram from packet_parser In-Reply-To: <57340.76.192.128.154.1197308995.squirrel@calmail.berkeley.edu> References: <57340.76.192.128.154.1197308995.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0712101005x67604531mcbf99cb088bcb0bd@mail.gmail.com> On Dec 10, 2007 9:49 AM, wrote: > Hi, right now Im working on the packet_parser and I just wanted to make > sure that our full UDP datagram with payload is encapsulated within the > real UDP/IP/ETHERNET headers. Your UDP payload, which includes your custom protocol's header and payload, are encapsulated within the headers Ethernet>IP>UDP> So, Ethernet>IP>UDP>YourHeaderGoesHere>YourPayload > Second, that the capture_len variable > refers to the length in bytes of the "packet" argument, because when I > printf the variable at the beginning of the function its only between like > 50 and 80. Thanks! >From the comments: * Note that "capture_len" is the length of the packet *as captured by the * tracing program*, and thus might be less than the full length of the * packet. However, the packet pointer only holds that much data, so * we have to be careful not to read beyond it. From fowler at eecs.berkeley.edu Mon Dec 10 14:49:36 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 14:49:36 -0800 Subject: [ee122] MNL_sendto ERROR In-Reply-To: References: Message-ID: <330471bf0712101449s556e6edofa8aaadc6c90da2d@mail.gmail.com> Hi Sean- Please send me offlist the actual text of your error output, and some context so that I can understand what's going on. Thanks, Lisa On Dec 10, 2007 2:37 PM, Xuexin Sean, Zhang wrote: > Hi all, > I used sendto() in my file_recv and everything works > I am changing it to us MNL_sendto, with the call > > and it returns me segfault. > I would be appreciated if anyone would suggests what may cause that error. > Thank you very much. > Sean Zhang From lindablus at berkeley.edu Mon Dec 10 15:39:08 2007 From: lindablus at berkeley.edu (Linda Sha) Date: Mon, 10 Dec 2007 15:39:08 -0800 Subject: [ee122] Unable to capture any packets Message-ID: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> Hi, I have a question about tcpdump: When I specify a port number for tcpdump, I'm not able to capture any packets. When I take out the port number, I get ssh encrypted messages. I'm not sure what happened. /share/b/ee122/tcpdump -s 0 -w trace host c199.eecs.berkeley.edu and port 9468 tcpdump.sun4u: listening on qfe0, link-type EN10MB (Ethernet), capture size 65535 bytes 0 packets captured 34224 packets received by filter 0 packets dropped by kernel ##port 9468 is the port my server is listening on. Thanks. Linda -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071210/85ff223c/attachment.html From fowler at eecs.berkeley.edu Mon Dec 10 16:08:08 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 16:08:08 -0800 Subject: [ee122] Unable to capture any packets In-Reply-To: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> References: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> Message-ID: <330471bf0712101608v7ae98001hfc2c38d5e04dae26@mail.gmail.com> Linda, that command works just fine for me. Are the packets going through just fine? Please respond offlist. Thanks, Lisa On Dec 10, 2007 3:39 PM, Linda Sha wrote: > Hi, > > I have a question about tcpdump: > When I specify a port number for tcpdump, I'm not able to capture any > packets. When I take out the port number, I get ssh encrypted messages. I'm > not sure what happened. > > /share/b/ee122/tcpdump -s 0 -w trace host c199.eecs.berkeley.edu and port > 9468 > tcpdump.sun4u: listening on qfe0, link-type EN10MB (Ethernet), capture size > 65535 bytes > 0 packets captured > 34224 packets received by filter > 0 packets dropped by kernel > > ##port 9468 is the port my server is listening on. > > Thanks. > > Linda > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From fowler at eecs.berkeley.edu Mon Dec 10 17:14:39 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 17:14:39 -0800 Subject: [ee122] tcpdump cannot capture loopback Message-ID: <330471bf0712101714i1c3aecc2ob805417681c0ed77@mail.gmail.com> Reminder-- tcpdump cannot capture loopback traffic (traffic sent to localhost and received on localhost). You MUST transfer traffic between different hosts, such as sphere and c199. Please check the FAQ for more info. -Lisa From fowler at eecs.berkeley.edu Mon Dec 10 17:24:38 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 17:24:38 -0800 Subject: [ee122] Reminder: Test on c199, expected files Message-ID: <330471bf0712101724m55825773s9d7579adaf649698@mail.gmail.com> Don't forget to test on c199! Do it now! I expect to see in your submission directory: README Makefile file_send file_recv proto_parser cc_send_1a.csv cc_send_1b.csv cc_send_2a.csv cc_send_3a.csv cc_send_3b.csv cc_send_4a.csv cc_send_4b.csv cc_recv_1a.csv cc_recv_1b.csv cc_recv_2a.csv cc_recv_3a.csv cc_recv_3b.csv cc_recv_4a.csv cc_recv_4b.csv And any and all associated and required files to compile the above successfully. Thanks, Lisa From phamductri at berkeley.edu Mon Dec 10 17:38:18 2007 From: phamductri at berkeley.edu (phamductri at berkeley.edu) Date: Mon, 10 Dec 2007 17:38:18 -0800 (PST) Subject: [ee122] how about tshark ? Message-ID: <39470.128.32.42.27.1197337098.squirrel@calmail.berkeley.edu> So tcpdump can't capture UDP on local loop, how about tshark ? is there any way to capture packets on local loop ? thanks From simtan at berkeley.edu Mon Dec 10 17:43:42 2007 From: simtan at berkeley.edu (Simon Tan) Date: Mon, 10 Dec 2007 17:43:42 -0800 Subject: [ee122] Reminder: Test on c199, expected files In-Reply-To: <330471bf0712101724m55825773s9d7579adaf649698@mail.gmail.com> References: <330471bf0712101724m55825773s9d7579adaf649698@mail.gmail.com> Message-ID: Do you really want the binary executables, or just the source files and the Makefile? Also, would you mind the CSV files in a directory of their own (i.e. /csv/cc_send_1a.csv, etc.)? Thanks! On Mon, 10 Dec 2007 17:24:38 -0800, Lisa Fowler wrote: > Don't forget to test on c199! Do it now! > > I expect to see in your submission directory: > > README > Makefile > file_send > file_recv > proto_parser > cc_send_1a.csv > cc_send_1b.csv > cc_send_2a.csv > cc_send_3a.csv > cc_send_3b.csv > cc_send_4a.csv > cc_send_4b.csv > cc_recv_1a.csv > cc_recv_1b.csv > cc_recv_2a.csv > cc_recv_3a.csv > cc_recv_3b.csv > cc_recv_4a.csv > cc_recv_4b.csv > > And any and all associated and required files to compile the above > successfully. > > Thanks, > Lisa > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 -- ~Simon Tan >> undergraduate at UC Berkeley Source: simtan at berkeley.edu From fowler at eecs.berkeley.edu Mon Dec 10 17:49:05 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 17:49:05 -0800 Subject: [ee122] how about tshark ? In-Reply-To: <39470.128.32.42.27.1197337098.squirrel@calmail.berkeley.edu> References: <39470.128.32.42.27.1197337098.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0712101749j68ee1febr49c79af750bc6676@mail.gmail.com> tshark can capture loopback, but I will be testing across hosts, so you need to make sure that your program works across hosts. On Dec 10, 2007 5:38 PM, wrote: > So tcpdump can't capture UDP on local loop, how about tshark ? is there > any way to capture packets on local loop ? > > thanks > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From simtan at berkeley.edu Mon Dec 10 17:54:06 2007 From: simtan at berkeley.edu (Simon Tan) Date: Mon, 10 Dec 2007 17:54:06 -0800 Subject: [ee122] Unable to capture any packets In-Reply-To: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> References: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> Message-ID: Capturing on the file_recv receiving port does capture packets, but we found that we get more complete results (i.e. we capture both outgoing and incoming packets coming on both sender and receiver sides) if we capture on the MNLDaemons' listening ports. However, for some reason, capturing on the MNLDaemon's ports didn't capture any packets at first -- we had to add 1 to the port numbers (MNLDaemon's listening port + 1) to capture packets. This seems completely ridiculous, but it actually worked (in our case at least). Can anyone give us insight as to why? (Is MNLDaemon buggy?) On Mon, 10 Dec 2007 15:39:08 -0800, Linda Sha wrote: > Hi, > > I have a question about tcpdump: > When I specify a port number for tcpdump, I'm not able to capture any > packets. When I take out the port number, I get ssh encrypted messages. > I'm > not sure what happened. > > /share/b/ee122/tcpdump -s 0 -w trace host c199.eecs.berkeley.edu and port > 9468 > tcpdump.sun4u: listening on qfe0, link-type EN10MB (Ethernet), capture > size > 65535 bytes > 0 packets captured > 34224 packets received by filter > 0 packets dropped by kernel > > ##port 9468 is the port my server is listening on. > > Thanks. > > Linda -- ~Simon Tan >> undergraduate at UC Berkeley Source: simtan at berkeley.edu From phamductri at berkeley.edu Mon Dec 10 18:02:11 2007 From: phamductri at berkeley.edu (phamductri at berkeley.edu) Date: Mon, 10 Dec 2007 18:02:11 -0800 (PST) Subject: [ee122] tshark question Message-ID: <40268.128.32.42.27.1197338531.squirrel@calmail.berkeley.edu> so tshark can capture loop back, this is the the one that I tried: tshark -c 1000 -w trace -f "udp and port 3456" -T text(on the receiver) tshark -c 1000 -w trace -f "udp and udp dst 3456" -T text (on the sender) the sender and receiver is the same machine, i run tshark in two different terminal, somehow tshark does not capture anything. Any ideas ? (I know that I have to do two separate machine, but i'm testing the parser right now, while my partner is finishing the rest) Thanks , Tri From vern at cs.berkeley.edu Mon Dec 10 18:06:02 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 10 Dec 2007 18:06:02 -0800 Subject: [ee122] tshark question In-Reply-To: <40268.128.32.42.27.1197338531.squirrel@calmail.berkeley.edu> (Mon, 10 Dec 2007 18:02:11 PST). Message-ID: <200712110206.lBB267Nj003012@pork.ICSI.Berkeley.EDU> > so tshark can capture loop back, this is the the one that I tried: I would not expect tshark to be able to capture the loop back either (though haven't tried). It uses the same packet-capture interface as tcpdump, and I believe the Solaris kernel simply does not provide support for capturing loopback packets. Vern From fowler at eecs.berkeley.edu Mon Dec 10 18:33:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 18:33:17 -0800 Subject: [ee122] tshark question In-Reply-To: <40268.128.32.42.27.1197338531.squirrel@calmail.berkeley.edu> References: <40268.128.32.42.27.1197338531.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0712101833q4c648a9fta43d51eca3aa09a9@mail.gmail.com> tshark can capture loopback on some systems, but not on c199 nor sphere. If your tshark can capture loopback, you have to specify the -i lo0 interface. -Lisa On Dec 10, 2007 6:02 PM, wrote: > so tshark can capture loop back, this is the the one that I tried: > tshark -c 1000 -w trace -f "udp and port 3456" -T text(on the receiver) > tshark -c 1000 -w trace -f "udp and udp dst 3456" -T text (on the sender) > the sender and receiver is the same machine, i run tshark in two different > terminal, somehow tshark does not capture anything. Any ideas ? (I know > that I have to do two separate machine, but i'm testing the parser right > now, while my partner is finishing the rest) > > Thanks , > > Tri > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From fowler at eecs.berkeley.edu Mon Dec 10 18:34:20 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 18:34:20 -0800 Subject: [ee122] Reminder: Test on c199, expected files In-Reply-To: References: <330471bf0712101724m55825773s9d7579adaf649698@mail.gmail.com> Message-ID: <330471bf0712101834h7bcde770o2b4822bd70d30d00@mail.gmail.com> It'd be great if it were precompiled for me, but that's fine if you don't -- but MAKE SURE that your makefile works! CSV's can be in their own directory. On Dec 10, 2007 5:43 PM, Simon Tan wrote: > Do you really want the binary executables, or just the source files and > the Makefile? > > Also, would you mind the CSV files in a directory of their own (i.e. > /csv/cc_send_1a.csv, etc.)? > > Thanks! > > On Mon, 10 Dec 2007 17:24:38 -0800, Lisa Fowler > wrote: > > > > Don't forget to test on c199! Do it now! > > > > I expect to see in your submission directory: > > > > README > > Makefile > > file_send > > file_recv > > proto_parser > > cc_send_1a.csv > > cc_send_1b.csv > > cc_send_2a.csv > > cc_send_3a.csv > > cc_send_3b.csv > > cc_send_4a.csv > > cc_send_4b.csv > > cc_recv_1a.csv > > cc_recv_1b.csv > > cc_recv_2a.csv > > cc_recv_3a.csv > > cc_recv_3b.csv > > cc_recv_4a.csv > > cc_recv_4b.csv > > > > And any and all associated and required files to compile the above > > successfully. > > > > Thanks, > > Lisa > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > > -- > ~Simon Tan >> undergraduate at UC Berkeley > Source: simtan at berkeley.edu > From drewlustro at gmail.com Mon Dec 10 20:18:01 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Mon, 10 Dec 2007 20:18:01 -0800 Subject: [ee122] MNL sends out pACKets on MNL.listen_port+1 (watch out!) Message-ID: <26CD6EA3-2BB8-400F-B4A7-88850D31302E@gmail.com> I'm was having trouble finding out what ports to capture on for each side, half becauce im not sure and half because the results reported by packet_parser are unexpected.... however I figured it out and I think this is undocumented. the MNL Daemon listens on say, port 12345 BUT when it sends anything out, it actually sends it out on 12346 ( + 1)... which is something you must know when selecting udp ports to observe when running tcpdump. This is probably confusing to everyone... Drew From joshua.hunt at berkeley.edu Mon Dec 10 20:37:11 2007 From: joshua.hunt at berkeley.edu (Josh Hunt) Date: Mon, 10 Dec 2007 20:37:11 -0800 Subject: [ee122] Unable to capture any packets In-Reply-To: References: <6c23caa70712101539m2e96d2b8xd1f27cb096e808cf@mail.gmail.com> Message-ID: <130a655e0712102037i5bbd3941pf33f56af7f398f1f@mail.gmail.com> I haven't been following this thread, but figured I'd say that I was having problems capturing to files. It was really strange and I couldn't figure it out. So I checked my quota on the inst machine and it was full :( doh! So I deleted some files and magically I could write my dump files now. Anyway thought this may keep someone from going crazy-er. Josh On Dec 10, 2007 5:54 PM, Simon Tan wrote: > Capturing on the file_recv receiving port does capture packets, but we > found that we get more complete results (i.e. we capture both outgoing and > incoming packets coming on both sender and receiver sides) if we capture > on the MNLDaemons' listening ports. > > However, for some reason, capturing on the MNLDaemon's ports didn't > capture any packets at first -- we had to add 1 to the port numbers > (MNLDaemon's listening port + 1) to capture packets. This seems > completely ridiculous, but it actually worked (in our case at least). Can > anyone give us insight as to why? (Is MNLDaemon buggy?) > > > On Mon, 10 Dec 2007 15:39:08 -0800, Linda Sha > wrote: > > > Hi, > > > > I have a question about tcpdump: > > When I specify a port number for tcpdump, I'm not able to capture any > > packets. When I take out the port number, I get ssh encrypted messages. > > I'm > > not sure what happened. > > > > /share/b/ee122/tcpdump -s 0 -w trace host c199.eecs.berkeley.edu and > port > > 9468 > > tcpdump.sun4u: listening on qfe0, link-type EN10MB (Ethernet), capture > > size > > 65535 bytes > > 0 packets captured > > 34224 packets received by filter > > 0 packets dropped by kernel > > > > ##port 9468 is the port my server is listening on. > > > > Thanks. > > > > Linda > > > > -- > ~Simon Tan >> undergraduate at UC Berkeley > Source: simtan at berkeley.edu > _______________________________________________ > 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/20071210/e2d8ba72/attachment.html From fowler at eecs.berkeley.edu Mon Dec 10 20:44:45 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 20:44:45 -0800 Subject: [ee122] submit proj2b Message-ID: <330471bf0712102044s609cdfc9h260bc123c6ee506e@mail.gmail.com> Not proj2phase2 submit proj2b I don't have the ability to fix this, sorry folks. Thanks, Lisa From drewlustro at gmail.com Mon Dec 10 22:14:38 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Mon, 10 Dec 2007 22:14:38 -0800 Subject: [ee122] Extension to midnight? Message-ID: file1.bin takes 15-20 minutes to do under the first MNL conf file... Wasn't expecting to have to deal with waiting for a long time, especially when c199 has 100+ users on it and a high load. Any chance we could get more time? From fowler at eecs.berkeley.edu Mon Dec 10 22:38:58 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 10 Dec 2007 22:38:58 -0800 Subject: [ee122] Extension to midnight? In-Reply-To: References: Message-ID: <330471bf0712102238j2f63242fn75dda7009aa85da5@mail.gmail.com> I hear your plea. If you are unable to get the 1a tests working due to time constraints or certain things making your transfer take a very long time, you may submit the 1a csv's later for a minor penalty. The rest of your code must be delivered on time -- ONLY the 1a CSV's may show up late to be eligible for this minor penalty. You must submit the 1a CSV's as a separate submission attempt with no extra files, or else I will consider it to be a late submission altogether. Let me know if this is not clear. -Lisa On Dec 10, 2007 10:14 PM, Drew Lustro wrote: > file1.bin takes 15-20 minutes to do under the first MNL conf file... > > Wasn't expecting to have to deal with waiting for a long time, > especially when c199 has 100+ users on it and a high load. > > Any chance we could get more time? > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From drewlustro at gmail.com Mon Dec 10 22:51:00 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Mon, 10 Dec 2007 22:51:00 -0800 Subject: [ee122] Extension to midnight? In-Reply-To: <330471bf0712102238j2f63242fn75dda7009aa85da5@mail.gmail.com> References: <330471bf0712102238j2f63242fn75dda7009aa85da5@mail.gmail.com> Message-ID: <0A0B094E-33DE-4A24-BBE2-3B1E729AC415@gmail.com> You're very clear, don't worry... we'll get you as many csv's as we can. It's just sad that we're going to lose 10% because every single time you run a test you gotta restart MNL on both sides, write down the port number it chooses, restart tcpdump on both sides with regards to the port numbers written down, start the receiver, start the sender, and then finally collect those dump files and run them through the protoparser. Sucks when your actual project is finished :[ Drew On Dec 10, 2007, at 10:38 PM, Lisa Fowler wrote: > I hear your plea. > > If you are unable to get the 1a tests working due to time constraints > or certain things making your transfer take a very long time, you may > submit the 1a csv's later for a minor penalty. > > The rest of your code must be delivered on time -- ONLY the 1a CSV's > may show up late to be eligible for this minor penalty. > > You must submit the 1a CSV's as a separate submission attempt with no > extra files, or else I will consider it to be a late submission > altogether. > > Let me know if this is not clear. > > -Lisa > > On Dec 10, 2007 10:14 PM, Drew Lustro wrote: >> file1.bin takes 15-20 minutes to do under the first MNL conf file... >> >> Wasn't expecting to have to deal with waiting for a long time, >> especially when c199 has 100+ users on it and a high load. >> >> Any chance we could get more time? >> _______________________________________________ >> ee122 mailing list >> ee122 at mailman.ICSI.Berkeley.EDU >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 >> From vern at cs.berkeley.edu Mon Dec 10 22:53:41 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 10 Dec 2007 22:53:41 -0800 Subject: [ee122] Extension to midnight? In-Reply-To: <0A0B094E-33DE-4A24-BBE2-3B1E729AC415@gmail.com> (Mon, 10 Dec 2007 22:51:00 PST). Message-ID: <200712110653.lBB6rkMh006333@pork.ICSI.Berkeley.EDU> > Sucks when your actual project is finished :[ Please keep complaints like this off of the mailing list. (And note: you already had 48 hours beyond the original deadline ...) Vern From drewlustro at gmail.com Mon Dec 10 23:08:13 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Mon, 10 Dec 2007 23:08:13 -0800 Subject: [ee122] Extension to midnight? In-Reply-To: <200712110653.lBB6rkMh006333@pork.ICSI.Berkeley.EDU> References: <200712110653.lBB6rkMh006333@pork.ICSI.Berkeley.EDU> Message-ID: Sorry. I'm a passionate cod3r :) We'll take the csv hit, thank you. On Dec 10, 2007, at 10:53 PM, vern at cs.berkeley.edu wrote: >> Sucks when your actual project is finished :[ > > Please keep complaints like this off of the mailing list. (And > note: you > already had 48 hours beyond the original deadline ...) > > Vern From kristianlyngbaek at berkeley.edu Tue Dec 11 01:14:55 2007 From: kristianlyngbaek at berkeley.edu (Kristian Lyngbaek) Date: Tue, 11 Dec 2007 01:14:55 -0800 Subject: [ee122] MNL vs. UDP sendto() Message-ID: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> We had a fully functional ready to submit program using UDP sendto() (well before submission deadline i might add). We are under the impression that MNL sendto() is supposed to be a transparent function such that we can replace all of our UDP sendto()s with MNL sendto()s. This is not the case. In an attempt to prepare for the HTTP client/server early on, our implementation involves a listening port on the receiver that sets up pairs of sockets on either side. (one for outgoing, one for incoming data - these were meant to be used for data transfer in HTTP transactions) We connected the sockets on either end, and our UDP sendto() calls look like this: sendto(node->out_fd, &s_header, S_HSIZE, 0, NULL, sizeof blankAddr); Our MNL sendto() calls look like this: MNL_sendto(node->out_fd, &s_header, S_HSIZE, 0, serv_addr, length, node->seqNumber, 0, S_HSIZE, &error); (serv_addr is allready struct sockaddr pointer, error is a local variable, etc. (basically our arguments are valid)) When we replaced our UDP sends with MNL sends, the MNL daemons said that the packets were getting sent to the appropriate sockets, but in reality the packets were not making it. It seemed that MNL sentto() only worked between the initial sender socket and receiver listening port. As soon as the receiver handed over the job to the other specially created sockets/ports MNL sentto() stopped working, although UDP sendto() does. We were wondering if MNL sendto() can only support 1 connection - Or transfer between only 2 sockets. As in if you send from one socket to another. And then from the same socket to a DIFFERENT one, will MNL fail? because in our case it sure seems like it does. Any ideas? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071211/7556eb52/attachment.html From ccowart at berkeley.edu Tue Dec 11 01:24:20 2007 From: ccowart at berkeley.edu (Christopher Cowart) Date: Tue, 11 Dec 2007 01:24:20 -0800 Subject: [ee122] MNL vs. UDP sendto() In-Reply-To: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> References: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> Message-ID: <20071211092420.GA29139@jobe.lan> On Tue, Dec 11, 2007 at 01:14:55AM -0800, Kristian Lyngbaek wrote: > We had a fully functional ready to submit program using UDP sendto() (well > before submission deadline i might add). > > We are under the impression that MNL sendto() is supposed to be a > transparent function such that we can replace all of our UDP sendto()s with > MNL sendto()s. > > This is not the case. MNL intercepts and resends the outbound UDP datagrams. After MNL is done with them, the src port is rewritten. This is mentioned in the revised spec. Given we designed out proto to sit on top of UDP, we assumed we wouldn't have to track ports. With the revised spec, we had to revisit that. You'll need to embed the src port in the messages so the remote host knows where to send reply datagrams. This would be unnecessary if MNL's sentto was actually a drop-in replacement. -- Chris Cowart -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 824 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071211/5ace92d1/attachment-0001.bin From kristianlyngbaek at berkeley.edu Tue Dec 11 01:28:47 2007 From: kristianlyngbaek at berkeley.edu (Kristian Lyngbaek) Date: Tue, 11 Dec 2007 01:28:47 -0800 Subject: [ee122] MNL vs. UDP sendto() In-Reply-To: <20071211092420.GA29139@jobe.lan> References: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> <20071211092420.GA29139@jobe.lan> Message-ID: <8d5ba94f0712110128x42564a1mb4bb86e7a4039e43@mail.gmail.com> We do embed the src port in the messages so the remote host knows where to send reply datagrams. The daemons show that it is being send to the right port, but its not getting there with MNL. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071211/0d53fed9/attachment.html From ofer at berkeley.edu Tue Dec 11 03:06:55 2007 From: ofer at berkeley.edu (Ofer Sadgat) Date: Tue, 11 Dec 2007 03:06:55 -0800 Subject: [ee122] MNL vs. UDP sendto() In-Reply-To: <8d5ba94f0712110128x42564a1mb4bb86e7a4039e43@mail.gmail.com> References: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> <20071211092420.GA29139@jobe.lan> <8d5ba94f0712110128x42564a1mb4bb86e7a4039e43@mail.gmail.com> Message-ID: <002f01c83be5$f416e5b0$dc44b110$@edu> I had the same problem, in my case I was trying get data from the MNLDaemon rather from a fresh socket. The MNLDaemon does not (I think) accept data and forward it to you therefore you can end up with no data. -Ofer From: ee122-bounces at ICSI.Berkeley.EDU [mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Kristian Lyngbaek Sent: Tuesday, December 11, 2007 1:29 AM To: Kristian Lyngbaek; ee122 at ICSI.Berkeley.EDU Subject: Re: [ee122] MNL vs. UDP sendto() We do embed the src port in the messages so the remote host knows where to send reply datagrams. The daemons show that it is being send to the right port, but its not getting there with MNL. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071211/8c967179/attachment.html From apolloellis at berkeley.edu Tue Dec 11 03:12:27 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Tue, 11 Dec 2007 03:12:27 -0800 (PST) Subject: [ee122] mnl_sendto -> recvfrom Message-ID: <58006.128.32.35.231.1197371547.squirrel@calmail.berkeley.edu> hi i can send files over mnl on one server but when i run mnl programs on two different servers i can send one way but not the other for some reason. i checked and the port mnl is sending to is correct and the ip address mnl is using is correct. i just cant solve it. has anybody got around this yet? :-) Apollo From mehechb at berkeley.edu Tue Dec 11 03:22:52 2007 From: mehechb at berkeley.edu (Bruno) Date: Tue, 11 Dec 2007 03:22:52 -0800 Subject: [ee122] mnl_sendto -> recvfrom In-Reply-To: <58006.128.32.35.231.1197371547.squirrel@calmail.berkeley.edu> References: <58006.128.32.35.231.1197371547.squirrel@calmail.berkeley.edu> Message-ID: <2c2ede6d0712110322u6d89bfbdjbb9c96563e2041a3@mail.gmail.com> We are having similar problems. It works if we send on the same machine, but when we send between two machines one of them can never receive.We've been trying to figure this out for several hours and have tried several machines and the only one that seems able to receive packets is c199. I've checked the ports and addresses and they are all right, packets are sent from the MNL port to the server/client port, and tshark shows the packet arriving at the destination, but our server/client never gets it. Bruno On Dec 11, 2007 3:12 AM, wrote: > hi i can send files over mnl on one server but when i run mnl programs on > two different servers i can send one way but not the other for some > reason. i checked and the port mnl is sending to is correct and the ip > address mnl is using is correct. i just cant solve it. has anybody got > around this yet? :-) > Apollo > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From drewlustro at gmail.com Tue Dec 11 04:40:37 2007 From: drewlustro at gmail.com (Drew Lustro) Date: Tue, 11 Dec 2007 04:40:37 -0800 Subject: [ee122] Extension to midnight? In-Reply-To: <475E7F8B.4070109@berkeley.edu> References: <330471bf0712102238j2f63242fn75dda7009aa85da5@mail.gmail.com> <0A0B094E-33DE-4A24-BBE2-3B1E729AC415@gmail.com> <475E7F8B.4070109@berkeley.edu> Message-ID: <6BD1CC25-893E-495A-B3F0-DBDF2DCEDD9D@gmail.com> ....and you've gone for the flamebait On Dec 11, 2007, at 4:16 AM, Niels Joubert wrote: > Passionate cod3r? Look up bash shell scripts > > Drew Lustro wrote: >> You're very clear, don't worry... we'll get you as many csv's as >> we can. It's just sad that we're going to lose 10% because every >> single time you run a test you gotta restart MNL on both sides, >> write down the port number it chooses, restart tcpdump on both >> sides with regards to the port numbers written down, start the >> receiver, start the sender, and then finally collect those dump >> files and run them through the protoparser. >> >> Sucks when your actual project is finished :[ >> >> Drew >> >> On Dec 10, 2007, at 10:38 PM, Lisa Fowler wrote: >> >> >>> I hear your plea. >>> >>> If you are unable to get the 1a tests working due to time >>> constraints >>> or certain things making your transfer take a very long time, you >>> may >>> submit the 1a csv's later for a minor penalty. >>> >>> The rest of your code must be delivered on time -- ONLY the 1a CSV's >>> may show up late to be eligible for this minor penalty. >>> >>> You must submit the 1a CSV's as a separate submission attempt with >>> no >>> extra files, or else I will consider it to be a late submission >>> altogether. >>> >>> Let me know if this is not clear. >>> >>> -Lisa >>> >>> On Dec 10, 2007 10:14 PM, Drew Lustro wrote: >>> >>>> file1.bin takes 15-20 minutes to do under the first MNL conf >>>> file... >>>> >>>> Wasn't expecting to have to deal with waiting for a long time, >>>> especially when c199 has 100+ users on it and a high load. >>>> >>>> Any chance we could get more time? >>>> _______________________________________________ >>>> 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 fowler at eecs.berkeley.edu Tue Dec 11 09:35:41 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 11 Dec 2007 09:35:41 -0800 Subject: [ee122] mnl_sendto -> recvfrom In-Reply-To: <2c2ede6d0712110322u6d89bfbdjbb9c96563e2041a3@mail.gmail.com> References: <58006.128.32.35.231.1197371547.squirrel@calmail.berkeley.edu> <2c2ede6d0712110322u6d89bfbdjbb9c96563e2041a3@mail.gmail.com> Message-ID: <330471bf0712110935r5ce49757u97882c0d17277975@mail.gmail.com> These problems generally indicate a bug in your code, such as not correctly setting the byte ordering on the port number on which your sender is listening. If you're on the same machine, you happen to luck out since the byte ordering is the same. If you're on a different machine, alas, it's probably not. When you do getsockname, you must save the port in its ntohs form. -Lisa On Dec 11, 2007 3:22 AM, Bruno wrote: > We are having similar problems. It works if we send on the same > machine, but when we send between two machines one of them can never > receive.We've been trying to figure this out for several hours and > have tried several machines and the only one that seems able to > receive packets is c199. I've checked the ports and addresses and > they are all right, packets are sent from the MNL port to the > server/client port, and tshark shows the packet arriving at the > destination, but our server/client never gets it. > > Bruno > > > On Dec 11, 2007 3:12 AM, wrote: > > hi i can send files over mnl on one server but when i run mnl programs on > > two different servers i can send one way but not the other for some > > reason. i checked and the port mnl is sending to is correct and the ip > > address mnl is using is correct. i just cant solve it. has anybody got > > around this yet? :-) > > Apollo > > > > _______________________________________________ > > 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 fowler at eecs.berkeley.edu Tue Dec 11 09:54:40 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 11 Dec 2007 09:54:40 -0800 Subject: [ee122] MNL vs. UDP sendto() In-Reply-To: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> References: <8d5ba94f0712110114l7b059069m28d2071434d58620@mail.gmail.com> Message-ID: <330471bf0712110954x41272d37k5dc78ed73c35e4e3@mail.gmail.com> Discussions regarding the requirements of MNL have been regular on the list and featured in the FAQ. I have also answered this question a few times in office hours. I'm sorry that these resources were unavailable to you, but they have been provided. HOW MNL WORKS: Sender listens on 5670. Receiver listens on 7890. MNL(sender) listens on 12345. MNL(receiver) listens on 54321. Sender sends to Receiver:7890 via MNL_sendto. (Src= sender:5670, Dst= receiver:7890) MNL_sendto rewrites the 7890 with 12345, so that MNL(sender) intercepts the packet. (Src= sender:5670, Dst= sender:12345) MNL(sender) then fiddles with the packet, possibly dropping it, and rewrites the destination to how it was before -- due to not being root, the source port has to change: (Src= sender:12346, Dst= receiver:7890) Receiver receives (Src= sender:12346, Dst= receiver:7890) To respond, Receiver must send all responses to (Src= receiver:7890, Dst= sender:5670), which it could save as a global state variable regarding its "connected host" Thus, Receiver sends the responses to (Src= receiver:7890, Dst= sender:5670) Which gets intercepted via MNL(receiver) (Src= receiver:7890, Dest= receiver:54321) And which gets rewritten by MNL(receiver) (Src= receiver:54322, Dest= sender:5670) IF you do not handle byte ordering properly, you will have problems. If you don't recompile MNL on the correct servers and somehow are using an old MNLDaemon.sock, you'll have problems. If you're not using c199 and sphere, you might have NAT or firewall issues to contend with. If you are testing to see if incoming packets are from the correct host without dealing with this port-rewrite issue, you may have dropped your own packet. If you are still having problems, you may contact me directly. Just about every "MNL bug" that I have been debugging with you has been unique and centered on your code and your unique implementation. -Lisa On Dec 11, 2007 1:14 AM, Kristian Lyngbaek wrote: > We had a fully functional ready to submit program using UDP sendto() (well > before submission deadline i might add). > > We are under the impression that MNL sendto() is supposed to be a > transparent function such that we can replace all of our UDP sendto()s with > MNL sendto()s. > > This is not the case. > > In an attempt to prepare for the HTTP client/server early on, our > implementation involves a listening port on the receiver that sets up pairs > of sockets on either side. (one for outgoing, one for incoming data - these > were meant to be used for data transfer in HTTP transactions) > > We connected the sockets on either end, and our UDP sendto() calls look like > this: > > sendto(node->out_fd, &s_header, S_HSIZE, 0, NULL, sizeof blankAddr); > > Our MNL sendto() calls look like this: > > MNL_sendto(node->out_fd, &s_header, S_HSIZE, 0, serv_addr, length, > node->seqNumber, 0, S_HSIZE, &error); > > > (serv_addr is allready struct sockaddr pointer, error is a local variable, > etc. (basically our arguments are valid)) > > When we replaced our UDP sends with MNL sends, the MNL daemons said that the > packets were getting sent to the appropriate sockets, but in reality the > packets were not making it. > It seemed that MNL sentto() only worked between the initial sender socket > and receiver listening port. As soon as the receiver handed over the job to > the other specially created sockets/ports MNL sentto() stopped working, > although UDP sendto() does. > > We were wondering if MNL sendto() can only support 1 connection - Or > transfer between only 2 sockets. As in if you send from one socket to > another. And then from the same socket to a DIFFERENT one, will MNL fail? > because in our case it sure seems like it does. > > Any ideas? > > Thanks. > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From jde at berkeley.edu Tue Dec 11 14:17:04 2007 From: jde at berkeley.edu (Jonathan D. Ellithorpe) Date: Tue, 11 Dec 2007 14:17:04 -0800 Subject: [ee122] ./MNLDaemon: Invalid argument. Message-ID: <475F0C60.3060509@berkeley.edu> I'm trying to run mnldaemon on sphere.cs.berkeley.edu, and when I try ./MNLDaemon samplecfg/dnon0.txt the machine says that the argument is invalid. Anybody know what's going on? I've recompiled for sphere and the daemon is in a separate folder (MNLSphere on sphere versus MNLc199 for c199). Thanks! Jonathan From jawwadmemon at berkeley.edu Tue Dec 11 14:31:45 2007 From: jawwadmemon at berkeley.edu (Jawwad) Date: Tue, 11 Dec 2007 14:31:45 -0800 Subject: [ee122] ./MNLDaemon: Invalid argument. In-Reply-To: <475F0C60.3060509@berkeley.edu> Message-ID: Need to make sure you have samplecfg/dnon0.txt in the same dir as ./MNLDaemon usually MNLDaemon is in MNL_src_.. so you have to call it from previous dir by saying ./MNLDaemon ~//samplecfg/dnon0.txt -----Original Message----- From: ee122-bounces at ICSI.Berkeley.EDU [mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Jonathan D. Ellithorpe Sent: Tuesday, December 11, 2007 2:17 PM To: ee122 at ICSI.Berkeley.EDU Subject: [ee122] ./MNLDaemon: Invalid argument. I'm trying to run mnldaemon on sphere.cs.berkeley.edu, and when I try ./MNLDaemon samplecfg/dnon0.txt the machine says that the argument is invalid. Anybody know what's going on? I've recompiled for sphere and the daemon is in a separate folder (MNLSphere on sphere versus MNLc199 for c199). Thanks! Jonathan _______________________________________________ ee122 mailing list ee122 at mailman.ICSI.Berkeley.EDU http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 From jde at berkeley.edu Tue Dec 11 14:42:31 2007 From: jde at berkeley.edu (Jonathan D. Ellithorpe) Date: Tue, 11 Dec 2007 14:42:31 -0800 Subject: [ee122] ./MNLDaemon: Invalid argument. In-Reply-To: References: Message-ID: <475F1257.2070109@berkeley.edu> Hmm... my executable in in the parent folder of the src (i.e. MNLSphere) because I compiled from the MNLSphere directory make -f Makefile.MNL so then my executable is in the same directory as the samplecfg directory. For the sake of being as clear as possible, here were my steps: mkdir MNLSphere mv MNL_0_1a.tar MNLSphere cd MNLSphere tar -xvf MNL_0_1a.tar make -f Makefile.MNL ./MNLDaemon samplecfg/dnone0.txt Jonathan Jawwad wrote: > Need to make sure you have samplecfg/dnon0.txt in the same dir as > ./MNLDaemon usually MNLDaemon is in MNL_src_.. so you have to call it from > previous dir by saying > ./MNLDaemon ~//samplecfg/dnon0.txt > > -----Original Message----- > From: ee122-bounces at ICSI.Berkeley.EDU > [mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Jonathan D. Ellithorpe > Sent: Tuesday, December 11, 2007 2:17 PM > To: ee122 at ICSI.Berkeley.EDU > Subject: [ee122] ./MNLDaemon: Invalid argument. > > I'm trying to run mnldaemon on sphere.cs.berkeley.edu, and when I try > ./MNLDaemon samplecfg/dnon0.txt the machine says that the argument is > invalid. > > Anybody know what's going on? I've recompiled for sphere and the daemon > is in a separate folder (MNLSphere on sphere versus MNLc199 for c199). > > Thanks! > > Jonathan > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > From ericcheung at berkeley.edu Tue Dec 11 14:42:40 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Tue, 11 Dec 2007 14:42:40 -0800 Subject: [ee122] ./MNLDaemon: Invalid argument. In-Reply-To: References: Message-ID: <475F1260.7070806@berkeley.edu> I think it's dnone0.txt, not dnon0.txt. Jawwad wrote: > Need to make sure you have samplecfg/dnon0.txt in the same dir as > ./MNLDaemon usually MNLDaemon is in MNL_src_.. so you have to call it from > previous dir by saying > ./MNLDaemon ~//samplecfg/dnon0.txt > > -----Original Message----- > From: ee122-bounces at ICSI.Berkeley.EDU > [mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Jonathan D. Ellithorpe > Sent: Tuesday, December 11, 2007 2:17 PM > To: ee122 at ICSI.Berkeley.EDU > Subject: [ee122] ./MNLDaemon: Invalid argument. > > I'm trying to run mnldaemon on sphere.cs.berkeley.edu, and when I try > ./MNLDaemon samplecfg/dnon0.txt the machine says that the argument is > invalid. > > Anybody know what's going on? I've recompiled for sphere and the daemon > is in a separate folder (MNLSphere on sphere versus MNLc199 for c199). > > Thanks! > > Jonathan > _______________________________________________ > 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 simtan at berkeley.edu Tue Dec 11 15:19:36 2007 From: simtan at berkeley.edu (Simon Tan) Date: Tue, 11 Dec 2007 15:19:36 -0800 Subject: [ee122] ./MNLDaemon: Invalid argument. In-Reply-To: <475F1257.2070109@berkeley.edu> References: <475F1257.2070109@berkeley.edu> Message-ID: If the machine says "Invalid argument", it typically means you need to recompile. MNL has its own 'usage' statement if you get its arguments wrong. Compile using gmake. On Tue, 11 Dec 2007 14:42:31 -0800, Jonathan D. Ellithorpe wrote: > Hmm... my executable in in the parent folder of the src (i.e. MNLSphere) > because I compiled from the MNLSphere directory > > make -f Makefile.MNL > > so then my executable is in the same directory as the samplecfg > directory. > > For the sake of being as clear as possible, here were my steps: > > mkdir MNLSphere > mv MNL_0_1a.tar MNLSphere > cd MNLSphere > tar -xvf MNL_0_1a.tar > make -f Makefile.MNL > ./MNLDaemon samplecfg/dnone0.txt > > Jonathan > > Jawwad wrote: >> Need to make sure you have samplecfg/dnon0.txt in the same dir as >> ./MNLDaemon usually MNLDaemon is in MNL_src_.. so you have to call it >> from >> previous dir by saying >> ./MNLDaemon ~//samplecfg/dnon0.txt >> >> -----Original Message----- >> From: ee122-bounces at ICSI.Berkeley.EDU >> [mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Jonathan D. >> Ellithorpe >> Sent: Tuesday, December 11, 2007 2:17 PM >> To: ee122 at ICSI.Berkeley.EDU >> Subject: [ee122] ./MNLDaemon: Invalid argument. >> >> I'm trying to run mnldaemon on sphere.cs.berkeley.edu, and when I try >> ./MNLDaemon samplecfg/dnon0.txt the machine says that the argument is >> invalid. >> >> Anybody know what's going on? I've recompiled for sphere and the daemon >> is in a separate folder (MNLSphere on sphere versus MNLc199 for c199). >> >> Thanks! >> >> Jonathan >> _______________________________________________ >> 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 -- ~Simon Tan >> undergraduate at UC Berkeley Source: simtan at berkeley.edu From fowler at eecs.berkeley.edu Wed Dec 12 00:43:23 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 12 Dec 2007 00:43:23 -0800 Subject: [ee122] Project 2 grading/feedback Message-ID: <330471bf0712120043g246ea59dr117d44e92ecae7fd@mail.gmail.com> Hi all - I need a few last things from you. Send the following things directly to me. * If you are NOT done submitting, send me a note ASAP and let me know to ignore any current submissions and to expect your final submission. * I know many of you became very invested in your project over the last few weeks, and if you would like *feedback* (beyond your grade and points breakdown), let me know by sending me an email that requests feedback, including your inst id. I make no promises that your feedback will be returned to you before January. I, unfortunately, as soon as grading is done, have a deadline outside of this class that will require all of my time and then some. The feedback will be informal, but will be feedback nonetheless. If you would like this, let me know. Otherwise, you'll just get your grade, and if you desire, your points breakdown. You need to tell me if you do want feedback because that requires special handling. Thanks, Lisa From dank at EECS.Berkeley.EDU Wed Dec 12 06:07:40 2007 From: dank at EECS.Berkeley.EDU (Carrell Killebrew) Date: Wed, 12 Dec 2007 06:07:40 -0800 Subject: [ee122] project 1b graded Message-ID: Check glookup and also check your instructional account email https://imail.eecs.berkeley.edu/src/login.php Also see my section webpage http://inst.eecs.berkeley.edu/~ee122-tb/ Lot of things to see, eh? Sorry for taking so long. Daniel From ericcheung at berkeley.edu Wed Dec 12 12:08:12 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Wed, 12 Dec 2007 12:08:12 -0800 Subject: [ee122] hw4 solutions? Message-ID: <47603FAC.5060205@berkeley.edu> When will solutions for hw4 be posted? Thanks - Eric From jortiz at cs.berkeley.edu Wed Dec 12 12:32:01 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Wed, 12 Dec 2007 12:32:01 -0800 Subject: [ee122] hw4 solutions? In-Reply-To: <47603FAC.5060205@berkeley.edu> References: <47603FAC.5060205@berkeley.edu> Message-ID: Today. On Dec 12, 2007 12:08 PM, Eric Cheung wrote: > When will solutions for hw4 be posted? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Wed Dec 12 21:58:10 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 12 Dec 2007 21:58:10 -0800 Subject: [ee122] solutions for Homework #4 Message-ID: <200712130558.lBD5wFcF027988@pork.ICSI.Berkeley.EDU> These are now available at: http://inst.eecs.berkeley.edu/%7Eee122/fa07/hw/hw4-soln.pdf Note, the web server on that machine appears to be down at the moment, so I've also put a copy at: http://www.icir.org/vern/tmp/hw4-soln.pdf - Vern From pavyedav at berkeley.edu Thu Dec 13 18:26:51 2007 From: pavyedav at berkeley.edu (Pavan Yedavalli) Date: Thu, 13 Dec 2007 18:26:51 -0800 Subject: [ee122] Coding on Final Exam? Message-ID: <8ec15b790712131826p766256eq4e38640d7eb0fbf3@mail.gmail.com> I remember the professor saying at some point something about there being coding on the final exam. Is this true? If so, what sort of material should we review? Both projects? -- Pavan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071213/4be332d6/attachment.html From vern at cs.berkeley.edu Thu Dec 13 23:52:29 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Thu, 13 Dec 2007 23:52:29 -0800 Subject: [ee122] Coding on Final Exam? In-Reply-To: <8ec15b790712131826p766256eq4e38640d7eb0fbf3@mail.gmail.com> (Thu, 13 Dec 2007 18:26:51 PST). Message-ID: <200712140752.lBE7qYMu019770@pork.ICSI.Berkeley.EDU> > I remember the professor saying at some point something about there being > coding on the final exam. Is this true? No, there won't be. It was in scope for the midterm, but for the final any issues regarding coding have already been amply covered by the class projects ... Vern From vern at cs.berkeley.edu Fri Dec 14 08:59:12 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 14 Dec 2007 08:59:12 -0800 Subject: [ee122] office hours today Message-ID: <200712141659.lBEGxHbp030333@pork.ICSI.Berkeley.EDU> Turns out I'll be able to have my regular 3-4PM office hours today after all, so feel free to stop by. Vern From vern at cs.berkeley.edu Sun Dec 16 10:47:58 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 16 Dec 2007 10:47:58 -0800 Subject: [ee122] last year's final Message-ID: <200712161848.lBGIm3JD008782@pork.ICSI.Berkeley.EDU> I received a request for a copy of last year's final without the solutions, so I've made this available from: http://www.icir.org/vern/tmp/ee122-fa06-final.pdf - Vern From vern at cs.berkeley.edu Sun Dec 16 11:18:02 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 16 Dec 2007 11:18:02 -0800 Subject: [ee122] IEEE providing some breakfast munchies for Tuesday morning's final Message-ID: <200712161918.lBGJI7jG009298@pork.ICSI.Berkeley.EDU> FYI, I've heard from Aaron Staley (IEEE Berkeley Student Chair) that thanks to IEEE's "morning finals breakfast" program, they plan to bring juice and pastries to 277 Cory on Tuesday morning, at a bit before 8AM. Vern From huntingtonsurfca at gmail.com Sun Dec 16 16:23:38 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sun, 16 Dec 2007 16:23:38 -0800 Subject: [ee122] ECN and congestion Message-ID: I propose the scenario: Alice and Bob both support ECN in their TCP/IP layers. Alice sends a message to bob over TCP, and while sending packets, one of them is labeled with the ECN marking congestion in the network. Bob sees this first and sends the ACK with the congestion also noted. For ECN to work (as it is described in RFC 3168), does Alice have to change her next outgoing packets to indicate that she understood and took measures to comply with ECN? I've been reading the RFC but feel a little overwhelmed by its knowledge. Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071216/702181ae/attachment.html From vern at cs.berkeley.edu Sun Dec 16 16:55:55 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 16 Dec 2007 16:55:55 -0800 Subject: [ee122] ECN and congestion In-Reply-To: (Sun, 16 Dec 2007 16:23:38 PST). Message-ID: <200712170056.lBH0u0JW014730@pork.ICSI.Berkeley.EDU> > For ECN to work (as it is described in RFC 3168), does Alice have to change > her next outgoing packets to indicate that she understood and took measures > to comply with ECN? Yes. Alice uses the new "CWR" (Congestion Window Reduced) bit in the TCP header to signal this to Bob. That said, you are *not* required to understand the detailed workings of ECN, just that it provides a means by which a router can signal that a connection should behave the same as it would have had a given packet been dropped. Vern From vern at cs.berkeley.edu Sun Dec 16 23:20:10 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 16 Dec 2007 23:20:10 -0800 Subject: [ee122] pre-final office hours Message-ID: <200712170720.lBH7KFLD018476@pork.ICSI.Berkeley.EDU> Tomorrow I will have office hours 3-4PM (send email for an appointment earlier in the afternoon if needed), and Lisa will have extra office hours 2-3PM (in 283E Soda, as usual). Vern From jortiz at cs.berkeley.edu Sun Dec 16 23:23:58 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Sun, 16 Dec 2007 23:23:58 -0800 Subject: [ee122] pre-final office hours In-Reply-To: <200712170720.lBH7KFLD018476@pork.ICSI.Berkeley.EDU> References: <200712170720.lBH7KFLD018476@pork.ICSI.Berkeley.EDU> Message-ID: I may also be holding extra office hours after 5pm. I'll be sure to let everyone know where. jorge On Dec 16, 2007 11:20 PM, wrote: > Tomorrow I will have office hours 3-4PM (send email for an appointment > earlier in the afternoon if needed), and Lisa will have extra office > hours 2-3PM (in 283E Soda, as usual). > > Vern > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Sun Dec 16 23:33:45 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 16 Dec 2007 23:33:45 -0800 Subject: [ee122] minor corrections to solutions for Homeworks #3 and #4 Message-ID: <200712170733.lBH7Xolq018632@pork.ICSI.Berkeley.EDU> Appended are corrections/additions to the solutions for a couple of problems in Homeworks #3 and #4 (both found by students - kudos!, and apologies for the original errors). Vern [ For Homework #3, the first change is simply "4,x" in the Dijkstra table instead being "4,v". ] Index: hw3_soln.tex =================================================================== --- hw3_soln.tex (revision 299) +++ hw3_soln.tex (working copy) @@ -132,13 +132,13 @@ Step & N' & D(s),p(s) & D(t),p(t) & D(u),p(u) & D(v),p(v) & D(w),p(w) & D(y),p(y) &D(z),p(z)\\ \hline 0 & x & $\infty$ & $\infty$ & $\infty$ & 3,x & 6,x & 6,x & $\infty$ \\ - 1 & xv & $\infty$ & 7,v & 6,v & 3,x & 6,x & 4,x & $\infty$ \\ + 1 & xv & $\infty$ & 7,v & 6,v & 3,x & 6,x & 4,v & $\infty$ \\ - 2 & xvy & $\infty$ & 7,v & 6,v & 3,x & 6,x & 4,x & 18,y \\ + 2 & xvy & $\infty$ & 7,v & 6,v & 3,x & 6,x & 4,v & 16,y \\ - 3 & xvyu & 10,u & 7,v & 6,v & 3,x & 6,x & 4,x & 18,y \\ + 3 & xvyu & 10,u & 7,v & 6,v & 3,x & 6,x & 4,v & 16,y \\ - 4 & xvyuw & 10,u & 7,v & 6,v & 3,x & 6,x & 4,x & 18,y \\ + 4 & xvyuw & 10,u & 7,v & 6,v & 3,x & 6,x & 4,v & 16,y \\ - 5 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,x & 12,t \\ + 5 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,v & 12,t \\ - 6 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,x & 12,t \\ + 6 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,v & 12,t \\ - 7 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,x & 12,t \\ + 7 & xvyuwt & 8,t & 7,v & 6,v & 3,x & 6,x & 4,v & 12,t \\ \hline \end{tabular} } @@ -149,7 +149,7 @@ \small \begin{tabular}{|r|cccccccc|} \hline - Step & N' & D(s),p(s) & D(t),p(t) & D(u),p(u) & D(v),p(v) & D(w),p(w) & D(y),p(y) &D(z),p(z)\\ + Step & N' & D(x),p(x) & D(t),p(t) & D(u),p(u) & D(v),p(v) & D(w),p(w) & D(y),p(y) &D(z),p(z)\\ \hline 0 & st & $\infty$ & 1,s & 4,s & $\infty$ & $\infty$ & $\infty$ & $\infty$ \\ 1 & st & $\infty$ & 1,s & 3,t & 5,t & $\infty$ & 8,t & 6,t \\ Index: hw4-soln.tex =================================================================== --- hw4-soln.tex (revision 297) +++ hw4-soln.tex (working copy) @@ -158,6 +158,16 @@ This gives us \textbf{2 messages per 3 slots}. + However, an alternative interpretation + is that B and C can send ACKs to + A and D simultaneously, because while + these transmissions overlap at B and C, + they don't at A and D, and therefore + the messages will be successfully + received. In this case, we can + get \textbf{2 messages per 2 slot = + 1 message per slot}. + \item We have: \begin{description} \item[slot 1] Message from @@ -167,6 +177,18 @@ \end{description} This again gives us \textbf{2 messages per 3 slots}. + + Again, an alternative interpretation + is that it's possible to synchronize + the sending of data from C + $\rightarrow$ D with the transmission + of \emph{ACKs} from B $\rightarrow$ A, + and of data from A $\rightarrow$ B with + ACKs from D $\rightarrow$ C. In this + case, on average we can again send + \textbf{2 messages per 2 slot = + 1 message per slot}. + \end{enumerate} \end{description} \end{enumerate} From nguyenjp at berkeley.edu Mon Dec 17 15:14:06 2007 From: nguyenjp at berkeley.edu (John Nguyen) Date: Mon, 17 Dec 2007 15:14:06 -0800 (PST) Subject: [ee122] Notes during Final In-Reply-To: <200712170733.lBH7Xolq018632@pork.ICSI.Berkeley.EDU> References: <200712170733.lBH7Xolq018632@pork.ICSI.Berkeley.EDU> Message-ID: <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> Are we allowed to have notes during the final? If so, please specify the notes policy. Thank you! -John From ericcheung at berkeley.edu Mon Dec 17 15:17:45 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Mon, 17 Dec 2007 15:17:45 -0800 Subject: [ee122] Notes during Final In-Reply-To: <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> References: <200712170733.lBH7Xolq018632@pork.ICSI.Berkeley.EDU> <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> Message-ID: <47670399.50506@berkeley.edu> The final review lecture slides say "You can have two regular-sized (8.5" x 11") sheets of paper with notes on both sides" John Nguyen wrote: > Are we allowed to have notes during the final? If so, please specify the > notes policy. Thank you! > > -John > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 From jortiz at cs.berkeley.edu Mon Dec 17 15:34:01 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Mon, 17 Dec 2007 15:34:01 -0800 Subject: [ee122] [EE122] Extra Office hours Message-ID: 5-6pm Today 711 Soda. jorge From blwang at berkeley.edu Mon Dec 17 15:43:31 2007 From: blwang at berkeley.edu (Ben Wang) Date: Mon, 17 Dec 2007 15:43:31 -0800 Subject: [ee122] Notes during Final In-Reply-To: <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> References: <200712170733.lBH7Xolq018632@pork.ICSI.Berkeley.EDU> <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> Message-ID: i think we are allowed 2 pages. but can we type them up? On 12/17/07, John Nguyen wrote: > Are we allowed to have notes during the final? If so, please specify the > notes policy. Thank you! > > -John > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > -- cheers Ben Wang From vern at cs.berkeley.edu Mon Dec 17 16:36:45 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 17 Dec 2007 16:36:45 -0800 Subject: [ee122] Notes during Final In-Reply-To: <4322.75.61.104.109.1197933246.squirrel@calmail.berkeley.edu> (Mon, 17 Dec 2007 15:14:06 PST). Message-ID: <200712180036.lBI0aoSB005268@pork.ICSI.Berkeley.EDU> > Are we allowed to have notes during the final? If so, please specify the > notes policy. Thank you! Yes, two sheets: You may use two 8.5" by 11" double-sided crib sheets, as densely packed with notes, formulas, and diagrams as you wish. - Vern From vern at cs.berkeley.edu Mon Dec 17 16:37:40 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 17 Dec 2007 16:37:40 -0800 Subject: [ee122] Notes during Final In-Reply-To: (Mon, 17 Dec 2007 15:43:31 PST). Message-ID: <200712180037.lBI0bjID005290@pork.ICSI.Berkeley.EDU> > i think we are allowed 2 pages. but can we type them up? Yes, with the constraint being "as long as you don't shrink them such that you need an aid to read them beyond what you routinely use." Vern From fowler at eecs.berkeley.edu Thu Dec 20 21:24:27 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 20 Dec 2007 21:24:27 -0800 Subject: [ee122] Proj2b Grades in glookup Message-ID: <330471bf0712202124i75b38a20s948e66fa1cc37073@mail.gmail.com> Your grades have been submitted in glookup. Breakdowns to come shortly. Number of grades reported: 80 Mean: 86.3 Standard deviation: 48.4 Minimum: 0.0 1st quartile: 40.1 2nd quartile (median): 95.3 3rd quartile: 126.0 Maximum: 160.0 Max possible: 160.0 Extra credit was reported in p2extra, also viewable in glookup. Have a great break! -Lisa From fowler at eecs.berkeley.edu Thu Dec 20 21:31:30 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 20 Dec 2007 21:31:30 -0800 Subject: [ee122] ***Inst accounts expire Fri Dec 21 9am*** Message-ID: <330471bf0712202131t4917fd5ew703e915f9ad8fbb9@mail.gmail.com> This means check your grades *TONIGHT*!! -Lisa From fowler at eecs.berkeley.edu Thu Dec 20 22:45:53 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 20 Dec 2007 22:45:53 -0800 Subject: [ee122] Score Breakdown Clarification Message-ID: <476B6121.7050603@eecs.berkeley.edu> By "Nov 21" I really did mean tomorrow, Dec 21 :) Penalties are multipliers. If your score was a "2" in the "Code Penalty" section, that means you lost 2x10% Somehow for some of you the formatting got terribly munged on the way out. If it's too intolerably legible let me know and I'll send it to you again, prettified. As a "happy holidays" gesture and a sign that we really did see how hard you worked on this project, for Project 2b, we changed the late penalty calculation to only penalize the points you earned. Therefore, you did not immediately start with a -16 if your project was 1 day late -- instead, the -10% penalty was applied after the fact to your raw score. Enjoy! -Lisa From fowler at eecs.berkeley.edu Fri Dec 21 00:24:24 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 21 Dec 2007 00:24:24 -0800 Subject: [ee122] ***Inst accounts expire Fri Dec 21 9am*** In-Reply-To: <330471bf0712202131t4917fd5ew703e915f9ad8fbb9@mail.gmail.com> References: <330471bf0712202131t4917fd5ew703e915f9ad8fbb9@mail.gmail.com> Message-ID: <330471bf0712210024j4509a258wfdb27f25ff3f10ed@mail.gmail.com> OK, so you can check your grades for a little while longer. They said that you'll have limited access to your inst account until January -- it will merely automatically run glookup for you. -Lisa On Dec 20, 2007 9:31 PM, Lisa Fowler wrote: > This means check your grades *TONIGHT*!! > > -Lisa > From vern at cs.berkeley.edu Fri Dec 21 17:08:28 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 21 Dec 2007 17:08:28 -0800 Subject: [ee122] final exam solutions & scores Message-ID: <200712220108.lBM18Xaq013643@pork.ICSI.Berkeley.EDU> Solutions for the final exam are now available at: http://inst.eecs.berkeley.edu/%7Eee122/fa07/notes/final-soln.pdf I've entered scores into glookup. These should include any adjustments that some of you have discussed with me. I haven't confirmed that the weightings in glookup are correct (and they probably were not correct in the recent past), so those of you who are figuring your class ranking, be advised it may not be accurately reflected. I aim to have grades determined by tomorrow, though it could slip until Sunday. Best wishes for the holidays ... ... and thanks for all of your hard work! Vern From vern at cs.berkeley.edu Sat Dec 22 20:02:16 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sat, 22 Dec 2007 20:02:16 -0800 Subject: [ee122] grades have now been final Message-ID: <200712230402.lBN42Lwb003489@pork.ICSI.Berkeley.EDU> Again, best wishes for the holidays and the New Year ... Vern