Feedback Went too quickly over the sockets API. Sorry about that - I usually try to remember the number of slides and budget time accordingly, but this time I forgot the number (and let too much time slip). However, this is one case where there's not too much damage done. Section 1.3 of the book shows how to implement a simple client and server, and it explains all of the functions pretty well. More detail than that is available in the man pages, so I don't think that this one will be too difficult to follow. If they're still not clear, bring it up in the next class or send me an e-mail, and I'll follow up. When will the machines be ready? I'm going to send in the list of accounts tomorrow morning, so please send me your info soon. I find the the support staff are usually pretty prompt, so I don't expect the delay will be an issue. Where does the socket interface fit into our multi-level layering? Does it handle dropped packets, reordering, etc? The socket() call allows you to specify the kind of socket that you want. You specify whether it's internet (PF_INET) or local to this machine (PF_UNIX), and whether it's a stream (TCP), datagram (UDP), or raw socket. If you specify an internet stream socket, you get what we normally call a TCP socket. As far as I know, the Slammer worm faked the originator/source IP address. Does this mean that it used raw sockets? I looked up the CERT advisory on this at http://www.cert.org/advisories/CA-2003-04.html and could not find any indication that it was spoofing the source addresses. What I did find was the phrase "seemingly random" when discussing what the pattern of IP addresses are for packets that a host is receiving. However, this makes sense, since infected nodes were picking targets at random -- the targets would see packets coming from infected hosts, but wouldn't be able to determine any pattern. Hence, the term "seemingly random". So, no, it doesn't look like it was spoofing, and therefore wouldn't need raw sockets. Where is microwave communication actually used? There are some cases when it's cheaper to use microwave links than to run wires. Think of remote areas like Australia, and that makes sense. It's also used in parts of the Southwestern US, by placing the sending/receiving stations at the peaks of hills. So, you get line-of-sight that way. The other places where it gets used is in environments where it's nearly impossible to run wires. For example, if a company or organization has buildings on either side of a street, it may be nearly impossible to get the city's permission to dig up the street and run a wire between the two buildings. In these cases, they can place microwave links on the two buildings and get a fast connection without administrative hassle. Microwave is limited to line-of-sight and does suffer in bad weather, but it's usually good enough for these kinds of environments. Does streaming media actually use TCP or UDP? Historically, they preferred using UDP for the reasons I mentioned in class. However, these days, most will also be capable of using TCP as well. In fact, the common ones can even use HTTP connections. What they do in the case of TCP or HTTP isn't just transferring the whole file as a stream of bytes, but rather using the connection as a reliable connection for two-way communication. They'll adjust the data rates based on round-trip time and other factors. They won't be able to observe packet loss in the way that they could using UDP, but they can still determine how long packets are taking to reach via TCP, and can then infer the quality (loss, congestion) of the link using that information. What is RFC? RFC is short for "request for comments". This is how ideas become codified into "standards" on the Internet. There's a group called the IETF, the Internet Engineering Task Force, that manages the process of people proposing ideas via RFCs. People then comment on them, and after all of the issues have been ironed out, these become standards. The main site for RFCs is http://www.ietf.org/rfc.html What is the typical solution to overcome the "copy" problem along the network stack? A global memory manager? We'll talk about this soon, but basically, the network stack (in BSD) has a type of chainable data structure called an mbuf. These allow for easy prepending, appending, and logical shifting of data. So, most of the data isn't copied physically, just logically manipulated in these chains.