CSci 4061Introduction to Operating Systems

Network Systems Programming

Goal:

• Enable communication between processes on

different machines.

Network Layers

• Physical Layer

• media: cat5, radio, transmits bits

• electrical, data, rates, connectors

• Link layer

• 802.3 (Ethernet),802.11 (wifi) transmits error-free

• framing, CRC codes, …

• Network layer

• Routing (path from A to B)

• Send packets; packets contain addresses

• Transport layer: systems-programming interface

applicationtransportnetworkdata linkphysical

advantage of layers?

Protocols

• Transport protocols• TCP

• Out of order pocket assembly• Re-transmits packets lost or corrupted• Connection-oriented (expensive)

• UDP• Connectionless• Unreliable

• Application protocols• Applications

• Data formats• Meaning of data• …ftp,http,etc

phone call

mailing a letter

Some network app/protocols

• E-mail

•Web

• Instant messaging

• Remote login

• P2P file sharing

•Multi-user network games

• Streaming stored video clips

• Voice over IP

• Real-time video conferencing

App-layer protocol defines

• Types of messages exchanged

• e.g. request, response

•Message syntax

• What fields in messages & how fields are delineated

•Message semantics

• Meaning of information in fields

• Rules for when and how processes send & respond to messages

HTTP Example

Request:

GET http://www.cnn.com/ HTTP/1.0

Accept: text/html If-Modified-Since:

Saturday, 15-January-2000 14:37:11

GMT

User-Agent: Mozilla/4.0

Response:

HTTP/1.0 200 OK

Date: Sat, 15 Jan 2000 14:37:12 GMT

Server: Microsoft-IIS/2.0

Content-Type: text/HTML

Content-Length: 1245

Last-Modified: Fri, 14 Jan 2000 08:25:13 GMT

This is the webpage contents ….

Addresses

• Local IPC—easy? pid, mailbox, etc

• Network communication: IP address • Machine + network interface• IPv4 a.b.c.d: 4x2^32, ~4 x 10^9 addresses

• Network layer routes packet to destination address (a.b.c.d)

• Symbolic names can be assigned to addresses to identify domains and end hosts• caesar.cs.umn.edu resolves to a.b.c.d by domain

name service (DNS)

Creating a network app

write programs that• run on (different) end systems

• communicate over network

• e.g., web server software communicates with

browser software

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

Application architectures

• Client-server

• Peer-to-peer (P2P)

Client-server architecture

server:• always-on host

• permanent IP address

• server farms for scaling

clients:• communicate with server

(know its IP address)

• may be intermittently connected

• may have dynamic IP addresses – why does a client have an IP address?

• do not communicate directly with each other

client/server

Pure P2P architecture

• no always-on server

• arbitrary end systems “directly” communicate

• peers are intermittently connected and change IP addresses could change

• Highly scalable but difficult to manage

--why?

peer-peer

Systems programming: Processes communicating

• Processes in different hosts communicate by exchanging messages, packets are message fragments

Client process: process that initiates communication

Server process: process that waits to be contacted

Abstraction:

• Socket – abstraction of a communication endpoint

Sockets

• Process sends/receives messages to/from its socket

• socket analogous to door• sending process shoves

message out door

• sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process

process

TCP with

buffers,

variables

socket

host or

server

process

TCP with

buffers,

variables

socket

host or

server

Internet

controlled

by OS

controlled by

app developer

• API:

• (1) choice of transport protocol

• (2) ability to fix a few parameters

• TCP or UDP sockets

Addressing processes

• To receive messages, process must have an address or identifier

• Host device has unique 32-bit IP address

(well, could have >1, but ignore for now)

• Q: Does IP address of host on which process runs suffice for identifying the process?

Addressing processes

• To receive messages, process must have address or identifier • Identifier includes both IP address and port numbers associated

with process on host.

• Host device has unique 32-bit IP address• Example port numbers:

• HTTP server: 80

• Mail server: 25

• To send HTTP message to caesar.cs.umn.edu web server:• IP address: 128.119.245.12

• Port number: 80

Internet transport protocols services

TCP service:

• Connection-oriented: setup required between client and server processes

• Reliable transport between sending and receiving process

• Does not provide: timing, minimum throughput guarantees, security

UDP service:

• Connectionless: does notprovide: connection setup, reliability, throughput guarantee, security

• unreliable data transfer between sending and receiving process

Message oriented

Q: why bother? Why is there a UDP?

Network Programming

Socket headers

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

Creating a socket

int socket (int domain, int type, int protocol);

• Creates a communication end-point, returns a fd

• Domain is the communication domain:• PF_UNIX is for local Unix communication

