UNIX SOCKETS

CLIENTS AND SERVERS

• Client program • Server program

• Running on end host • Running on end host
• Requests service • Provides service
• E.g., Web browser • E.g., Web server

GET /index.html

“Site under construction”

CLIENTS ARE NOT NECESSARILY
HUMAN
• Example: Web crawler (or spider)
• Automated client program
• Tries to discover & download many Web pages
• Forms the basis of search engines like Google
• Spider client
• Start with a base list of popular Web sites
• Download the Web pages
• Parse the HTML files to extract hypertext links
• Download these Web pages, too
• And repeat, and repeat, and repeat…
 CLIENT-SERVER
COMMUNICATION
• Client “sometimes on” • Server is “always on”
• Initiates a request to the server when interested • Services requests from many client hosts
• E.g., Web browser on your laptop or cell phone • E.g., Web server for the www.cnn.com Web site
• Doesn’t communicate directly with other clients • Doesn’t initiate contact with the clients
• Needs to know server’s address • Needs fixed, known address
CLIENT AND SERVER PROCESSES

• Program vs. process

• Program: collection of code
• Process: a running program on a host
• Communication between processes
• Same end host: inter-process communication
• Governed by the operating system on the end host
• Different end hosts: exchanging messages
• Governed by the network protocols
• Client and server processes
• Client process: process that initiates communication
• Server process: process that waits to be contacted
DELIVERING THE DATA:
DIVISION OF LABOR

• Network
• Deliver data packet to the destination host
• Based on the destination IP address

• Operating system
• Deliver data to the destination socket
• Based on the destination port number (e.g., 80)

• Application
• Read data from and write data to the socket
• Interpret the data (e.g., render a Web page)
 SOCKET: END POINT OF
COMMUNICATION
• Sending message from one process to another
• Message must traverse the underlying network
• Process sends and receives through a “socket”
• In essence, the doorway leading in/out of the house
• Socket as an Application Programming Interface
• Supports the creation of network applications

User process User process

socket socket
Operating Operating
System System
IDENTIFYING THE RECEIVING
PROCESS
• Sending process must identify the receiver
• The receiving end host machine
• The specific socket in a process on that machine

• Receiving host
• Destination address that uniquely identifies the host
• An IP address is a 32-bit quantity

• Receiving socket
• Host may be running many different processes
• Destination port that uniquely identifies the socket
• A port number is a 16-bit quantity
 USING PORTS TO IDENTIFY
SERVICES Server host 128.2.194.242

Client host Service request for Web server

128.2.194.242:80 (port 80)
(i.e., the Web server)
Client OS
Echo server
(port 7)

Service request for Web server

128.2.194.242:7 (port 80)
(i.e., the echo server)
Client OS
Echo server
(port 7)
KNOWING WHAT PORT NUMBER
TO USE
• Popular applications have well-known ports
• E.g., port 80 for Web and port 25 for e-mail
• See http://www.iana.org/assignments/port-numbers

• Well-known vs. ephemeral ports

• Server has a well-known port (e.g., port 80)
• Between 0 and 1023 (requires root to use)
• Client picks an unused ephemeral (i.e., temporary) port
• Between 1024 and 65535

• Uniquely identifying traffic between the hosts

• Two IP addresses and two port numbers
• Underlying transport protocol (e.g., TCP or UDP)
• This is the “5-tuple” I discussed last lecture
UNIX SOCKET API

• Socket interface
• Originally provided in Berkeley UNIX
• Later adopted by all popular operating systems
• Simplifies porting applications to different OSes
• In UNIX, everything is like a file
• All input is like reading a file
• All output is like writing a file
• File is represented by an integer file descriptor
• API implemented as system calls
• E.g., connect, read, write, close, …
 PUTTING IT ALL TOGETHER
Server

socket()

bind()
Client
listen()
socket()
establish
accept()
connection
connect()
block
send request
write()
read()
process
request
send response
write()
read()
 CLIENT CREATING A SOCKET:
SOCKET()
• Creating a socket
• int socket(int domain, int type, int protocol)
• Returns a file descriptor (or handle) for the socket
• Originally designed to support any protocol suite

