CS325 Exam #1 Solutions: ------------------------ Problem 1: ---------- 1a) Why does it make sense for the Internet to use packet switching instead of circuit switching? Packet switching allows us to make more efficient use of resources: We can all share the bandwith of a network connection dynamically instead of resorting to fixed allocations that waste bandwidth when folks don't use their fixed share. It also allows for more robust networks, since each individual packet finds its own way through the network and can adapt to damage or slowdowns on specific links. 1b) By the time an HTTP GET request is sent, we’ve already connected a socket to a host machine, so what purpose does the Host: header have in an HTTP GET request? We connect to the server via an IP address, but that server could potentially hosting web sites for several different domains (e.g. math.pugetsound.edu and cs.pugetsound.edu). We need the Host header so we're clear about which domain's content we're after. (The Host: header was optional in HTTP 1.0, but is required in HTTP 1.1 even if the server isn't hosting multiple domains.) 1c) What is the purpose of DNS? What sort of information does a root DNS server store and what kinds of questions can it answer? The Domain Name System (DNS) translates machine names like cs.pugetsound.edu into their corresponding IP addresses. Information on these mappings is distributed throughout the DNS hierarchy though -- the top-level .edu server doesn't know the IP address for cs.pugetsound.edu, but it knows the IP address for our local DNS server, which records our local mappings. The question asked about a ROOT server though: Root servers delegate DNS queries to the appropriate top-level domain servers. For example, a request to find the IP address for cs.pugetsound.edu would be passed off to the .edu top-level domain server. The root server, therefore, only stores mappings between top-level domains (e.g. .com, .edu, .gov) and the addresses of the servers that know specifics about each of those domains. Problem 2: ---------- a) The PPP will require an "order pizza" message that includes the name of the person ordering the pizza, and specifics about their order. Since orders can be refused, we also need a response message specifying whether the order was approved or rejected. I've decided to use a third message type to notify users that a full pizza has been ordered, though you could also lump this in with the response type. b) My design puts the packet type at the front, as a short string, and subsequent fields within the packet are separated by \r\n characters. An order message looks like: ORDER\r\nUSER NAME\r\nPIZZA TYPE\r\nINTEGER Where the user name and pizza type can have spaces in them, and capitalization isn't important. Pizza types will be short strings like "sausage and pepperoni", though we'd need to standardize options, perhaps by looking at the restaurant's menu. The final field is an integer denoting the number of slices ordered. If users want several different types of pizza, they'll need to send multiple ORDER packets. The response looks like: RESPONSE\r\nSTATUS Where status is either "OK", or "NO". In the case of OK, it's followed by a space and the number of slices accepted for this order. So, for example, if I order 27 slices of anchovy and walnut pizza, the server might decide to accept 16 slices and respond with: RESPONSE\r\nOK 16 The "ORDERED" response is sent once a pizza has actually been ordered by the server: ORDERED\r\nPIZZA TYPE c) Clearly some state is required on the *server*. The server needs to keep track of how much pizza you've ordered, how much you owe, and the global state of the orders (have we achieved enough pepperoni slice orders for a full pizza yet?). However, in this design, the protocol itself is STATELESS since the server doesn't need to remember anything in order to determine what the client is allowed to say or when. The client can only send ORDER messages, and can send those at any time without logging in, so each client interaction with the server is INDEPENDENT. That's what stateless means. (In other words, the "state" required is involved in the database, and not to implement the protocol.) Problem 3: ---------- If you realized this was just about persistance, and that hosts could still use exponential backoff after collisions: a) This might not be a bad idea on networks that are always moderately loaded, and in which every host is using the same approach. It would help ensure that we'd avoid collisions when a few hosts all want to send at the same time. If only some of the hosts are using this new approach, the only time it might be an advantage is if lots of people want to send -- the "traditional" hosts will collide and back off to larger window sizes while the "new" hosts don't, potentially giving the new approach an advantage. (Though, if too many "new" hosts are competing, four slots won't necessarily be enough to avoid a collision.) b) With all systems using the new approach it forces hosts to wait even if there isn't any competition, wasting bandwidth. If only some of the hosts are using this approach, they're at a disadvantage on lightly loaded networks, where "normal" systems would send without waiting. Problem 3x: ----------- If you assumed that we didn't do exponential backoff, and that we never waited more than 0..3 slots, then: a) If all hosts are using the new approach, there would be an advantage on moderately loaded networks, where 0..3 was the "right" size for the window given the level of contention. We'd use that window size automatically, whereas traditional Ethernet implementations would have to have a couple of collisions first before getting to that window size. If we were in a mixed environment, there would potentially be advantages in a heavily loaded network. If the traditional hosts worked their window up to sizes larger than 0..3, hosts using the new approach would have an advantage over them as long as there weren't too many "new" hosts trying to send. b) With all systems using the new approach it forces hosts to wait even if there isn't any competition, wasting bandwidth. If only some of the hosts are using this approach, they're at a disadvantage on lightly loaded networks, where "normal" systems would send without waiting. Whether we're in a mixed environment or not, if too many hosts are trying to send and we can't expand the window size, we'd be locked into a long series of collisions.