CS作业代写 Computer Networking and Applications – cscodehelp代写 – INTERVIEW&CODEHELP

Computer Networking and Applications
• The Transport Layer is responsible for providing logical communication between processes. Uses the services of the Network Layer to (try) to transfer data between processes.
• The TL relies on the services of the Network layer protocol, so it is limited
in the services it can provide.

Transport Layer
application
data link physical
application
data link physical

Computer Networking and Applications
The Internet Transport Layer offers two services
They are different and we will look at them both.
Transport Layer
application
data link physical
application
data link physical

Computer Networking and Applications
Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple sockets, add transport header (later used for demultiplexing)
demultiplexing at receiver:
use header info to deliver received segments to correct socket
application
application
application

Computer Networking and Applications
Connectionless demux: example
DatagramSocket mySocket2 = new DatagramSocket
DatagramSocket serverSocket = new DatagramSocket
DatagramSocket
mySocket1 = new
DatagramSocket
application
application
application

Computer Networking and Applications
DatagramSocket mySocket2 = new DatagramSocket
DatagramSocket serverSocket = new DatagramSocket
DatagramSocket
mySocket1 = new
DatagramSocket
application
Connectionless demux: example
source port: 9157 dest port: 6428
source port: 6428 dest port: 9157
source port: ? dest port: ?
source port: ? dest port: ?
application
application

Computer Networking and Applications
Connectionless demultiplexing
recall: created socket has host-local port #:
 recall: when creating datagram to send into UDP socket, must specify
 destination IP address  destination port #
IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest
DatagramSocket mySocket1
= new DatagramSocket(12534);
when host receives UDP segment:
 checks destination port # in segment
 directs UDP segment to socket with that port #
Transport Layer 3-7

Computer Networking and Applications
Connection-oriented demux: example
application
application
host: IP address A
host: IP address C
application
server: IP address B

Computer Networking and Applications
Connection-oriented demux: example
application
application
host: IP address A
source IP,port: B,80 dest IP,port: A,9157
source IP,port: A,9157 dest IP, port: B,80
server: IP address B
source IP,port: C,5775 dest IP,port: B,80
source IP,port: C,9157 dest IP,port: B,80
host: IP address C
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
application

Computer Networking and Applications
Connection-oriented demux
TCP socket identified by 4-tuple:
 source IP address
 source port number  dest IP address
 dest port number
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
 non-persistent HTTP will have different socket for each request

Computer Networking and Applications
Transport Layer Services
• The fundamental service of TCP and UDP is to extend the Network Layer packet delivery service provided by IP between hosts to a delivery service between processes
TCP and UDP both provide
multiplexing and de-multiplexing of data from several processes
• UDP provides
– best effort delivery
application
application
data link physical

Computer Networking and Applications
User Datagram Protocol (UDP) • no connection establishment
(which can add delay)
• simple: no connection state at sender, receiver
• small segment header
• no congestion control: UDP can
blast away as fast as desired
• can add reliability at application layer
• 1’s complement checksum can be used to detect (but not correct) errors. (example)
• segments can be lost or delivered to application out of order.
• each segment is independent of others.
Length, in bytes of UDP segment, including header
source port #
Application data
UDP segment format
dest port #
©Kurose & Ross, 2002

Computer Networking and Applications
UDP: segment header
length, in bytes of UDP segment, including header
why is there a UDP?
source port #
UDP segment format
dest port #
application data (payload)
no connection establishment (which can add delay)
simple: no connection state at sender, receiver
small header size
no congestion control: UDP can blast away as fast as desired

Computer Networking and Applications
Reliable Data Transfer
• Many applications want reliable data transfer, so many
transport layer protocols provide this.
• The service level of the underlying network may vary. Assume the TL needs to deal with errors and loss of data packets.
• Start with the assumption of a reliable network and progressively add in mechanisms for dealing with errors… (on blackboard)

