Lecture 21: Sockets & Networking

1 Client/server design pattern

• A client initiates the communication by connecting to a server.
• The client sends requests to the server, and the server sends replies back. Finally, the client disconnects.
• A server might handle connections from many clients concurrently, and clients might also connect to multiple servers.

2 Network sockets

• IP Address
• Hostnames
• Port Numbers
• Network sockets
  
  • A listening socket is used by a server process to wait for connections from remote clients.
  • A connected socket can send and receive messages to and from the process on the other end of the connection. It is identified by both the local IP address and port number plus the remote address and port.

3 I/O

3.1 Buffers

• The data that clients and servers exchange over the network is sent in chunks.
• When data arrive, they go into a buffer , an array in memory that holds the data until you read it.

3.2 Streams

• The data going into or coming out of a socket is a stream of bytes.

4 Blocking

Blocking means that a thread waits (without doing further work) until an event occurs.
Socket input/output streams exhibit blocking behavior

• When an incoming socket’s buffer is empty, calling read blocks until data are available.
• When the destination socket’s buffer is full, calling write blocks until space is available.

Definition of the deadlock, where modules are waiting for each other to do something, so none of them can make any progress.

5 Wire protocols

How to design a wire protocols:

• Keep the number of different messages small. It’s better to have a few commands and responses that can be combined rather than many complex messages.
• Each message should have a well-defined purpose and coherent behavior.
• The set of messages must be adequate for clients to make the requests they need to make and for servers to deliver the results.

In order to precisely define for clients & servers what messages are allowed by a protocol, use a grammar. Here is an expamle for Http1.1:

request ::= request-line
            ((general-header | request-header | entity-header) CRLF)*
            CRLF
            message-body?
request-line ::= method SPACE request-uri SPACE http-version CRLF
method ::= "OPTIONS" | "GET" | "HEAD" | "POST" | ...
...

6 Testing client/server code

• Separate network code from data structures and algorithms
  Most of the ADTs in your client/server program don’t need to rely on networking. You should implement them as discussed above.
• Separate socket code from stream code
  A function or module that needs to read from and write to a socket may only need access to the input/output streams, not to the socket itself. This design allows you to test the module by connecting it to streams that don’t come from a socket.

---

Reference

[1] 6.005 — Software Construction on MIT OpenCourseWare | OCW 6.005 Homepage at https://ocw.mit.edu/ans7870/6/6.005/s16/