• Domain: protocol family

• PF_INET for the Internet (IPv4)
• Type: semantics of the communication
• SOCK_STREAM: reliable byte stream (TCP)
• SOCK_DGRAM: message-oriented service (UDP)
• Protocol: specific protocol
• UNSPEC: unspecified
• (PF_INET and SOCK_STREAM already implies TCP)
 CLIENT: LEARNING SERVER
ADDRESS/PORT
• Server typically known by name and service
• E.g., “www.cnn.com” and “http”
• Need to translate into IP address and port #
• E.g., “64.236.16.20” and “80”

• Translating the server’s name to an address

• struct hostent *gethostbyname(char *name)
• Argument: host name (e.g., “www.cnn.com”)
• Returns a structure that includes the host address

• Identifying the service’s port number

• struct servent
*getservbyname(char *name, char *proto)
• Arguments: service (e.g., “ftp”) and protocol (e.g., “tcp”)
• Static config in/etc/services
 CLIENT: CONNECTING
SOCKET TO THE SERVER
• Client contacts the server to establish connection
• Associate the socket with the server address/port
• Acquire a local port number (assigned by the OS)
• Request connection to server, who hopefully accepts

• Establishing the connection

• int connect (int sockfd,
struct sockaddr *server_address,
socketlen_t addrlen)
• Arguments: socket descriptor, server address, and address size
• Returns 0 on success, and -1 if an error occurs
 CLIENT: SENDING DATA

• Sending data
• ssize_t write
(int sockfd, void *buf, size_t len)
• Arguments: socket descriptor, pointer to buffer of data to send, and length of the buffer
• Returns the number of bytes written, and -1 on error
 CLIENT: RECEIVING DATA

• Receiving data
• ssize_t read
(int sockfd, void *buf, size_t len)
• Arguments: socket descriptor, pointer to buffer to place the data, size of the buffer
• Returns the number of characters read (where 0 implies “end of file”), and -1 on error
• Why do you need len?
• What happens if buf’s size < len?

• Closing the socket

• int close(int sockfd)
 SERVER: SERVER PREPARING ITS
SOCKET

• Server creates a socket and binds address/port

• Server creates a socket, just like the client does
• Server associates the socket with the port number
(and hopefully no other process is already using it!)
• Choose port “0” and let kernel assign ephemeral port

• Create a socket
• int socket (int domain,int type, int protocol)
• Bind socket to the local address and port number
• int bind (int sockfd, struct sockaddr *my_addr, socklen_t addrlen)
• Arguments: sockfd, server address, address length
• Returns 0 on success, and -1 if an error occurs
 SERVER: ALLOWING CLIENTS TO
WAIT
• Many client requests may arrive
• Server cannot handle them all at the same time
• Server could reject the requests, or let them wait
• Define how many connections can be pending
• int listen(int sockfd, int backlog)
• Arguments: socket descriptor and acceptable backlog
• Returns a 0 on success, and -1 on error
• What if too many clients arrive?
• Some requests don’t get through
• The Internet makes no promises…
• And the client can always try again
 SERVER: ACCEPTING
CLIENT CONNECTION
• Now all the server can do is wait…
• Waits for connection request to arrive
• Blocking until the request arrives
• And then accepting the new request

• Accept a new connection from a client

• int accept(int sockfd, struct sockaddr *addr,socketlen_t *addrlen)
• Arguments: sockfd, structure that will provide client address and port, and length of the
structure
• Returns descriptor of socket for this new connection
 SERVER: ONE REQUEST AT A
TIME?
• Serializing requests is inefficient
• Server can process just one request at a time
• All other clients must wait until previous one is done
• What makes this inefficient?

• May need to time share the server machine

• Alternate between servicing different requests
• Do a little work on one request, then switch when you are waiting for some other
resource (e.g., reading file from disk)
• “Nonblocking I/O”
• Or, use a different process/thread for each request
• Allow OS to share the CPU(s) across processes
• Or, some hybrid of these two approaches
 CLIENT AND SERVER: CLEANING