Computer Networking and Applications
Principles of reliable data transfer
 important in application, transport, link layers • top-10 list of important networking topics!
 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Computer Networking and Applications
Reliable data transfer: getting started
rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer
deliver_data(): called by rdt to deliver data to upper
send receive side side
udt_send(): called by rdt, to transfer packet over unreliable channel to receiver
rdt_rcv(): called when packet arrives on rcv-side of channel

Computer Networking and Applications
Reliable data transfer: getting started
• incrementallydevelopsender,receiversidesof
reliable data transfer protocol (rdt)
• consideronlyunidirectionaldatatransfer
– but control info will flow on both directions!
• use finite state machines (FSM) to specify sender,
state: when in this “state” next state uniquely determined by next event
event causing state transition actions taken on state transition
event actions

Computer Networking and Applications
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 reads data from underlying channel
Wait for call from above
rdt_send(data)
packet = make_pkt(data) udt_send(packet)
Wait for call from below
rdt_rcv(packet)
extract (packet,data) deliver_data(data)

Computer Networking and Applications
rdt2.0: channel with bit errors
 underlying channel may flip bits in packet • checksum 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
How do humans recover from “errors”
 new mechanisms in rdt2.0 (beyond rdt1.0): during conversation?
• errordetection
• receiverfeedback:controlmsgs(ACK,NAK)rcvr->sender

Computer Networking and Applications
rdt2.0: channel with bit errors
 underlying channel may flip bits in packet • checksum 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):
• errordetection
• feedback:controlmsgs(ACK,NAK)fromreceiverto sender

Transport Layer
Computer Networking and Applications
rdt2.0: FSM specification
rdt_send(data)
sndpkt = make_pkt(data, checksum)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
udt_send(NAK)
Wait for call from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from above
Wait for ACK or NAK

Transport Layer
Computer Networking and Applications
rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(sndpkt)
Wait for call from above
Wait for ACK or NAK
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
udt_send(NAK)
Wait for call from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Transport Layer
Computer Networking and Applications
rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(sndpkt)
Wait for call from above
Wait for ACK or NAK
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
udt_send(NAK)
Wait for call from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Computer Networking and Applications
what happens if ACK/NAK corrupted?
• sender doesn’t know what happened at receiver!
• can’t just retransmit: possible duplicate
handling duplicates:
• sender retransmits current pkt if ACK/NAK corrupted
• sender adds sequence number to each pkt
rdt2.0 has a fatal flaw!
• receiver discards (doesn’t stop and wait deliver up) duplicate pkt
sender sends one packet, then waits for receiver response

Computer Networking and Applications
rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) )
udt_send(sndpkt)
Wait for call 0 from above
Wait for ACK or NAK 0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) )
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for ACK or NAK 1
rdt_send(data)
sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)
Wait for call 1 from above

Computer Networking and Applications
rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && has_seq1(rcvpkt)
sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)
extract(rcvpkt,data) deliver_data(data)
sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
Wait for 0 from below
Wait for 1 from below
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data) deliver_data(data)
sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

Transport Layer
Computer Networking and Applications
• seq # added to pkt
• twoseq.#’s(0,1)will
suffice. Why?
• must check if received ACK/NAK corrupted
• twiceasmanystates
– state must “remember” whether “expected” pkt should have seq # of 0 or 1
 must check if received packet is duplicate
• stateindicateswhether0 or 1 is expected pkt seq #
 note: receiver can not know if its last ACK/NAK received OK at sender
rdt2.1: discussion

Computer Networking and Applications
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
 duplicate ACK at sender results in same action as NAK: retransmit current pkt

Computer Networking and Applications
rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
Wait for call 0 from above
Wait for ACK 0
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||
isACK(rcvpkt,1) ) udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) && isACK(rcvpkt,0)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||
has_seq1(rcvpkt)) udt_send(sndpkt)
Wait for 0 from below
sender FSM fragment
receiver FSM fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data) deliver_data(data)
sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)

