Class 33: RPC

Held Friday, April 21, 2000

Overview

Today's outline does not yet have an overview. Please let me know if you think it should have one.

Notes

• 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 assignment 9.
• I've updated the due date on assignment 8
• Printouts of assignment 7 are due today.

Contents

• TCP Setup, Continued
• Shutting Down TCP Connections
• Sliding Window
• Request/Response

Summary

TCP Setup, Continued

• What happens during setup if packets are lost?
  • Does the book say?
  • Does the diagram say?

Shutting Down TCP Connections

• 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 ``stop receiving''.
• Whoever closes first is at a slight disadvantage; it needs to stay alive to catch extra packets floating through the Internet.

Sliding Window

• 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 values.
  • Further evidence that computer science is an experimental discipline: ``Let's see whether this policy works!''

Request/Response

• 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 rejoined. How?