HOUSE
• Once the connection is open
• Both sides and read and write
• Two unidirectional streams of data
• In practice, client writes first, and server reads
• … then server writes, and client reads, and so on
• Closing down the connection
• Either side can close the connection
• … using the close() system call
• What about the data still “in flight”
• Data in flight still reaches the other end
• So, server can close() before client finishes reading
INTERNET ADDRESS LIBRARY
ROUTINES
(GETHOSTBYADDR)

• Get the name of the host the program is running on.

• struct hostent* gethostbyaddr(char *address, int addressLength, int type)
• address is in network byte order
• addressLength is 4 if type is AF_INET
• type is the address family (e.g., AF_INET)
User and System
Programs

Kernel Support

Hardware
 SOCKET API

• Socket API originated with the 4.2 BSD system released in 1983
• Sockets – A way to speak to other programs using UNIX file descriptors.
• A file descriptor is an integer associated with an open file.This can be a network
connection
• Kinds of Sockets-DARPA Internet addresses(Internet Sockets) , Unix Sockets,
X.25 Sockets etc
• Types of Internet Sockets
1. SOCK_STREAM uses TCP (Transmission Control Protocol) Connection oriented and Reliable
2. SOCK_DGRAM uses UDP (User Datagram Protocol)
Connectionless and Unreliable
STRUCTS AND DATA HANDLING

A socket descriptor is of type int

Byte ordering
Most significant byte first – Network byte order (Big Endian)
Least significant byte first – Host Byte order ( Little ..)

Socket Structures in Network byte order

struct sockaddr { unsigned short sa_family; // address family, AF_xxx char sa_data[14]; // 14
bytes of protocol address };

