Communication. References Chapter 3, Tanenbaum and Van Steen Beej’s Network Programming Guide

Communication

References

• Chapter 3, Tanenbaum and Van Steen

• Beej’s Network Programming Guide

Layered Protocols

• All communication is based on exchanging messages.

• Protocols control the sending and receiving of messages e.g., TCP, IP, HTTP,FTP

Layered Protocols

• Many different protocols are needed at a variety of levels e.g.,

How many volts needed for a 0 bit and for a 1 bit How does the receiver know which is the last bit of the

message? How is a lost message detected?

• ISO developed the OSI model. Very useful as a reference point Internet protocols such as TCP, IP are mostly used.

Layered Protocols

Layers, interfaces, and protocols in the OSI model.

2-1

Layered Protocols

A typical message as it appears on the network.

2-2

Physical Layer

• The physical layer is concerned with the transmission of 0’s and 1’s. How many volts to use for 0 and 1 How many bits per second can be sent

• Many physical layer standards have been developed for different media e.g., RS-232-C standard for serial communication lines

Data Link Layer

• The physical layer just sends bits.

• A mechanism is needed to detect and correct errors such as damaged or lost messages

• The data link layer groups bits into units (frames). Each frame has Sequence numbers for detecting lost messages Checksums for detecting damage

Data Link Layer

Discussion between a receiver and a sender in the data link layer.

2-3

Network Layer

• For a message to get from the sender to the receiver, it may need to make a number of hops (in a wide-area network)

• There is usually more than one path.

• Choosing a path is called routing

• Most widely used network protocol is the connectionless IP (Internet Protocol)

Transport Protocols

• The transport layer turns the underlying network into something that an application developer can use.

• Upon receiving a message from the application layer, the transport layer breaks it into small pieces enough for transmission, assigns each one a sequence number and then sends them all.

Transport Protocols

• At the receiving end, the transport layer has to put back together the pieces into the message before passing it to the application.

• The Internet transport protocol is called Transmission Control Protocol (TCP).

TCP is a reliable transport protocol i.e., it can deal with losses

• The Internet transport protocol that does not deal with losses is called UDP.

• The official ISO transport protocol has 5 variants

Client-Server TCP

a) Normal operation of TCP.b) Transactional TCP (T/TCP).

2-4

Higher-Level Protocols

• The Internet does not provide these protocols

• Session and Presentation Provides dialog control and provides

synchronization facilities Example: Agree on a record format Example: Checkpoints of application state so that

a crash requires an application to go back to the checkpointed data and not to the beginning.

Higher-Level Protocols

• Application Protocols The OSI standards intended this to contain a

collection of standard network applications. Basically, in the Internet this has become the

container for all applications and protocols that do not fit into the one of the underlying layers. nntp, ftp, http

Standards

• All communication activity in Internet governed by protocols.

• Internet protocols define format, order of messages sent and received among network entities and actions taken on message transmission and receipt.

• The Internet protocols provide a standard that has been worked on by many people.

• Many people claim that these standards are the major reason for the success of networked systems.

Client-Server Paradigm

• Many network applications use a form of communication known as the client-server paradigm

Server application waits (passively) for contact. Client initiates the contact.

• Client and server applications interact directly with a transport-layer protocol for establishing communication and to send and receive information.

• The transport layer uses lower layer protocols to send and receive individual messages.

Application Programming Interface: API

• The interface an application uses when it interacts with the transport protocol software is known as an Application Programming Interface (API).

• An API defines a set of operations that an application can perform when it interacts with a protocol.

• APIs are defined as follows: Provide a set of procedures that can be called For each procedure, define the arguments expected Usually there is a procedure for each basic operation e.g.,

send, receive

Socket API

• Introduced in 1981

• Originally only Unix

• Implemented as a library

• This can be used to communicate with TCP or UDP

Socket Programming using TCPSocket: a door between application process and end-end-transport

protocol (UDP or TCP)TCP service: reliable transfer of bytes from one process to anotherUDP service: does not guarantee a reliable transfer of bytes

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet

Socket Programming with TCP

• Client must contact server Server process must first be running Server must have created socket (door) that welcomes

client’s contact

• Client contacts server by Specifying IP address, port number of server process

Socket Programming with TCP

• When client creates socket: client TCP establishes connection to server TCP

• When contacted by client, server TCP creates new socket for server process to communicate with client Allows server to talk with multiple clients

