Unformatted text preview: the chapter, there is no single way to exchange bulk data using TCP. It is
a dynamic process that depends on many factors, some of which we can control (e.g., send
and receive buffer sizes) and some of which we have no control over (e.g., network
congestion, implementation features). In this chapter we've examined many TCP transfers,
explaining all the characteristics and algorithms that we could see.
Fundamental to the efficient transfer of bulk data is TCP's sliding window protocol. We then
looked at what it takes for TCP to get the fastest transfer possible by keeping the pipe
between the sender and receiver full. We measured the capacity of this pipe as the
bandwidth-delay product, and saw the relationship between this and the window size. We
return to this concept in Section 24.8 when we look at TCP performance.
We also looked at TCP's PUSH flag, since we'll always see it in trace output, but we have no
control over its setting. The final topic was TCP's urgent data, which is often mistakenly
called "out-of-band data." TCP's urgent mode is just a notification from the sender to the
receiver that urgent data has been sent, along with the sequence number of the final byte of
urgent data. The programming interface for the application to use with urgent data is often
less than optimal, which leads to much confusion.
20.1 In Figure 20.6 we could have shown a byte numbered 0 and a byte numbered 8193.
What do these 2 bytes designate?
20.2 Look ahead to Figure 22.1 and explain the setting of the PUSH flag by the host bsdi. file:///D|/Documents%20and%20Settings/bigini/Docu...homenet2run/tcpip/tcp-ip-illustrated/tcp_bulk.htm (23 of 24) [12/09/2001 14.47.22] Chapter 20. TCP Bulk Data Flow 20.3 In a Usenet posting someone complained about a throughput of 120,000 bits/sec on a
256,000 bits/sec link with a 128-ms delay between the United States and Japan (47%
utilization), and a throughput of 33,000 bits/sec when the link was routed over a satellite
View Full Document
- Spring '12