Lec 10 - 13 - Transport - Layer - PART-1 PDF

Computer Networks
(CS F303)
BITS Pilani Virendra Singh Shekhawat
Department of Computer Science and Information Systems
Pilani Campus
BITS Pilani
Pilani Campus
Second Semester 2018-2019

Module-3 <Transport layer>
Lecture: 10-13 [7 Feb 2019]
Topics
• Creating network Applications

– Socket Programming
• TCP vs. UDP Sockets
• Transport Layer
– Transport Layer Services
• Multiplexing/Demultiplexing
– Connectionless and Connection Oriented
» TCP and UDP
• Reliable data transfer (Protocol design)
• Flow control
• Congestion control
3
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Socket Programming [.1]
• What is a socket?
– To the kernel, a socket is an endpoint of communication.
– To an application, a socket is a file descriptor that lets the application
read/write from/to the network.
• Remember: All Unix I/O devices, including networks, are modeled as files.
• Clients and servers communicate with each by reading from and

writing to socket descriptors.
application application
socket controlled by
process process app developer
transport transport
network network controlled
link by OS
link Internet
physical physical
4
Socket Programming [..2]
Two socket types for two transport services:

– UDP: unreliable datagram
– TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters (data) from its keyboard
and sends the data to the server.
2. The server receives the data and converts characters to
uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays the line
on its screen.
5
Socket Programming with UDP
UDP: no “connection” between client & server

• No handshaking before sending data
• Sender explicitly attaches IP destination address and port # to
each packet
• Receiver extracts sender IP address and port# from received
packet
Note: Transmitted data may be lost or received

out-of-order
6
Socket Programming with TCP
Client contacts server by: • When contacted by client, server
• Creating TCP socket, specifying IP
address, port number of server TCP creates new socket for
process server process to communicate
• Server must have created socket with that particular client
(door) that welcomes client’s – Allows server to talk with multiple
contact
clients
• Client TCP establishes connection
to server TCP
Application viewpoint:
TCP provides reliable, in-order byte-stream
transfer (“pipe”) between client and server
7
Socket Structure [.1]
struct sockaddr
{
unsigned short sa_family; // address family, AF_xxx
char sa_data[14] ; // 14 bytes of protocol address
}
• sa_family – this remains AF_INET for stream and

datagram sockets
• sa_data contains destination address and port
number for the socket
8
Socket Structure [..2]
• Parallel structure to sockaddr

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 sockaddr
}
• sin_zero is just used to pad the structure to the length of a structure sockaddr
and hence is set to all zeros with the function memset()
• Important – you can cast sockaddr_in to a pointer of type struct sockaddr and
vice versa
• sin_family corresponds to sa_family and should be set to “AF_INET”.
• sin_port and sin_addr must be in NBO
9
NBO & HBO Conversion
Functions
• Two types that can be converted
– short (two bytes)
– long (two bytes)
• Primary conversion functions

– htons() // host to network short
– htonl() // host to network long
– ntohs // network to host short
– ntohl() // network to host long
• Very Important: Even if your machine is Big-Endian m/c, but you put your
bytes in NBO before putting them on to the network for portability
10
Primary Socket System Calls
• socket() - create a new socket and return its descriptor

• bind() - associate a socket with a port and address
• listen() - establish queue for connection requests
• accept() - accept a connection request
• connect() - initiate a connection to a remote host
• recv() - receive data from a socket descriptor
• send() - send data to a socket descriptor
• close() - “one-way” close of a socket descriptor
11
Socket System Calls:
Connectionless (e.g., UDP)
12
Socket System Calls: Connection-
Oriented (e.g., TCP)
13
Socket System Calls [.1]
• SOCKET: int socket(int domain, int type, int protocol);
– domain := AF_INET (IPv4 protocol)
– type := (SOCK_DGRAM or SOCK_STREAM )
– protocol := 0 (IPPROTO_UDP or IPPROTO_TCP)
– returned: socket descriptor (sockfd), -1 is an error
• BIND: int bind(int sockfd, struct sockaddr *my_addr, int addrlen);

– sockfd - socket descriptor (returned from socket())
– my_addr: socket address, struct sockaddr_in is used
– addrlen := sizeof(struct sockaddr)
14
Socket System Calls [..2]
• LISTEN: int listen(int sockfd, int backlog);
– backlog: how many connections we want to queue
• ACCEPT: int accept(int sockfd, void *addr, int *addrlen);