Unix File I/O

• A file descriptor is a small, positive integer.int fd;char buf[256];

fd = open(“a.txt”, O_RDWR);write(fd, buf, sizeof(buf));close(fd)

• The file descriptor is used to refer to the file a.txt

Unix Descriptor Table

Descriptor TableDescriptor Table

0

1

2

3

4

Data structure for file 0



Sockets and Descriptors

• Socket communication also uses the descriptor approach.

• Before an application can communicate, it must request the operating system to create a socket to be used for communication.

• The system returns a small integer descriptor that identifies the socket.

• The application uses the descriptor as an argument in a procedure of the API that is defined for communication.

Socket Descriptor Data Structure

Family: PF_INETFamily: PF_INETService: SOCK_STREAMService: SOCK_STREAMLocal IP: 158.108.33.66Local IP: 158.108.33.66Remote IP: 158.108.2.71Remote IP: 158.108.2.71Local Port: 2249Local Port: 2249Remote Port: 21Remote Port: 21

Family: PF_INETFamily: PF_INETService: SOCK_STREAMService: SOCK_STREAMLocal IP: 158.108.33.66Local IP: 158.108.33.66Remote IP: 158.108.2.71Remote IP: 158.108.2.71Local Port: 2249Local Port: 2249Remote Port: 21Remote Port: 21

Descriptor TableDescriptor Table

0

1

2

3

4

Sockets and Descriptors

• In Unix sockets are integrated with I/O.• The OS provides a single set of descriptors for

files, devices, communication.• Read and Write can be used for both files and

communication• However, socket programming does differ

from file I/O in that there are many details needed to use a socket e.g., transport protocol, address of the remote machine, etc

Socket Creation

• descriptor = socket(domain, type, protocol) domain specifies the specifies the addressing format to be

used by the socket. Socket. AF_NET specifies Internet address and AF_UNIX specifies file path names.

type specifies the type of communication the socket will use. SOCK_STREAM: connection-oriented stream transfer SOCK_DGRAM: connectionless message-oriented transfer

protocol specifies a particular transport protocol; usually 0 = default for type

A –1 is returned if an error occurs.

Socket Creation

• Transport Protocols TCP -- connection-oriented UDP -- connectionless

• It is possible to have more than one transport protocol for a specific type of communication.

Socket Creation

• Example#include <sys/types.h>#include <sys/socket.h>if ((s = socket(AF_INET, SOCK_STREAM, 0) ) < 0){

perror(“socket”);}

Endpoint Addresses

• A socket association is characterized as follows: communication protocol, local address, local port,

remote address, remote port

• Local address, port are defined using the bind call

• Remote address, port are defined using connect, sendto

Address Representation

• This structure holds socket address information for many types of sockets.

