Protocol

• Programs that communicate across a network must agree on a protocol on how they will communicate

• High-level decisions must be made on which program is expected to initiate communications and when responses are expected

Web Server

• A web server is typically a long-running program called a daemon

• Web server sends network messages only in response to requests from the network.

Web Client

• The other side of the protocol is a Web client or browser.

• The browser initiates communication with the Web server.

Client/Server Model• Client/Server model is used for most

network communications• If the client initiates all requests, the

protocol is simplified – we will use this type of protocol

• More complex applications use asynchronous callback communication, where the server initiates a message to the client

Application Protocol

Client Application Protocol Server

Communications Relationships

• Clients normally communicate with one server at a time

• Although, a browser could access several server web sites over a period of time

• Server regularly communicates with several clients at a time

Client/Server Relationship

Client

Client

Client Server

Communications Paths

• Application communicates with TCP• TCP communicates with IP• IP communicates with datalink layer of

some sort• Communication goes down the stack on

one side and up on the other• Client and server are typically user

processes

TCP Comm on the Same EthernetUser

Process

Web

ClientApplication Protocol

Web

ServerApplication Layer

Protocol TCP TCP Protocol TCP Transport Layer

Stack

Within

Kernel IP IP Protocol IP Network Layer

Ethernet Ethernet Protocol Ethernet Datalink Layer

Actual Client/Server Flow

Ethernet LAN

Connection-Oriented vs Connectionless Protocols

• Transmission Control Protocol (TCP) – connection oriented

• User Datagram Protocol (UDP) – Connectionless protocol

IP

• Protocol in use since early 1980s is IP version 4 (IPv4).

• A new version IP version 6 (IPv6) was developed mid 1990s

• This text covers network applications using IPv4 and IPv6

LANs Connected with WAN client

application

server

application

host

with

TCP/IP

host

with

TCP/IP

LAN LAN

router router

WAN

router router router router

Daytime Client IPv4 – Top

#include "unp.h"intmain(int argc, char **argv){ int sockfd, n; char recvline[MAXLINE + 1]; struct sockaddr_in servaddr; if (argc != 2) err_quit("usage: a.out <IPaddress>"); if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) err_sys("socket error"); bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_port = htons(13); /* daytime server */ if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0) err_quit("inet_pton error for %s", argv[1]);

Daytime Client IPv4 – Bottom

if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)

err_sys("connect error");

while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {

recvline[n] = 0; /* null terminate */

if (fputs(recvline, stdout) == EOF)

err_sys("fputs error");

}

if (n < 0)

err_sys("read error");

exit(0);

Socket Function

• Returns a file descriptor• AF_INET indicates the file descriptor can

communicate with any internet IP – AF_UNIX indicates the file descriptor can communicate within a single UNIX system such as Chico’s ect-unix system.

• SOCK_STREAM indicates connection protocol like TCP – SOCK_DGRAM indicates connectionless protocol like UDP

Convention

if ( (sockfd = socket(AF_INET, SOCK_STREAM,0)) < 0)

The space in between parentheses at the beginning of socket call indicates that both the return of the socket FD and testing of FD for error are performed in the if statement condition

Instead of:

sockfd = socket(AF_INET, SOCK_STREAM,0);

if (socketfd < 0)

Connect Function

• Establishes connection with server• Parameters are:

– File descriptor returned by client sock function

– A structure of type sockaddr_in– The size of the sockaddr_in structure

• Connect associates File descriptor with communications port

struct sockaddr_in

• Fields initially set to 0 by bzero

• Fields are then set with information about how to communicate with server– sin_family = AF_INET– sin_port = htons(13)– inet_pton sets sin_addr to argv[1]

Reading Data and Printing the Result

• Notice that read and fputs are in a while loop.

• Some socket systems will return all data in one read call and others will return data one byte at a time. While loop handles both cases.

Daytime Client IPv6 - Top

