User:Shealer/sandbox

This is the user sandbox of Shealer. A user sandbox is a subpage of the user's user page. It serves as a testing spot and page development space for the user and is not an encyclopedia article. Create or edit your own sandbox here. Other sandboxes: Main sandbox | Template sandbox Finished writing a draft article? Are you ready to request review of it by an experienced editor for possible inclusion in Wikipedia? Submit your draft for review!

In transmit flow control, sliding window is a variable-duration window that allows a sender to transmit a specified number of data units before an acknowledgement is received or before a specified event occurs. An example of a sliding window in packet transmission is one in which, after the sender fails to receive an acknowledgement for the first transmitted packet, the sender "slides" the window, i.e. resets the window, and sends a second packet. This process is repeated for the specified number of times before the sender interrupts transmission. Sliding window is sometimes (loosely) called acknowledgement delay period. For example, supposing a fixed window size of ${\displaystyle m}$ packets, a sender may send out packets ${\displaystyle [n\ldots (n+m-1)]}$ before receiving any acknowledgement. If acknowledgement arrives from the receiver for packet ${\displaystyle n}$, then (a) the sender is able to send out packet ${\displaystyle (n+m)}$, (b) it doesn't need acknowledgement for packet ${\displaystyle n}$ anymore; thus the range (window) of unacknowledged packets slides to ${\displaystyle [(n+1)\ldots (n+m)]}$. In some way, "sliding" means a FIFO operation, trimming the range at one end, extending it at the other end. The purpose of the sliding window is to increase throughput. Let's denote the round trip time with RTT. The time necessary to transfer and acknowledge ${\displaystyle K}$ (a big number of) packets is roughly ${\displaystyle \operatorname {RTT} \cdot K/(2m)}$ (in one round trip, ${\displaystyle 2m}$ packets and ${\displaystyle 2m}$ ACKs are delivered). However, the size of the window (in bytes) should not grow above "capacity of the path" (the sum of affected network buffer sizes of all hops along the path); windows too big don't increase throughput, just latency, number of packets transmitted out-of-order, and memory usage. In practice, protocols often adapt the window size to the link's speed and actual saturation or congestion. === See also === * Federal Standard 1037C * RFC 1323 - TCP Extensions for High Performance * TCP window scaling and broken routers, 2004 * Sliding Window Demo (Flash required) * Sliding Window Demo (Shockwave required)