Held Friday, April 21, 2000
Today's outline does not yet have an overview. Please
let me know if you think it should have one.
- For Monday, read about RPC. We will conclude chapter 5 on Monday.
- You should also start reading chapter 6 for Monday.
- Just to keep you busy this weekend, I'd also like you to work
on part C of
- I've updated the due date on
- Printouts of
are due today.
- What happens during setup if packets are lost?
- Does the book say?
- Does the diagram say?
- Potentially a little bit more complicated
- Either side must be told by the client to close. This means
``stop sending''. It does not necessarily mean
- Whoever closes first is at a slight disadvantage; it needs to
stay alive to catch extra packets floating through the Internet.
- Some basic concerns:
- When do you send data?
- When do you send acknowledgements?
- Problems in designing sliding-window protocols at this layer:
- How do you determine the timeout?
- How many sequence numbers are enough?
- What do sequence numbers number?
- Sequence numbers number bytes.
- How many sequence numbers are enough? TCP uses 32 bits.
- Is that enough? Not on the fastest links.
- What do you do? Various tricks.
- How TCP determines timeout: Lots of guesswork looking at past
- Further evidence that computer science is an experimental
discipline: ``Let's see whether this policy works!''
- Many network applications seem to more naturally fall within
a request/response paradigm than a byte stream paradigm.
- Some examples:
- Give me that file
- Give me data that matches this pattern
- Add this data to your database
- Rather than incurring the cost of setting up and taking down connections,
it might be better to look at other protocols.
- Some basic design issues:
- Error detection and correction
- If messages are big enough, they'll need to be split and