Buffered vs. Streamed Messages


When we think of messages moving between endpoints, we instinctively think in terms of buffers. To put it another way, we typically assume that when our application has received a Message, it has knowledge of the Message in its entirety. This type of behavior is known as buffering. The converse of buffering is known as streaming, and there are two ways that streaming communication can occur. The first mechanism resembles a push model, where the sender is pushing bytes to the receiver at its own cadence. When streaming content is moved in this way, the sender writes data until its local buffer is full, the data is transmitted to the receiver, and the receiver reads data from its local buffer as it arrives. The second mechanism resembles a pull model. When streaming content is moved in this way, the receiver requests bytes from the sender, and upon receipt of this request, the sender sends the requested number of bytes. This process is repeated in a loop until the sender has no more bytes to send. The WCF infrastructure implements the latter streaming methodology.

In WCF, the header blocks of a Message are always buffered, and the body of a Message is either buffered or streamed. The default maximum size of this buffer is 64 KB. (You will see how to change this setting in Chapter 8.) If the body of a Message is streamed, its size is unbounded. In practical terms, this means that we can transmit streaming media in WCF. Not all messages have streamed body elements. For example, small messages do not need to be streamed; buffers effectively handle them. Furthermore, a large Message is inherently difficult to validate. Consider, as an example, the case of a sending a 30-minute home movie in a streamed body element. The movie probably has value on its own and can be shown to the end user before the end tags are received. If the stream ends and no end tags are sent, handling the error becomes nearly impossible, because the end user has probably already seen the data. Likewise, if an application applies a digital signature to the stream, the signature can be vaidated only after the entire stream has been received and buffered, thereby largely defeating the purpose of using a streamed body.




Inside Windows Communication Foundation
Inside Windows Communication Foundation (Pro Developer)
ISBN: 0735623066
EAN: 2147483647
Year: 2007
Pages: 106
Authors: Justin Smith

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net