• PF_INET/INET6 is for IPv4/v6 Internet

communication

Creating a socket (cont’d)

• Type specifies the communication style

• TCP

• SOCK_STREAM

• stream of bytes

• UDP

• SOCK_DGRAM

• Unreliable message delivery

fd = socket (PF_INET, SOCK_STREAM, 0);

Using sockets: client-server

• Server• Creates a socket with socket()

• Binds the socket to a local or network address with bind()

• Set up a queue for incoming connection requests with listen()

• accept () a connection

Using sockets (cont’d)

• Accept connection requests with accept()

• Creates a new socket connected to the client

• Returns new socket identifier as an fd

• Read and write to/from the socket fd with our old friends read/write

• Close the socket fd with close() when you are done

Socket addressing

• bind() takes a socket address structure

with an address format that depends on

domain

int bind (int sockfd, struct sockaddr *my_addr,

socklen_t addrlen);

struct sockaddr{

sa_family_t sin_famly; // AF_INET, same as PF_INET

u_intl6_t sin_port; // port: network byte order

struct in_addr sin_addr; // IP address: network byte order

}

len? different sizes for differenttypes (IPv4, IPv6, …)

Using bind

int port = 6666;

struct sockaddr_in addr:

addr.sin_family= AF_INET;

addr.sin_addr.s_addr= htonl(INADDR_ANY);

addr.sin_port= htons(port); //server picks the port

bind (fd,(struct sockaddr*)&addr, sizeof(addr));

INADDR_ANY:

OS pick local IP address—if multi-homed, then may want to hand-pick address.

Network byte order

Avoiding Port Collision

• If you are testing your server… bind … then crash …

• OS holds port for a while and you may get a bind error next time you run the server

int enable = 1;

setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,

(char*)&enable, sizeof(int));

• Gives back ports to OS: call before bind so next bind call does not fail

Choosing Ports

• You can pick >1024 (up to 65536) usually

• netstat will list active ports

Listen and accept

listen() sets up a queue for incoming connection requests

accept() gives you a channel to the requester

#include <sys/types.h>

#include <sys/socket.h>

int listen (int fd, int backlog);

int accept (int fd, struct sockaddr* addr;

socklen_t* addrlen);

// create a socket … enable/reuse … bind

listen (fd, 5); //queue up 5 pending requests

new_fd = accept (fd,(struct sockaddr*)&client_addr, &addr_len);

//can read or write to new_fd so can the other side

Accept

accept () returns a fd for a new socket

accept() blocks until a request arrives

Server Styles

• Single thread, one request at a time …

• Thread/request

• Each new request is handled by a new thread

• Could also have a thread pool

Server Styles (cont’d)

•Multiplexed

• Each thread does a portion of request handling (i.e. lab #4)

• Server cannot selectively accept clients!

• Cannot say, accept from IP 128.118.44.3

• Can, however, block/pass it through with a firewall

Host Lookup

#include <netdb.h>

struct hostent* gethostbyname(const char *name);

hostent contains sockaddr

Client Scenario

• Create socket with socket ()

• Resolve host address

• No need to bind, OS does it automatically (when you connect) and finds a free port

• Connect to the server with connect ()

• Read and write to/from the socket with • read/write () or other socket I/O calls• close the socket with close()

Look at tcp_client.c, tcp_server.c (chapter 13)1. Show bind error2. Show server not ready

Internet Addresses

• Internet addresses• IP + port

• Must be understandable by the network layer (routers) and end-host

• Network byte order

• Functions to convert components from host to network formats and vice-versa.

#include <inet.h>

uint32_t htonl(uint32_t hostlong); //long for IP

uint32_t htonl(uint32_t netlong);

• short int conversion for ports

Socket programming with UDP

UDP (User Datagram Protocol):

no “connection” between

client and server

no handshaking

sender explicitly attaches IP

address and port of

destination to each packet

server must extract IP

address, port of sender from

received packet

UDP: transmitted data may be

received out of order, or lost

application viewpoint

UDP provides unreliable transfer

of groups of bytes (“datagrams”)

between client and server

Some sites block UDP!

UDP servers

• Same header files

• Specify SOCK_DGRAM for socket type

• Bind to a port

• No need to listen or accept : why?

• Send and receive messages with sendto() and

recvfrom() with contained addresses

UDP (cont’d)

int sendto

(int sockfd, const void *buf, size_t len,

int flags, const struct sockaddr *dest_addr,

socklen_t addrlen);

ssize_t recvfrom

(int sockfd, void *buf, size_t len,

int flags,struct sockaddr *src_addr,

socklen_t *addrlen);

• Each message is addressed separately• this is why you can’t use read/write• max “packet” size ~ 64K