Class 03: Network Building Blocks

Held Friday, January 28, 2000

Overview

Today we continue our study of networks by considering protocol graphs and the Internet layered model.

Notes

• I'm hoping that there are more of you interested in summer work than attended yesterday's presentation.
  • You can find information on my research program at http://www.cs.grinnell.edu/~rebelsky/Department/samr-summer-2000.html
  • Note that there a list of summer REU programs is available at http://cerebro.xu.edu/summerinternships.html.
    • One of the REU programs has a deadline of January 31
    • Two have deadlines of February 7
• Monday at noon in Science 2413, the Computer Science Bag Lunch Film festival will resume with ``The Future of Computing: Seizing the Future We Want''. You may find it interesting to attend.
• There are no specific readings in The C Programming Language for Monday. Simply start reading through the book.
• I've heard that there are only two students in the Exotic Programming Languages group this semester. Since the group is studying Python, a ``hot'' Web programming language, I'd expect to see more.
• I received some requests that I not give in-class exams this semester, so I won't. Expect to see changes to the syllabus.
• I've started to go over your surveys, but haven't finished.
  • You can find some initial responses online.
  • Some of you (particularly those of you with just 152 as background) are worried that this will be over your head. I'll do my best to keep the pace reasonable, and the material should be understandable.
  • Most of you do your best studying before 10 p.m. That is certainly different than I'd expect from CS folks :-)

Contents

• Networking Background
  • Protocol Graphs
  • TCP/IP
  • Service Models
• Sockets
  • Sockets in C

Summary

• The Internet model
• Protocol graphs
• Introduction to sockets
• Introduction to C

Networking Background

Protocol Graphs

• While it the layered model seems to imply that there is one protocol at every level, in truth the model simply categorizes protocols.
  • If you think about it, we have already identified a number of application-level protocols.
• The layering simply gives us general attributes of a protocol. The particular characteristics are specified as part of the protocol.
• A protocol at one level may take advantage of one or more protocols at a lower level and service one or more protocols at higher levels.
• Hence, we arrange protocols into protocol graphs.
• In a well-designed network, it is easy to add new protocols (nodes) to these graphs.
• In fact, if you have a protocol that provides the same services as another protocol, you should be able to use it to support the same ``higher layer'' protocols.

TCP/IP

• Surprisingly (or, perhaps, not so surprisingly), almost no one uses the OSI model (and corresponding implementation).
• The platform we mostly use is TCP/IP, which has its own model with many fewer layers.
  • Host-to-network: get packets between hosts
  • Internet: get packets from end to end, even if they travel along different paths
  • Transport: more services
  • Application: high-level protocols
• And more details ...
• Host-to-network
  • Sorry, we're software people
• Internet
  • Get packets from here to there, across different networks.
  • Routing
  • Similar to OSI network layer
• Transport
  • Two basic services: TCP (transmission control) and UDP (user datagram).
  • TCP
    • Reliable
    • Connection-oriented
    • Byte stream
    • Fragmentation and reassembly
    • Flow control
  • UDP
    • Unreliable
    • Connectionless
    • Fast?
• Application
  • Terminal
  • File transfer
  • Electronic mail
  • Domain names
  • News
  • Hypertext
  • ...

Service Models

• There are (at least) two basic models of operations: an interrupt-driven model and a blocking model.
• In the interrupt-driven model, programs continue running and are then ``interrupted'' with messages when messages arrive.
• A typical interrupt of operations is
  • Request -- ask a service to do some work (send a message)
  • Indication -- received by the service (interruption)
  • Response -- sent by the service, in response to a request (send a message)
  • Confirm -- received by original requeste (interruption)
• Example: phone conversation.
• Note that this effectively requires the network programmer to think in terms of interrupts or events. Most programmers don't, so some models provide a different set of operations.
• The programmer might instead simply say: ``Get a message'' and block until the message arrives. We might phrase such a model in terms of two basic operations:
  • Send
  • Receive

Sockets

• Sockets are a network API devised for the Unix system.
• In the OSI model, We might say that they provide session level services.
• Sockets provide bidirectional connections.
• Nonetheless, they follow a client-server structure for creating new connections.
• A server
  • Creates a new socket
  • Specifies how many clients can queue up on that socket
  • Listens for a connection
  • Is told when a connection is made
• A client
  • Creates a new socket
  • Specifies an address of a server
  • Connects to the server
• Both client and server can send and receive on the socket.
• Note that this might imply two different network models:
  • Servers are signalled when new connections are available.
  • Servers and clients explicitly call a (typically blocking) receive function.

Sockets in C

• Sockets were originally developed for use with the C programming language.
• The C implementation seems like an appropriate way to get started with
  • networking services
  • the C programming language
• We'll step through the examples from pp. 45-48 of the book and consider both what they say and what C you need to know to understand them.