struct sockaddr {

unsigned short sa_family; // address family,

char sa_data[14]; // 14 bytes of protocol address }; • sa_family represents the address format i.e., AF_INET.

• sa_data contains an address and port number for the socket.

• This structure is considered “unyieldy” since most programmers do not want to pack sa_data by hand.

• Programmers deal with the sockaddr_in structure


• Internally an address is represented as a 32-bit integer

struct in_addr { u_long s_addr;}struct sockaddr_in { short sin_family; /*Address Family*/ u_short sin_port /*port number*/ struct in_addr sin_addr /* network address*/ char sin_zero[8]; /*unused*/}


• sin_family represents the address format (Internet vs Unix)

• sin_port specifies a port number which is associated with a process.

• sin_addr specifies the address of a host machine

• sin_zero is used to fill out the structure.


• sockaddr_in is used for TCP/UDP and sockaddr_un is used for Unix sockets.

• The API procedures assume that a variable that is a pointer to sockaddr is used.

• The programmer should cast a variable of type sockaddr_in (or sockaddr_out) to a variable that is a pointer to sockaddr

• If this is not done, most C compilers generate a warning.

Data Representation• Integers are not represented the same on all machine

architectures little endian: least significant byte first; the Intel series,

VAX big endian: most significant byte first (this is network byte

order); IBM 370, Motorola 68000 and Sun Sparc• When little endian computers are going to pass

integers over the network (e.g., IP addresses), they need to convert them to network byte order.

• Internet protocols use big endian order.

Data Representation

• The following functions are used to convert between the host byte order and the network byte order.

m = ntohl(m): network to host byte order (32 bit) m = htonl(m): host to network byte order (32 bit) m = ntohs(m): network to host byte order (16 bit) m = htons(m): host to network byte order (16 bit)

• On those systems that have the same byte ordering as the Internet protocols, these four functions are usually defined as null macros.

Byte Manipulation Functions

• void bzero (void *dest, size_t nbytes) Sets the specified number of bytes to 0 in the destination. Often used to initialize a socket address structure to 0

• void bcopy (const void *src, void *dest, size_t nbytes)

Moves the specified number of bytes from the source to the destination

• void memset (void *dest, int c, size_t len) Sets the specified number of bytes to the value of c in the

destination.

Bind

• bind(int socket, struct sockaddr *localaddr, int addrlen)

localaddr is a structure that specifies the local address to be assigned to the socket.

addrlen specifies the length of the sockaddr structure pointed to by the address argument.

• Used by both TCP and UDP.

Bind#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <netdb.h>

int s;struct sockaddr_in sin;if ((s = socket(AF_INET, SOCK_STREAM,0)) < 0 { /*error*/};

memset((char *) &sin, 0, sizeof(sin));sin.sin_family = AF_INET:sin.sin_port = htons(6000);sin.sin_addr.s_addr = htonl(INADDR_ANY);if bind(s, (struct sockaddr *) &sin, sizeof(sin)) < 0) {…}

send()

int send(int socket, const void *msg, int len, int flags);

msg specifies a pointer to the first of the data to be sent len is an integer that specifies the amount of data to be sent flags are used to specify special options which are mostly

intended for system debugging (don’t worry about this; just set it to 0)

• Used for stream communications

recv()

int recv(int socket, void *msg, int len, int

flags);

Similar to send() except this is used to receive data and put into msg

NOTE: Don’t forget that you may use the read/write functions.

connect()

int connect(int s, struct sockaddr *name, int namelen)

client issues connect() to establish remote address and port (stream, datagram sockets)

Establish connection (stream socket)• The call fails if the host is not listening to port.

listen()

• int listen(int s, int queuesize)

queuesize specifies a length for the socket’s request queue. The OS builds a separate request queue for each socket. Client requests are put into the queue. Socket being listened to can’t be used for client. Sample code often shows queuesize to be 5. This is

leftover from the 1980’s. Larger numbers are needed. By default, an HTTP server is 128. This can be changed.

accept()

• int accept (int s, struct sockaddr *addr, int *addrlen);

All servers begin by calling socket to create socket and bind to specify a protocol port number.

These two calls are sufficient for a server to start accepting messages in a connectionless transport.

An extra call ( accept() ) is needed for a connection-oriented protocol.

accept() fills in fields of argument addr with the address of the client that formed the connection and sets addrlen to the length of the address.

accept()

The server uses the new socket to communicate with the client and then closes the socket when finished.

The original socket remains unchanged and this is used to accept the next connection from a client.

Getting IP address/port from socket

int getsockname(int sockfd, struct sockaddr *localaddr, socklen_t *addrlen)

Get the local IP/port bound to socket

int getpeername(int sockfd, struct sockaddr *remoteaddr, socklen_t *addrlen)

Get the IP/port of remote endpoint

Two Other Useful Functionsstruct hostent *gethostbyaddr (void *addr, size_t

len, int type); Converts from IP addr to name

struct hostent *gethostbyname (char *name); Converts from name to IP address

struct hostent {char *h_name;/* official name of host */

char **h_aliases; /* alias list */int h_addrtype; /* address type */

int h_length; /* address length*/ char **h_addr_list; /* address list */

}#define h_addr h_addr_list[0]

Example (Stream Socket; setting address)

setaddr(sp, host, port) struct sockaddr_in *sp; char *host; int port; { struct hostent *hp;

hp = gethostbyname(host);

Example (Stream Socket; setting address)

if (hp == NULL) { fprintf(stderr, "%s: unknown host\n", host); exit(1); } sp->sin_family = AF_INET; bcopy(hp->h_addr, &sp->sin_addr, hp->h_length); sp->sin_port = htons(port);}

Example (Stream Socket; socket creation)

streamsocket(port) int port;{ int s; struct sockaddr_in sin;

sin.sin_family = AF_INET; sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = htons(port); s = socket(AF_INET, SOCK_STREAM, 0);


if (s < 0) error("socket");if (bind(s, &sin, sizeof (sin)) < 0) error("bind");return s; }


/* * System call failed: print a message and give up. */error(msg) char *msg;{ extern char *myname; /* program name */

fprintf(stderr, "%s: ", myname); perror(msg); exit(1);}

Example (Stream Socket; client)

#include <stdio.h>#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>char *myname;


main(argc, argv) char *argv[];{ struct sockaddr_in sin; int s, n, zero; char buf[BUFSIZ];

myname = argv[0]; if (argc < 2) { fprintf(stderr, "usage: %s port [host]\n", myname); exit(1); }


s = streamsocket(0); /* port 0 means "any port" */setaddr(&sin, argc > 2 ? argv[2] : "localhost",

atoi(argv[1]));

/* connect a socket using name specified by the command line */

if (connect(s, (struct sockaddr *) &sin, sizeof(struct sockaddr *)) < 0) {

error("connecting stream socket"); exit(1); }


printf("Type in text\n");/* read text from the standard input */bzero(buf, sizeof(buf));while ((n = read(0, buf, sizeof(buf))) > 0) /* send the text through socket */ if (write(s, buf, sizeof(buf)) < 0) error("writing on stream socket"); } bzero(buf, sizeof(buf));close(s);exit(0);}

