Up until now, our discussions about network applications have asssumed that the reliability and capacity of the underlying network is sufficient for the task at hand. With the continued growth of wireless communications devices, as well as the ever-increasing use of multimedia content in networked applications, it's important to consider situations where this assumption is not valid--in other words, in situations where the distributed system is bandwidth-limited.
After a brief discussion of the overall topic of limited bandwidth, we'll show a framework for doing some crude bandwidth monitoring, built within the I/O stream classes in java.io. Then we'll show a general content consumer/ producer model that could be used in conjunction with the bandwidth monitoring utilities to implement adaptive buffering for data being streamed over the network.
An application can be considered bandwidth-limited in two ways. First, the application can have relatively high bandwidth requirements (compared to average applications) that the communications scheme can't fully support. An application falls into this category when the required rate of data flow is very close to the capacity of the network connection. Streaming high-quality video for real-time playback is one such application--a constant, high-throughput, reliable network connection is necessary to support distributed video.
Bandwidth is also limited when the network connection has relatively low or unreliable capacity (compared to average network connections), and is insufficient for many data transactions. Current telephone modem throughput rates, for example, are insufficient to support downloading high-quality multimedia in real time. Many wireless communications schemes can be unreliable to the point that their effective throughput is much lower than their peak throughput, and a bandwidth-limited situation occurs.
In either case, the data requirements of the application exceed the available bandwidth, so measures must be taken to handle this situation without degrading our application's behavior unacceptably.
Copyright © 2001 O'Reilly & Associates. All rights reserved.