Slicing the Windows Communication Foundation Technology Stack, Part 5

In this series, I've gone through one set of problems that we encounter with buffered transfers, and a different set of problems that we encounter with streamed transfers.  Each mode has its advantages, although it would be really nice if we could combine the strengths of both.  Buffered transfers give us flexibility in choosing the security mechanism.  Streamed transfers are more scalable.  It turns out there is a way to essentially combine the properties of both modes.  Even better, we can fix one more performance problem by doing so.

Steve's service has a problem that is hard to notice until you move from a development environment to a deployed environment.  The problem comes from the system requirement that we must support clients over flaky connections.  Reliable messaging is used to guarantee that messages are retransmitted if there is a connection problem.  However, reliable messaging is done at the message level, and small errors can cause a retransmission of an entire large message.  Bad things will happen if a client has a connection with a high error rate relative to the size of the message.  The server will continuously retransmit the message until the send operation times out, tying up server resources without making any progress sending data to the client.

A way to solve all of these problems is to redefine what we use as a message.  Chunking is a technique that splits a large message into many smaller messages.  Since the messages are now small, we can use buffered transfers without worrying about increased memory use.  Since we have buffered transfers, we don't have to worry about changing the security mode or channel shape.  And, we can apply reliable messaging to each individual chunk so that a message failure only requires the server to retransmit a small message.

Here's a look at the same architecture, from the SOAP level down, with chunking instead of streaming.  Since buffered transfers can use either message or transport security, I've left the security at the transport level:

Tomorrow, I'll conclude this little series by looking at a few more performance problems that are hard to notice until you have dozens of clients hitting your server.

Next time: Slicing the Windows Communication Foundation Technology Stack, Part 6

Comments

• Anonymous
  February 16, 2006
  Yesterday, we looked at an architecture change from a buffered transport strategy to a streamed transport...
• Anonymous
  February 17, 2006
  The comment has been removed
• Anonymous
  February 17, 2006
  The comment has been removed
• Anonymous
  February 18, 2006
  The architecture we saw last time is actually a nice solution to the original web service problem. ...
• Anonymous
  October 17, 2006
  Yesterday, we looked at an architecture change from a buffered transport strategy to a streamed transport