Transport Layer
Computer Networking and Applications
rdt3.0: channels with errors and loss
new assumption: underlying channel can also lose packets (data, 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 seq. #’s already handles this
– receiver must specify seq # of pkt being ACKed
• requires countdown timer

Computer Networking and Applications
rdt3.0 senderrdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)
start_timer L
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
Wait for call 0from above
Wait for ACK0
timeout udt_send(sndpkt) start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) && isACK(rcvpkt,0)
stop_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) && isACK(rcvpkt,1)
stop_timer
udt_send(sndpkt) start_timer
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )
Wait for ACK1
Wait for call 1 from above
rdt_rcv(rcvpkt)
rdt_send(data)
sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)
start_timer

Computer Networking and Applications
rdt3.0 in action
rcv ack0 send pkt1
rcv ack1 send pkt0
receiver sender
rcv pkt0 send ack0
rcv pkt0 ack0 send ack0
rcv pkt1 ack1 send ack1
pkt0 rcv pkt0 ack0 send ack0
(a) no loss
send pkt0 pkt0 rcv ack0 ack0
send pkt1 pkt1 X
resend pkt1
rcv pkt1 ack1 send ack1
rcv pkt0 ack0 send ack0
rcv ack1 send pkt0
(b) packet loss

Transport Layer
Computer Networking and Applications
rdt3.0 in action
rcv ack0 send pkt1
rcv pkt0 send ack0
rcv pkt1 send ack1
rcv ack0 send pkt1
pkt0 rcv pkt0 ack0 send ack0
pkt1 rcv pkt1 ack1 send ack1
resend pkt1
rcv ack1 send pkt0
rcv ack1 send pkt0
rcv pkt1 (detect duplicate)
resend pkt1
ack1 (detect duplicate)
rcv pkt0 ack0 send ack0
rcv ack1 send pkt0
rcv pkt0 send ack0
rcv pkt0 (detect duplicate)
(c) ACK loss
send ack0 (d) premature timeout/ delayed ACK

Computer Networking and Applications
Need for Pipelining
• 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
T = 8Kb/pkt = 8 microsec/packet transmit 10**9 b/sec
Utilization = U = fraction of time sender busy sending
= 8 microsec = 0.00027 30.008 msec
1KB pkt every 30 msec -> 33KB/sec thruput over 1 Gbps link network protocol limits use of physical resources!
©Kurose & Ross, 2002

Computer Networking and Applications
– onetimer
– on timeout, retransmit all packets in window from last ACK + 1
• Receiver
– cumulativeACK
– discard out of order packets
• Advantages & disadvantages
©Kurose & Ross, 2002

Computer Networking and Applications
Selective Repeat – window size
rseq #’s: 0, 1, 2, 3
rwindow size=3
rreceiver sees no difference
in two scenarios
rincorrectly passes duplicate data as new in (a)
Q:what is the relationship between seq# size and window size?
©Kurose & Ross, 2002

Computer Networking and Applications
• TCP is designed to provide the appearance of a reliable channel
over the unreliable network layer (IP).
• In addition to the checksum and multiplexing as provided by UDP, TCP also provides flow control and congestion control and a reliable connection.
• The channel, or connection, is not a virtual circuit. All state information resides in the sending and receiving hosts, not in the routers.
• TCP deals with
– Lost packets
– Re-ordered packets – Delayedpackets
• TCP is a modified hybrid of go-back-N and selective repeat. Cumulative ACKs. Only ACK up to correctly received segments.
RFCs 793, 1122, 1323, 2018, 2581

Computer Networking and Applications
User Datagram Protocol (UDP) • no connection establishment
(which can add dela

程序代写 CS代考加微信: cscodehelp QQ: 2235208643 Email: kyit630461@163.com

CS作业代写 Computer Networking and Applications – cscodehelp代写

Published by admin

Leave a Reply Cancel reply