1. CS 5565 Network Architecture and Protocols
Lecture 10
Godmar Back

2. Announcements Project 1B due Mar 20 Problem Set 2 due Mar 18
Reminder: can be done as a team, can switch teams between projects, use forum if you’re looking for team members
Problem Set 2 due Mar 18
Required Reading: research paper
CS 5565 Spring 2009
2/18/2019

3. Principles of Reliable Data Transfer
important in app., transport, link layers
top-10 list of important networking topics!
characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
CS 5565 Spring 2009
2/18/2019

4. Evolution of Assumptions
perfect channel
error detection: checksums,
receiver feedback: acknowledgements; retransmissions
Automatic Repeat reQuest (ARQ protocol)
rdt1.0
bit errors
rdt2.0
(redundant) retransmissions  duplicates  sequence numbers 0/1: “alternating bit” protocol
corrupted acks
rdt2.1
eliminate NAK: use ACK+seq num
----
rdt2.2
rdt1-3 are stop-and-wait protocols
timeouts
lossy channel
rdt3.0
lossy channel with bit errors
CS 5565 Spring 2009
2/18/2019

5. 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
CS 5565 Spring 2009
2/18/2019

6. Pipelined Protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts
range of sequence numbers must be increased
buffering at sender and/or receiver
Two generic forms of pipelined protocols: Go-Back-N (“GBN”), Selective Repeat (“SR”)
CS 5565 Spring 2009
2/18/2019

7. 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!
CS 5565 Spring 2009
2/18/2019

8. Go-Back-N Sender: k-bit seq # in pkt header
“window” of up to N, consecutive unack’ed pkts allowed
ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
may receive duplicate ACKs (see receiver)
timeout(n): retransmit pkt n and all higher seq # pkts in window
CS 5565 Spring 2009
2/18/2019

9. GBN: Sender Extended FSM
Wait
start_timer
udt_send(sndpkt[base])
udt_send(sndpkt[base+1]) …
udt_send(sndpkt[nextseqnum-1])
timeout
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
nextseqnum++ }
else
refuse_data(data)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base=1
nextseqnum=1
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt) L
CS 5565 Spring 2009
2/18/2019

10. GBN: Receiver Extended FSM
Wait
udt_send(sndpkt)
default
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
expectedseqnum++
expectedseqnum=1
sndpkt =
make_pkt(expectedseqnum,ACK,chksum) L
ACK-only: always send ACK for correctly-received pkt with highest in-order seq #
may generate duplicate ACKs
need only remember expectedseqnum
out-of-order pkt:
discard (don’t buffer) -> no receiver buffering!
Re-ACK pkt with highest in-order seq #
CS 5565 Spring 2009
2/18/2019

11. GBN in action
CS 5565 Spring 2009
2/18/2019

12. Selective Repeat
receiver individually acknowledges all correctly received pkts
buffers pkts, as needed, for eventual in-order delivery to upper layer
sender only resends pkts for which ACK not received
sender timer for each unACKed pkt
sender window
N consecutive seq #’s
again limits seq #s of sent, unACKed pkts
CS 5565 Spring 2009
2/18/2019

13. Selective Repeat: Sender, Receiver Windows
CS 5565 Spring 2009
2/18/2019

14. Selective Repeat receiver sender data from above :
if next available seq # in window, send pkt
timeout(n):
resend pkt n, restart timer
ACK(n) in [sendbase,sendbase+N]:
mark pkt n as received
if n smallest unACKed pkt, advance window base to next unACKed seq #
pkt n in [rcvbase, rcvbase+N-1]
send ACK(n)
out-of-order: buffer
in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1]
ACK(n)
otherwise:
ignore
CS 5565 Spring 2009
2/18/2019

15. SR in action
CS 5565 Spring 2009
2/18/2019

16. Selective Repeat & Window Sizes
Example:
seq #’s: 0, 1, 2, 3
window size=3
receiver sees no difference in these two scenarios!
incorrectly passes duplicate data as new in (a)
Q: what relationship is required between seq # size and window size?
CS 5565 Spring 2009
2/18/2019

17. The Problem With Reordering
Pkt0
Sender
sends
Pkt1
retransmitted
Pkt0 is overtaken by
retransmits
Ack0
Ack1
Error: receiver expects Pkt0, and interprets delayed retransmitted Pkt0 as containing new data!
Receiver expected Pkt0, and sends ack when it arrives. Expects Pkt1 next.
Receiver expected Pkt1, and sends ack when it arrives. Expects Pkt0 next.
Receiver
Alternating Bit Protocol is special example of GBN(1)
CS 5565 Spring 2009
2/18/2019