#include "unp.h"intmain(int argc, char **argv){ int sockfd, n; char recvline[MAXLINE + 1]; struct sockaddr_in6 servaddr; if (argc != 2) err_quit("usage: a.out <IPaddress>"); if ( (sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0) err_sys("socket error"); bzero(&servaddr, sizeof(servaddr)); servaddr.sin6_family = AF_INET6; servaddr.sin6_port = htons(13); /* daytime server */ if (inet_pton(AF_INET6, argv[1], &servaddr.sin6_addr) <= 0) err_quit("inet_pton error for %s", argv[1]);

Daytime Client IPv6 - Bottom

if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)

err_sys("connect error");

while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {

recvline[n] = 0; /* null terminate */

if (fputs(recvline, stdout) == EOF)

err_sys("fputs error");

}

if (n < 0)

err_sys("read error");

exit(0);

Error Conditions

• Important to check every function for error

• For example, we check socket, inet_pton, connect, read, and fputs

• Our functions err_quit and err_sys print an error message and terminate the program

Wrapper Function

int Socket (int family, int type, int protocol)

{

int n;

if ( (n = socket (family, type, protocol)) < 0)

err_sys(“socket error”);

return (n);

}

errno• Most functions involving processes return –1

on error and set a global variable called errno• If the function does not return –1, errno is

undefined• Errno values are always uppercase and

always begin with E, such as ETIMEDOUT• Errno values are normally defined in

<sys/errno.h>• When we say something like, “the connect

function returns ECONNREFUSED” we mean that connect returns –1 and sets errno to ECONNREFUSED.

More Wrappersint n;if ( (n = pthread_mutex_lock(&ndone_mutex)) != 0)

errno = n, err_sys(“pthread_mutex_lock error”);

or

void Pthread_mutex_lock(pthread_mutex_t *mptr){

int n;if ( (n = pthread_mutex_lock(mptr)) == 0)errno = n;err_sys(“pthread_mutex_lock error”);

}

Daytime Server IPv4 (Top)#include "unp.h"#include <time.h>intmain(int argc, char **argv){ int listenfd, connfd; struct sockaddr_in servaddr; char buff[MAXLINE]; time_t ticks; listenfd = Socket(AF_INET, SOCK_STREAM, 0); bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(13); /* daytime server */ Bind(listenfd, (SA *) &servaddr, sizeof(servaddr)); Listen(listenfd, LISTENQ);

Daytime Server IPv4 (Bottom)

for ( ; ; ) {

connfd = Accept(listenfd, (SA *) NULL, NULL);

ticks = time(NULL);

snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

Write(connfd, buff, strlen(buff));

Close(connfd);

}

}

Socket Function

• Identical to client code

• Return value is a file descriptor for server communication

sockaddr_in Structure• AF_INET indicates communication is

over internet

• INADDR_ANY indicates that the server can receive from any IP address

• htons(13) indicates server receives over port 13

Bind

• Bind has socket FD and sockaddr_in structure as parameters

• It uses them to associate the socket FD with a port number

Listen

• Sets the queue size for the number of client requests

• The name “Listen” leads you to believe that it is a function that listens for client requests, but that is what the Accept function does

Accept

• TCP uses what is called a three-way handshake to establish a connection

• When handshake completes, accept returns

• Accept returns a new file descriptor for server to communicate daytime data to client

time/ctime

• The time function returns the current time and date since the UNIX Epoch 00:00:00 January 1, 1970, Coordinated Universal Time (UTC)

• The ctime function converts the current time to human readable form, i.e.,

Mon May 26 20:58:40 2003

snprintf

• Prints ctime result to buffer

• Both sprintf and snprintf print result to a buffer, but snprintf has an extra parameter that allows for checking of buffer overflow

Close

• Server closes down connection with close

• Initiates normal TCP termination sequence

• FIN is sent in each direction and each FIN is acknowledged on the other end

Analysis

• Server is IPv4 dependent• Server handles only one client at a time – we refer to

this as an iterative server• If multiple clients arrive at one time, pending clients

are queued to be serviced by the server when free• It would be nice to overlap service to multiple clients

– we refer to this as a concurrent server• We can either have the server fork child processes to