– addr: here the socket-address of the caller will be written
– returned: a new socket descriptor (for the temporal socket)
• CONNECT: int connect(int sockfd, struct sockaddr *serv_addr, int

addrlen); //used by TCP client
– parameters are same as for bind()
15
Socket System Calls […3]
• SEND: int send(int sockfd, const void *msg, int len, int flags);
– msg: message you want to send
– len: length of the message
– flags := 0
– returned: the number of bytes actually sent
• RECEIVE: int recv(int sockfd, void *buf, int len, unsigned int flags);
– buf: buffer to receive the message
– len: length of the buffer (“don’t give me more!”)
– flags := 0
– returned: the number of bytes received
16
Socket System Calls [….4]
• SEND (DGRAM-style): int sendto(int sockfd, const void *msg, int len, int flags,
const struct sockaddr *to, int tolen);
– msg: message you want to send
– len: length of the message
– flags := 0
– to: socket address of the remote process
– tolen: = sizeof(struct sockaddr)
– returned: the number of bytes actually sent
• RECEIVE (DGRAM-style): int recvfrom(int sockfd, void *buf, int len, unsigned
int flags, struct sockaddr *from, int *fromlen);
– buf: buffer to receive the message
– len: length of the buffer (“don’t give me more!”)
– from: socket address of the process that sent the data
– fromlen:= sizeof(struct sockaddr)
– flags := 0
– returned: the number of bytes received
• CLOSE: close (socketfd);