18. Reordering What if packets can be reordered by underlying layer?
Does not usually happen for RDT in data link layer
But very possible for RDT over network layer
Model as loss + spontaneous reemission of first packet by channel
Solution: do not reuse sequence numbers unless there’s reasonable guarantee that packets with old numbers cannot reemerge
CS 5565 Spring 2009
2/18/2019

19. Summary Sliding Window Protocols Problems: GBN Go-Back-N
SR Selective Repeat
Alternate-Bit-Protocol = special case of GBN(1)
Problems:
Receiver’s view may not match sender’s view: sequence number range vs window size: seqrange >= 2 * wsize (assuming no reordering)
When channel can reorder: need additional timing constraints before reusing sequence numbers
No % perfect solution possible
CS 5565 Spring 2009
2/18/2019

20. Part 2: TCP Sockets & TCP Demultiplexing
Socket API
Part 2: TCP Sockets & TCP Demultiplexing

21. TCP Sockets Provide reliable byte-stream abstraction
In-order, reliable delivery of bytes
Connection-oriented
Client must connect(2)
Server performs “passive open” using accept(2)
CS 5565 Spring 2009
2/18/2019

22. TCP Sockets: Overview Left side: client Right side: server socket()
listen()
socket()
connection
setup
connect()
accept()
bind()
write()
read()
Left side:
client
Right side:
server
read()
write()
connection
shutdown
close()
close()
CS 5565 Spring 2009
2/18/2019

23. int connect(int sockfd, const struct sockaddr *peeraddr, int addrlen)
sockfd: returned by socket()
peeraddr: peer’s address (type sockaddr_in)
this initiates hand-shake with server
CS 5565 Spring 2009
2/18/2019

24. listen(2), accept(2) addr: accepted peer’s (aka client) address
int listen(int s, int backlog)
int accept(int s, struct sockaddr *addr, int *addrlen);
addr: accepted peer’s (aka client) address
of type sockaddr_in
listen() must precede accept
No network traffic, but informs OS to start queuing connection requests
accept() returns new socket
But does not assign new port – why not?
CS 5565 Spring 2009
2/18/2019

25. TCP Demultiplexing 10.0.0.1:80 ??? D: 10.0.0.1:80 10.0.0.1 10.0.0.2
socket()
bind(*, 80)
listen(5)
:80
??? D: :80
connect( ,80)
socket()
S: :3045 D: :80
S: :80 D: :3045
accept()
S: :80 D: :512
S: :80 D: :2047
S: :2047 D: :80
S: :512
bind( ,512)
S: :512 D: :80
connect( ,80)
CS 5565 Spring 2009
2/18/2019

26. Utility Functions in_addr_t inet_addr(const char *cp);
char *inet_ntoa(struct in_addr in);
int gethostname(char *name, size_t len);
int getpeername(int s, struct sockaddr *name, socklen_t *namelen);
int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
int getsockopt(int s, int level, int optname, void *optval, socklen_t *optlen);
int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);
struct hostent *gethostbyname(const char *name);
struct hostent *gethostbyaddr(const char *addr, int len, int type);
int getaddrinfo(const char *node, const char *service, const struct addrinfo *hints, struct addrinfo **res);
void freeaddrinfo(struct addrinfo *res);
CS 5565 Spring 2009
2/18/2019

27. struct hostent struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */ }
Note: IPv4 addresses, *h_addr_list points to array of long (32-bit)
Struct hostent *hent = gethostbyname(hostname);
If (hent == 0) { herror(hostname); exit(-1); }
addr = ((long*)*hent->h_addr_list)[0];
extracts first IP for host. As always, in network order!
CS 5565 Spring 2009
2/18/2019

28. Common Pitfalls (3) What is wrong with this code?
struct sockaddr_in server1addr;
struct sockaddr_in server2addr;
/* not shown: initialize server1addr, server2addr */
printf(“using server 1 at %s and server 2 at %s\n”,
inet_ntoa(serveraddr1.sin_addr),
inet_ntoa(serveraddr2.sin_addr));
Beware of statically allocated buffers!
Use alternatives where available: inet_ntop, getaddrinfo, etc.
CS 5565 Spring 2009
2/18/2019

29. Java Binding Does not expose byte order
gethostbyname() is hidden (use a “String” as a hostname to get default 1st IP address)
Does not expose bind/listen directly
Use different types for different sockets:
DatagramSocket, Socket, ServerSocket
Does not expose universal file descriptor
CS 5565 Spring 2009
2/18/2019