Example (Stream Socket; server)

#include <stdio.h>#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <netdb.h>char *myname;

#define MSGSIZE 1


main(argc, argv) char *argv[];{ struct sockaddr_in from; int s, n, fromlen, msgs, rval; struct hostent *hp; char buf[BUFSIZ];

myname = argv[0];


if (argc < 2) { fprintf(stderr, "usage: %s port\n", argv[0]); exit(1);}s = streamsocket(atoi(argv[1]));alarm(5*60); /* die after five minutes */fromlen = sizeof(from);if (getsockname(s, (struct sockaddr *)&from, &fromlen)) {

error("getting socket name");exit(1);

}printf("Socket has port #

%d\n",ntohs(from.sin_port));listen(s, 5);


for (;;) { /*start accepting connections*/ msgs = accept(s, 0, 0);

if (msgs == -1) error("accept");

else do { bzero(buf, sizeof(buf));


if ((rval = read(msgs, buf, sizeof(buf))) < 0)error("reading stream message");

if (rval == 0)printf("Ending connection\n");

else {printf("%s\n",buf);

} } while (rval!= 0); close(msgs); }}

UDP: User Datagram Protocol [RFC 768]

• “no frills,” “bare bones” Internet transport protocol• “best effort” service, UDP segments may be:

Lost Delivered out of order to app

• connectionless: No handshaking between UDP sender, receiver Each UDP segment handled independently of

others

Why use UDP instead of TCP?• No connection establishment (which can add delay)

Remember that TCP does a three-way handshake before transmitting data. UDP does not.

• TCP maintains connection state Receive and send buffers Sequence and acknowledgement numbers Congestion control parameters

• Smaller segment overhead Each TCP segment has 20 bytes of header overhead while each UDP

segment has 8 bytes. The overhead in TCP includes sequence and acknowledgement numbers,

and a flow congestion field.

• There is no congestion control UDP can blast away as fast as possible

UDP

• Often used for streaming multimedia apps loss tolerant rate sensitive

• Other UDP uses (why?): DNS ping command

Applications using UDP and TCP

• Email – TCP• telnet – TCP• HTTP – TCP• ftp – TCP• Remote file server (NFS) – typically UDP• DNS – typically UDP• Streaming multimedia – typically UDP• Internet telephony – typically UDP• Network management (SNMP) – typically UDP

UDP and Reliability

• Lack of congestion control

• It is possible to have reliable data transfer in UDP. The application must have acknowledgements and

retransmission mechanisms Streaming applications do this.

API for UDP

• socket() call uses SOCK_DGRAM instead of SOCK_STREAM

• There is no connect() call

• Uses recvfrom() and sendto() instead of read() and write()

• There are no listen() or accept() calls

sendto()

• int sendto (int socket, char *msg, int len, int flags, struct sockaddr *to, int tolen);

to specifies the destination address and tolen specifies the length of the destination address.

• Used for datagram communications

recvfrom()

• int recvfrom (int socket, char *msg, int len, int flags, struct sockaddr *from, int fromlen);

sets from to source address of data sets fromlen to valid length of from returns number of bytes received

Documents

Communication. References Chapter 3, Tanenbaum and Van Steen Beej’s Network Programming Guide