CS325 Exam #1 Solutions:
------------------------

Problem 1:
----------

1a) Why does the Data Link layer have to do framing? Why can’t Data Link layer
entities just send streams of bits?

Framing is the process of building a group of bits, adding any relevant header and/or
checksum data, and marking the start and end of the frame (packet) with clearly
identifiable bit sequences. Framing helps us with all of the functions of a link
layer: It's clear when transmissions start and end, it allows for reliable
transmission since we can use checksums and retransmissions of frames to get data
across an unreliable connection, and we can implement flow control by holding off on
the transmission of a future frame until the current frame has been acknowledged.

1b)  You'd use sendto() when using UDP, since otherwise it wouldn't be clear to whom 
you were sending the packet. In TCP, since you connect() your socket to a specific 
destination machine, there's no need to keep specifying the destination address on 
each send so you'd use send(). 


c)  SMTP sends outgoing mail. It pushes mail from "my" system to the server in charge 
of email for my recipient. IMAP is used by the recipient to maintain a consistent
view of their emails across all of their devices.



Problem 2:
----------

TQTP is a pretty simple protocol: We need to be able to start a game (and specify the
number of guesses allowed), and then have a way to ask questions and to get a
response. One could imagine adding some extra features, like a "game over" message
that the server sends if the user hits 20 questions, though it would be possible to
have both the client and the server track the number of guesses. In that case, both
can detect end-of-game without a special message.

a)  My implementation will have four message types:

    A "Game Start" message that asks the server to initiate a game, and contains the 
    number of guesses that should be allowed
    
    A "Game Response" message that the server sends back to the client. If it's willing
    to play a game, this will let the user know it's ok to start guessing.
    
    A "Question" message where the user sends their question as a string
    
    A "Question Response" message that the server sends in response to a 
    question message. In general we're expecting a YES or NO as a result,
    but it could also be news that we've won or lost the game.
    

b)  I'm going to adopt SMTP's approach of using a short, fixed-length string to
identify the packet type, followed by the relevant data. The overall packet structure
is therefore:

    TYPE\r\nDATA
    
where the DATA field is variable length. Possible TYPE values are:

    STRT - start a game (sent from client to server)
    GAME - server's response to a STRT message
    QUES - client asks a question
    RESP - server sends a response to a question
    
A STRT message carries the digits of an integer as its DATA payload. GAME carries a
YES or NO as its payload. QUES has the text of the question as its DATA, and RESP has
YES, NO, WIN or IGNORED as its payload. (The server sends IGNORED if the user keeps 
asking questions after reaching the limit, or something other than a yes/no question.)
    
c)  Implementing this protocol correctly requires state, since we must first start a
game before we begin playing. The client is only allowed to send a QUES message if it
has already sent a STRT message and gotten a GAME\r\nYES response. In my
implementation, since the server sends a RESP\r\nIGNORED message if I take too many
guesses, the protocol also requires that the remaining number of guesses be tracked.


Problem 3:
----------

a)  Expanding linearly is a more cautious approach than Ethernet's exponential
backoff. On a heavily loaded network, where we would expect frequent collisions, the
hosts using the standard approach will quickly end up with much larger window sizes
than the host using the linear rule. That will give the "linear host" an unfair
advantage as it will get more frequent chances to broadcast than its peers. On a
lightly loaded network, where window sizes don't get larger than 0..0 or 0..1 there
will be no difference between the linear and exponential backoff approaches.

b)  Remembering the window size seems like a good idea, rather than having to
re-expand our window each time we have something to send on a heavily loaded network,
but it's never going to be a good idea. For one thing, it locks in "worst case"
behavior -- we set our window to a value that's appropriate for the heaviest load on
the network, but if load goes down again the other hosts will be using smaller
windows and, therefore, will have a greater chance of sending than we would. Even if
the load stays high, our peers will be resetting their windows and restarting their
exponential backoff after a successful transmission. While they're expanding their
window sizes to "meet" ours, they're potentially going to have an advantage over us.