struct sockaddr_in { short int sin_family; // Address family

unsigned short int sin_port; // Port number
struct in_addr sin_addr; // Internet address
unsigned char sin_zero[8]; // Same size as struct sockaddr };
CONVERT THE NATIVES

struct in_addr { unsigned long s_addr; // 32-bit long, or 4 bytes };

If ina is of type struct sockaddr_in
ina.sin_addr.s_addr references the 4-byte IP address (in Network Byte
Order

• htons() – Host to Network Short

• htonl() -- "Host to Network Long"
• ntohs() -- "Network to Host Short"
• ntohl() -- "Network to Host Long"
IP ADDRESSES

• socket01.utdallas.edu 129.110.43.11

• sol2.utdallas.edu 129.110.34.2 etc

Other UTD machines for use socket02 – socket06 , sol1 , jupiter

inet_addr() converts an IP address in numbers-and-dots notation into unsigned long

ina.sin_addr.s_addr = inet_addr(“129.110.43.11”) // Network byte order

Also can use inet_aton() -- “ascii to network”

int inet_aton(const char *cp,struct in_addr *inp);

inet_ntoa returns a string from a struct of type in_addr

inet_ntoa(ina.sin_addr) ;
SYSTEM CALLS

• socket() – returns a socket descriptor

• socketpair() - Returns two socket descriptors, that are unnamed and

connected. It is similar to pipes but with a basic difference.

• bind() – What port I am on / what port to attach to

• connect() – Connect to a remote host

• listen() – Waiting for someone to connect to my port

• accept() – Get a file descriptor for a incoming connection

• send() and recv() – Send and receive data over a connection

SYSTEM CALLS

• sendto() and recvfrom() – Send and receive data without connection

• close() and shutdown() – Close a connection Two way / One way

• getpeername() – Obtain the peer name given the socket file descriptor

• gethostname() – My computer name

(Useful to get the port number given a struct of type sockaddr)

Readn() writen() readline() Read / Write a particular number of bytes

Fork() – To start a new process with parents addr space
Exec() Load a new program on callers addr space
 SYSTEM CALLS
• readv ( ) and writev ( ) - Read and write from non contiguous buffers

• sendmsg() and recvmsg() – most general of all read and write

system calls

• getsockname() – Obtain the name given to the socket.

• getsockopt() and setsockopt() – manipulate the options associated

with the socket.

• fcntl ()- affects an open file and controls it with multiple operations.

• Ioctl() – affects the file operations in context to I/O, where we have

options of file , socket, routing and interface operations
 FEATURES OF Fnctl CALL

• Nonblocking I/O— We can set the O_NONBLOCK file status flag using the F_SETFL
command to set a socket as nonblocking.
• Signal-driven I/O— We can set the O_ASYNC file status flag using the F_SETFL
command, which causes the SIGIO signal to be generated when the status of a socket
changes.
• The F_SETOWN command lets us set the socket owner (the process ID or process group
ID) to receive the SIGIO and SIGURG signals. The former signal is generated when
signal-driven I/O is enabled for a socket and the latter signal is generated when new out-
of-band data arrives for a socket
• The F_GETOWN command returns the current owner of the socket.
• The term "socket owner" is defined by POSIX. Historically, Berkeley-derived
implementations have called this "the process group ID of the socket" because the
variable that stores this ID is the so_pgid member of the socket structure
SUMMARY OF fcntl, ioctl, AND
ROUTING SOCKET OPERATIONS
SUMMARY OF NETWORKING ioctl
REQUESTS.
USEFUL UNIX COMMANDS

• netstat –i prints information about the interfaces

• netstat –ni prints this information using numeric addresses

• loop back interface is called lo and the ethernet interface is called eth0 or le0 depending on the machine

• netstat –r prints the routing table

• netstat | grep PORT_NO shows the state of the client socket

• ifconfig eth0 – Given the interface name ifconfig gives the details for each interface --- Ethernet Addr ,
inet_addr , Bcast , Mask , MTU

• ping IP_addr -- Sends a packet to the host specified by IP_addr and prints out the roundtrip time ( Uses ICMP
messages)

• traceroute IP_addr -- Shows the path from this host to the destination printing out the roundtrip time for a
packet to each hop in between

• Tcpdump communicates directly with Data Link layer UDP Packet fail
CLIENT-SERVER PROGRAMMING
• TCP Client Server Example
• Status of client-server before call to accept daytimetcpsrv1.c
• Server Client

listenfd ● ● connect()

Status of clientserver after return from accept

listenfd ● ● connect()
connfd ●
Status of Client-Server after fork returns

Server( Parent) Client

listenfd ● ● connect()
connfd ●

Server ( Child)
listenfd●
connfd ●
Status of Client Server after parent and Child close appropriate sockets

Server ( Parent) Client

listenfd ● ● connect()

Server(Client)
connfd ●
Socket functions of UDP Client Server
Socket()

Bind()

Socket() Recvfrom()

Sendto()
Blocks until datagram
received from a client

recvfrom
Sendto()
Close()

UDP Client UDP Server

THREADS
• Threads are lightweight process which share the process instructions , global
variables , open files , signal handlers and signal dispositions , current
working directory and user and group Ids
• Each thread has its own thread ID , set of Registers, PC and Stack pointer,
stack , errno ,signal mask , priority
• Basic Thread Functions : Creation and Termination
• Int pthread_create(pthread_t *tid,const pthread_attr_t *attr,void *(*func)
(void*), void *arg);
• Int pthread_join(pthread_t tid,void **status); // Wait for a thread to
terminate
• pthread_t pthread_self(void); //Returns thread ID of calling thread
• Int pthread_detach(pthread_t pid);//We cannot wait for it to terminate, On its
termination all resources are released
• Void pthread_exit(void *status);
• Threads/tcpserv01.c
THREAD SYNCHRONIZATION
• Shared data can be protected using mutex locks provided by the pthread
library
• int pthread_mutex_lock(pthread_mutex_t *mptr);
• int pthread_mutex_unlock(pthread_mutex_t *mptr);
• Threads/example02.c
• Can use condition variables for signalling mechanism
• int pthread_cond_wait(pthread_cond_t *cptr,pthread_mutex_t *mptr);
• int pthread_cond_signal(pthread_cond_t *cptr);
• Can also use System semaphores from <semaphores.h> See manual
~syrotiuk/pthreads.cc