Re: Flow Control In UDP/TCP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:e4TloO$RIHA.5164@xxxxxxxxxxxxxxxxxxxxxxx
1. For flow control we are interested in the send window at
the sender and the congestion window also at the sender.
The send window decreases each time new data is sent from
the buffer (e.g. not a retransmission) and increases with TCP
ACKs of previously sent data (acknowledged by the receiver).
When the send window closes the sender stops sending new
data until it opens again. The other factor to consider is also the
congestion window. It's a bit more complicated and it does not
involve the receiver directly. The congestion window's purpose
is to indicate how much data can we stuff into the pipe to the
receiver before congestion occurs. Unlike the send window
whose size is static (configured during the TCP 3-way handshake)
the congestion window size is dynamic. It's increased as the
sender stuffs more data into the pipe and contracts each time
packet loss is registered (TCP assumes packet loss to be due
to congestion). Otherwise the congestion window closes and
opens just like the send window. The sender stops sending
when either the send or the congestion window is closed.

2. If you stop receiving on your UDP socket, incoming data
is not auomatically discarded. It's stored in your UDP socket's
receive buffer and new datagrams only get discarded once that
buffer is full.

Furthermore, if you are trying to receive but not getting anything, there
are three options:

(1) Nothing is being sent.
(2) It's being lost in the network, due to queue overflow, random early
drop, routing problems, etc.
(3) Your computer is discarding the packet due to a bad checksum or a
firewall rule.

A packet sniffer such a wireshark, run on both sender and receiver, is
helpful to find out which.


--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"mmlab_js" <mmlabjs@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:08E7C3D7-F182-4E5A-8A50-514D5F261B6B@xxxxxxxxxxxxxxxx
Hi,
I know that TCP provides flow control, but UDP doesn't. But I have three
questions:
1. For TCP, as data is received from the sender, the window size
decreases.
When the window size reaches 0, but the data is still coming. How is the
data
been processed?
2. For UDP, If I don't receive any incoming data, is the data been
discarded???




.

Relevant Pages

  • Re: download peak control
    ... But this does apply to the sender side mostly. ... ie some amount of buffer space the sender may ... aggregated size is as large as the announced window size (the window ... receiver again announces the availabilty of 'some amount of buffer ...
    (comp.os.linux.development.apps)
  • Re: [9fans] telnet vs. godaddy whois
    ... A good example of how correct behaviour can get ... byte of data when it knows the receiver's window is closed? ... TCP provides a means for the receiver to govern the amount of data ... sent by the sender. ...
    (comp.os.plan9)
  • Re: Flow Control In UDP/TCP
    ... For flow control we are interested in the send window at ... the sender and the congestion window also at the sender. ... ACKs of previously sent data (acknowledged by the receiver). ...
    (microsoft.public.win32.programmer.networks)
  • Re: TCP receive window behavior
    ... > application is fast enough that the receiver window is never reduced. ... > Say the receiver has a receive buffer space of R bytes. ... As far as I know, the ramp up is controlled by the sender, not the receiver. ...
    (comp.os.linux.networking)
  • Re: Ethernet Performance Testing and throughput
    ... limitations of such a circuit. ... Gaak, iperf:) Seriously, offline feel free to let me know what might ... One might refer to an "effective window size" which would be ... there is in addition to the Rx window a Tx Congestion window. ...
    (comp.dcom.lans.ethernet)