handle the clients concurrently, or have the server create threads to handle them

• It would be appropriate to invoke the server as an infinate daemon process

Client/Server Examples in Text

• Daytime client/server

• Echo client/serve (begins in Chapter 5)

OSI Model

• International Organization for Standardization (ISO)

• Open Systems Interconnection (OSI)

OSI Layers and Internet Protocol Suite

7application

application

details

6presentation

applicationuser

process

5 session Sockets

4 transport TCP or UDP XTI

3 network IPv4 or IPv6 kernel

2datalink

device driver

comm

details

1 physical and hardware

OSI modelInternet

Protocol Suite

Analysis• Bottom two layers are device driver and

networking hardware• IPv4 or IPv6 occurs at Nework layer• TCP or UDP occurs at Transport layer• Application layer handles Web client

(browser), Telnet client, Web server, FTP server, etc.

• Sockets are interfaces from the top 3 layers of the OSI model to the transport layer – a later example will show the application can bypass the Transport layer

Why have Socket API between Session and Transport Layers?

• Upper layers handle details of application (i.e., FTP, Telnet, HTTP) but know little about communications details

• Lower layers handle communications details such as send data, ack, sequencing,calculating and verifying checksums, but know little about application details

• Upper layers know about user processes• Lower layers know about kernel processes

BSD Networking History

• First Implementation 4.2BSD became available 1983

• We are using 4.5BSD which became available 1993

• Many other versions are available• LINUX does not fit into the Berkeley-

derived classification – it was developed from scratch

macosx

freebsd4

aix

freebsd

Test Networkshpux

linux solaris

135.197.17.100

192.6.38.100

12.106.32.254

206.168.112.96

Internet

Network Topology

• Machines are spread across the Internet

• Virtual Private Networks (VPNs) or Secure Shell (SSH) connections provide connectivity between machines regardless of where they live

Discovering Network Topology

• There are no current UNIX standards with respect to network configuration and administration

• Two basic commands can be used to discover details:– netstat (located in /usr/bin)– ifconfig (located in /usr/sbin)

• Make sure /usr/bin and /usr/sbin are in your normal shell search path (PATH)

netstat

• netstat -i provides information on interfaces using name addresses for networks

• netstat -ni provides information on interfaces using numeric addresses for networks

• netstat -r shows routing table using name addresses for networks

• netstat -nr shows routing table using numeric addresses for networks

ifconfig

• Given interface names, ifconfig is used to obtain details about the interface

• Shows:– IP address– Broadcast address– Subnet mask

• MULTICAST flag indicates host supports multicasting

• Some implementations provide an -a flag that prints information on all configured interfaces

ping• ping <IP address> checks to see if IP

address is alive• ping –s <IP address> sends one

datagram per second that will be acknowledged by the IP address if it is alive – only need to receive one acknowledgement to know IP is alive

• ping –s <broadcast address> is responded to by all IP addresses in broadcast network

Portable Operating System Interface (POSIX)

• Not a single standard, but a family of standards being developed by IEEE

• POSIX has been adopted as international standard by ISO and International Electrotechnical Commission called ISO/IEC

• POSIX components:– Part 1: System API (C language) – POSIX.1– Part 2: Shell and Utilities – POSIX.2– Part 3: System Administration – POSIX.3

• Current status of POSIX standards are at: http://www.pasc.org/standing/sd11.html

64-Bit Architectures

• Trend since 1990s has been towards 64-bit architectures and 64-bit software

• 64-bit pointers can address large amounts of memory

Comparison of 32-Bit and 64-Bit Datatypes

Datatype ILP32 Model LP64 Model

char 8 8

short 16 16

int 32 32

long 32 64

pointer 32 64

Specifying Type

• ANSI C invented size_t datatype as argument to malloc to determine the number of bytes to allocate

• In different systems, size_t can be 32 bits or 64 bits

• By mistake size of socket address was made size_t, but 64 bit size is unneeded

• Therefore, in sockets API use socklen_t datatype and in XTI use t_scalar_t and t_uscalar_t datatypes