17
Socket Addresses
Socket address structure from <netinet/in.h>:
struct sockaddr_in (IPv4)
struct sockaddr_in {
uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
struct in_addr {
in_addr_t s_addr;
};
18
Byte ordering routines
#include <sys/types.h>
#include <netinet/in.h>
u_long htonl(u_long hostlong); /* host-to-network, long integer */
u_short htons(u_short hostshort); /* host-to-network, short integer */
u_long ntohl(u_long netlong); /* network-to-host, long integer */
u_short ntohs(u_short netshort); /* network-to-host, short integer */
Address conversion routines

#include <sys/socket.h>
#include <arpa/inet.h>
unsigned long inet_addr(char *ptr);

converts a char string IP address to its 32-bit network byte-order integer equivalent.
char *inet_ntoa(struct in_addr inaddr);

19
Simple TCP Server [.1]
#define SERVER_PORT 5888
int main()
{ int sockfd, connfd,clilen,n;
char buf[256];
struct sockaddr_in servaddr, cliaddr;
sockfd = socket( AF_INET, SOCK_STREAM, 0);

if (sockfd < 0)
{ printf(“ Server socket error");
exit(1); }
servaddr.sin_family = AF_INET;
servaddr.sin_port = htons(SERVER_PORT);
servaddr.sin_addr.s_addr =htonl(INADDR_ANY);
if(bind(sockfd,(struct sockaddr*)&servaddr,sizeof(servaddr) <0 )

{ printf(“Server Bind Error”); exit(1); }
20
Simple TCP Server [..2]
listen(sockfd, 5);
for(; ; ) {
clilen= sizeof(cliaddr);
connfd=accept(sockfd, (struct sockaddr *) &cliaddr, &clilen);
if(connfd<0)
{ printf(“Server Accept error \n”); exit(1); }
printf("Client IP: %s\n", inet_ntoa(cliaddr.sin_addr));

printf("Client Port: %hu\n", ntohs(cliaddr.sin_port));
n = read(connfd, buf,256);
printf("Server read: \"%s\" [%d chars]\n", buf, n);
write(connfd, “Server Got Message”, 18);

close(connfd);
}
}
21
Simple TCP Client
int main()
{ int sockfd, clifd,len;
char buf[256];
struct sockaddr_in servaddr;
sockfd = socket( AF_INET, SOCK_STREAM, 0);
if (sockid < 0) { printf(“ Server socket error"); exit(1); }
servaddr.sin_addr.s_addr = inet_addr(“172.24.2.4”);
connect(sockfd,(struct sockaddr*)&servaddr, sizeof(servaddr))
print(“Enter Message \n”);

fgets(buf,256,stdin);
write(sockfd,buf,strlen(buf));
read(sockfd,buf,256);
printf(“Client Received%s\n",buf);
Close(sockfd);
}
22
Simple UDP Server
int main()
{ int sockfd, clilen;
char buf[256];
struct sockaddr_in servaddr, cliaddr;
sockfd = socket( AF_INET, SOCK_DGRAM, 0);
servaddr.sin_addr.s_addr =htonl(INADDR_ANY);
if (bind(sockfd,(struct sockaddr*)&servaddr,sizeof(servaddr)) <0 )
{ printf(“Server Bind Error”); exit(1); }
for(; ; )
{ clilen= sizeof(cliaddr);
recvfrom(sockfd,buf,256,0,(struct sockaddr*)&cliaddr,&clilen);
printf(“Server Received:%s\n”,buf);
sendto(sockfd,“Server Got Message",18, 0,(struct sockaddr*)&cliaddr,clilen);

}
}
23
Simple UDP Client
#define SERVER_IPADDR “172.24.2.4”
int main()
{ int sockfd,len;
char buf[256];
struct sockaddr_in ,cliaddr,servaddr;
servaddr.sin_addr.s_addr = inet_addr(SERVER_IPADDR); Not
mandatory
sockfd = socket( AF_INET, SOCK_DGRAM, 0);
cliaddr.sin_family = AF_INET;
cliaddr.sin_port = htons(0);
cliaddr.sin_addr.s_addr =htonl(INADDR_ANY);
bind(sockfd,(struct sockaddr*)&cliaddr,sizeof(cliaddr));
printf(“Enter Message\n”); fgets(buf,255,stdin);

len= sizeof(server);
sendto(sockfd,buf,strlen(buf), 0,(struct sockaddr*)&seraddr,len);
recvfrom(sockfd,buf,256,0,NULL,NULL);
printf(“Clinet Received: %s \n”,buf);
close(sockfd);
}
24
Transport Layer Services and
Protocols
• Provides logical communication
between app processes
– Apps processes sends msgs to each
other using the logical communication
• Extend host-to-host delivery to

process-to-process delivery
25
TP Layer Vs. Network Layer
• Network layer: logical communication between hosts
• TP Layer: logical communication between processes
• TP layer services are constrained by the service

model of underlying network-layer protocol
• But certain services can be offered by the TP layer

even when the network layer doesn’t offer
– e.g., Reliable data transfer
26
Transport Layer Services
• Reliable in-order delivery (TCP)

– Congestion control
– Flow control
– Connection setup
• Unreliable, unordered delivery (UDP)

– Extension of “best-effort” IP
27
Multiplexing/Demultiplexing
Multiplexing at sendening time:
handle data from multiple Demux at receiving time:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket
application
application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
28
Demultiplexing at Receiver
• Host receives IP datagrams 32 bits

 Each datagram has source IP
address, destination IP source port # dest port #
address
 Each datagram carries one other header fields
transport-layer segment
 Each segment has source,
destination port number application
data
(payload)
• Host uses IP addresses &
port numbers to direct
segment to appropriate TCP/UDP segment format
socket
29
3-29
Connectionless Demultiplexing
• When host receives UDP segment:

– Checks destination port # in segment and directs segment to
socket with port #
• IP datagrams with same dest. port #, but different

source IP addresses and/or source port numbers will
be directed to same socket at destination
30
Example: Connectionless
Demultiplexing
DatagramSocket serverSocket
DatagramSocket = new DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
(6428);
DatagramSocket DatagramSocket
(9157); application
(5775);
P1
P3 P4
transport
transport transport
network
link physical link
physical physical
source port: 6428 source port: ?

dest port: 9157 dest port: ?
source port: 9157 source port: ?

dest port: 6428 dest port: ?
31
Connection Oriented Demux
• TCP socket identified by 4-tuple:

• Source IP address, source port #, dest IP address, dest port #
– Demux: receiver uses all four values to direct segment to
appropriate socket
• Server host may support many simultaneous TCP
sockets:
• Each socket identified by its own 4-tuple
• Web servers have different sockets for each
connecting client
• e.g., non-persistent HTTP will have different socket for each
request
32
Example: Connection Oriented
Demux
application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets 33
Example
threaded server
application
P4
P3 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
34
User Datagram Protocol [RFC 768]
• Best effort service

– UDP segment may lost, delivered out of order to
app
• Connectionless
– No handshaking between sender and receiver
• Each UDP segment handled independently of

others
35
UDP Segment Header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header
length checksum
Why is there a UDP?
• No connection establishment
application
(which can add delay)
data
(payload) • simple: no connection state
at sender, receiver
• small header size
UDP segment format • no congestion control: UDP
can blast away as fast as
desired
36
UDP Checksum
• Treat segment contents (with header fields) as a

sequence of 16-bit integers at sender
– Sum all such 16-bit words in the segment
– One’s complement of the sum is put in checksum
field
• At the receiver, all 16-bit words are added

(including checksum) to detect error in segment
37
Principles of Reliable Data Transfer
• Important in application, transport, link layers

• Top-10 list of important networking topics!
38

39

• Characteristics of unreliable channel will determine complexity

of reliable data transfer protocol (rdt)
40
Reliable Data Transfer: getting started
rdt_send(): called from above, deliver_data(): called by

(e.g., by app.). Passed data to be rdt to deliver data to upper
delivered to receiver upper layer
send receive
side side
udt_send(): called by rdt, rdt_rcv(): called when packet

to transfer packet over arrives on rcv-side of channel
unreliable channel to receiver
41
Reliable Data Transfer: getting started
We will:
• Incrementally develop sender, receiver sides of reliable data
transfer protocol (rdt)
• Consider only unidirectional data transfer
– But control info will flow on both directions!
• Use finite state machines (FSM) to specify sender, receiver
event causing state transition
actions taken on state transition
State: when in this “state”
next state uniquely state state
1 event
determined by next 2
event actions
42
Rdt1.0: reliable transfer over a
reliable channel
• Underlying channel perfectly reliable
– No bit errors, No loss of packets
• Separate FSMs for sender, receiver:
– Sender sends data into underlying channel
– Receiver read data from underlying channel
Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from packet = make_pkt(data) call from extract (packet,data)
above rdt_send(packet) below deliver_data(data)
sender receiver
43
Rdt2.0: channel with bit errors
• Underlying channel may flip bits in packet

– Don’t worry… Checksum is there to detect bit errors
• The question? How to recover from errors?

– Acknowledgements (ACKs): receiver explicitly tells sender that pkt received
OK
– Negative acknowledgements (NAKs): receiver explicitly tells sender that pkt
had errors
– Sender retransmits pkt on receipt of NAK
• New mechanisms in rdt2.0 (beyond rdt1.0):

– Error detection
– Receiver feedback: control msgs (ACK,NAK) rcvr->sender
44
rdt2.0: FSM Specification
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for rdt_rcv(rcvpkt) &&
Wait for call
ACK or udt_send(sndpkt) corrupt(rcvpkt)
from above
NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
L
from below
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
45
rdt2.0: Operation with no Errors
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for call Wait for rdt_rcv(rcvpkt) &&
from above ACK or udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)

Wait for call
L from below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
46
rdt2.0: Error Scenario
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for call Wait for rdt_rcv(rcvpkt) &&
from above ACK or udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)

Wait for call
L from below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
47
rdt2.0 Has a fatal flaw!
• What happens if ACK/NAK corrupted?

– Sender doesn’t know what happened at receiver!
– Simple, just retransmit.
• How to handle duplicates?

– Sender adds sequence number to each pkt
– Receiver discards (doesn’t deliver up) duplicate pkt
48
rdt2.1: Sender, handles garbled
ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for call Wait for
ACK or NAK
isNAK(rcvpkt) )
0 from
0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or NAK call 1 from
rdt_rcv(rcvpkt) && 1 above
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
49
rdt2.1: Receiver, handles garbled
ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
50
rdt2.1: Discussion
Sender:
• Seq # added to pkt
• Two seq. #’s (0,1) will suffice. Why?
• Must check if received ACK/NAK corrupted
• Twice as many states
– State must “remember” whether “current” pkt has 0 or 1 seq. #
Receiver:
• Must check if received packet is duplicate
– State indicates whether 0 or 1 is expected pkt seq #
– For an out of order received packet, it sends ACK for it
• Note: Receiver can not know if its last ACK/NAK received OK at

sender
51
rdt2.2: NAK Free Protocol
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
Wait for call Wait for
ACK isACK(rcvpkt,1) )
0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
sndpkt = make_pkt(ACK, 1, below fragment
chksum)
udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
52
rdt2.2: A NAK-free protocol
• Same functionality as rdt2.1, using ACKs only
• Instead of NAK, receiver sends ACK for last pkt received

OK
– Receiver must explicitly include seq # of pkt being ACKed
53
rdt3.0: Channels with errors and loss
• New assumption: Underlying channel can also lose

packets (data or ACKs)
– Checksum, seq. #, ACKs, retransmissions will be of help, but
not enough
• Approach: Sender waits “reasonable” amount of time

for ACK
– Retransmits if no ACK received in this time
– If pkt (or ACK) just delayed (not lost):
• Retransmission will be duplicate, but use of seq. #’s already handles this
• Receiver must specify seq # of pkt being ACKed
– Requires countdown timer
54
rdt3.0 Sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer L
L Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
L
55
rdt3.0 in action
56
rdt3.0 (Lost ACK and Premature
Timeout)
57
Performance of rdt3.0
• rdt3.0 works, but performance stinks

• Example: 1 Gbps link, 15 ms end to end prop. delay, 1KB packet:
Ttransmit = L (packet length in bits)

R (transmission rate, bps)
 U sender: utilization – fraction of time sender busy sending
U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R microsec
onds
58
rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R
first packet bit arrives

RTT last packet bit arrives, send ACK
ACK arrives, send next

packet, t = RTT + L / R
U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R microsec
onds
59
Pipelined Protocols
• Pipelining: Sender allows multiple, “in-flight”, yet-to-be-acked pkts

– Range of sequence numbers must be increased
– Buffering at sender and/or receiver
60
Pipelining: Increased Utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
Increase utilization
by a factor of 3!
U 3*L/R .024
= = = 0.0008
sender 30.008
RTT + L / R microsecon
ds
61
Thank You!
62

Lec 10 - 13 - Transport - Layer - PART-1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lec 10 - 13 - Transport - Layer - PART-1 PDF

Uploaded by

Copyright:

Available Formats

Computer Networks

Second Semester 2018-2019

• Creating network Applications

• Clients and servers communicate with each by reading from and

Two socket types for two transport services:

UDP: no “connection” between client & server

Note: Transmitted data may be lost or received

• sa_family – this remains AF_INET for stream and

• Parallel structure to sockaddr

• Primary conversion functions

• socket() - create a new socket and return its descriptor

• BIND: int bind(int sockfd, struct sockaddr *my_addr, int addrlen);

• ACCEPT: int accept(int sockfd, void *addr, int *addrlen);

• CONNECT: int connect(int sockfd, struct sockaddr *serv_addr, int

• CLOSE: close (socketfd);

u_long htonl(u_long hostlong); /* host-to-network, long integer */

u_short htons(u_short hostshort); /* host-to-network, short integer */

u_long ntohl(u_long netlong); /* network-to-host, long integer */

u_short ntohs(u_short netshort); /* network-to-host, short integer */

Address conversion routines

unsigned long inet_addr(char *ptr);

char *inet_ntoa(struct in_addr inaddr);

sockfd = socket( AF_INET, SOCK_STREAM, 0);

if(bind(sockfd,(struct sockaddr*)&servaddr,sizeof(servaddr) <0 )

printf("Client IP: %s\n", inet_ntoa(cliaddr.sin_addr));

write(connfd, “Server Got Message”, 18);

connect(sockfd,(struct sockaddr*)&servaddr, sizeof(servaddr))

print(“Enter Message \n”);

sendto(sockfd,“Server Got Message",18, 0,(struct sockaddr*)&cliaddr,clilen);

printf(“Enter Message\n”); fgets(buf,255,stdin);

sendto(sockfd,buf,strlen(buf), 0,(struct sockaddr*)&seraddr,len);

• Extend host-to-host delivery to

• Network layer: logical communication between hosts

• TP Layer: logical communication between processes

• TP layer services are constrained by the service

• But certain services can be offered by the TP layer

• Reliable in-order delivery (TCP)

• Unreliable, unordered delivery (UDP)

application P1 P2 application socket

• Host receives IP datagrams 32 bits

• When host receives UDP segment:

• IP datagrams with same dest. port #, but different

source port: 6428 source port: ?

source port: 9157 source port: ?

• TCP socket identified by 4-tuple:

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

• Best effort service

• Each UDP segment handled independently of

• Treat segment contents (with header fields) as a

• At the receiver, all 16-bit words are added

• Important in application, transport, link layers

• Important in application, transport, link layers

• Important in application, transport, link layers

• Characteristics of unreliable channel will determine complexity

rdt_send(): called from above, deliver_data(): called by

udt_send(): called by rdt, rdt_rcv(): called when packet

Wait for rdt_send(data) Wait for rdt_rcv(packet)

• Underlying channel may flip bits in packet

• The question? How to recover from errors?

• New mechanisms in rdt2.0 (beyond rdt1.0):

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

• ACCEPT: int accept(int sockfd, void addr, int addrlen);