Hannibal the Cannibal on Class and Method Design

Everything I know about class and method design I learned from Hannibal Lecter.

OK that's not exactly true, but the first, most basic, and in many ways most important thing that I learned about class and method design I learned from the good doctor. Before there was IoC, dependency injection, MVC, MVP, the Open Close Principal, or Liskov's Substitution Principal. Before there was even encapsulation and loose coupling, there was Hannibal Lecter's First Principle:

As software developers we live in a world of unbounded complexity. Most of the design principles that we have developed over the years represent, at their heart, our effort to beat down and shackle that complexity: to build walls around complex systems and declare, "Beyond this point none shall pass!"(encapsulation), to clearly define responsibilities, declaring "A shall do thus, and B shall do thus, and never shall the one take up the task of the other" (abstraction, loose coupling, MVC, MVP). We keep these ideas ever in our minds as we develop the classes and methods that implement the solutions that earn us our daily bread.

But the advice we should turn to most often is that of Hannibal Lecter. His words should ring in our ears throughout each day: each thing that we develop, each method, each class -- what is it? Step back from the problem you are trying to solve for a moment, and look at each one of our little creations in isolation. Each is deserving of its own identity, its own purpose, its own place in the cosmos. Each deserves to have a life of its own, unique and independent of the lives of its brothers and sisters. Software is complex enough without having to remember the particular problem that the author of a class or method was working on at the time he or she wrote it. As Abraham Lincoln once said, "the world will little note nor long remember the context in which the method was written, but the method itself will live on."

Sometimes it's not easy to step back and focus on the individual pieces of our solution in isolation from the rest. It takes a change of gears, a certain adjustment of perspective. In the following clip we see Hannibal guide Clarice in finding the true essence of the class she's working on. As with many of the good doctor's creations, it may be best that we don't try to guess its exact purpose, though it does appear to be a subclass of a class called "Man":

As always, the good doctor gets straight at the heart of the matter. The purpose of this class is not to be found in the particular use to which it's currently being put. It has a more basic, more fundamental nature.

At this point it may be best not to try to draw concrete examples out of the problem Hannibal and Clarice are working on. Instead, I'll give three brief examples from some code I reviewed just last week. The names of the methods and the classes will of course be changed to protect the innocent: these types of problems disturb the good doctor greatly, and it's best not to upset him.

namespace HannibalsFirstPrinciple

{

    public class ViolationNumberOne

    {

        // Called before running the batch process

        public void Foo()

        {

            // Does some stuff

        }

    }

}

Any time you see a comment like the one on the public method "Foo" shown here, alarm bells should start ringing in your head. You don't have to read the method body to know that Hannibal's First Principle has been violated. This is a public method on a public class. Who's to say that Foo will always be called before running the batch process? The client can call Foo whenever it likes! And what the heck is "the batch process" anyway? It sounds like some piece of some particular problem the author of this class was working on at the time he or she created it. Clearly the author wrote this with a single-minded focus on one particular problem that he or she was working on, and never took the time to think about what this class is in and of itself.

This programmer would not be producing code of this sort today if he or she had studied under doctor Lecter. Here's another example:

namespace HannibalsFirstPrinciple

{

    public class Account

    {

        public int Amount { get; set; }

    }

    public class ViolationNumberTwo

    {

        private const int MAX_ACCOUNT_AMOUNT = 10000;

        public void ValidateAccounts()

        {

            var account = new Account() { Amount = 5000 };

            Console.WriteLine(IsAccountOverTheLimit(account.Amount, MAX_ACCOUNT_AMOUNT));

        }

        private bool IsAccountOverTheLimit(int value1, int value2)

        {

            return value1 > value2;

        }

    }

}

Consider the method IsAccountOverTheLimit. In the context of the entire program, it seems reasonable enough: it checks the amount in an account against the maximum value allowed. But what does it really do? In fact, IsAccountOverTheLimit itself has nothing to do with accounts or limits at all. It simply compares two integers; it's the client that gives these particular meanings to the method. Had the author studied under doctor Lecter (and survived), he or she would have written the method this way:

        private bool IsAccountOverTheLimit(Account account)

        {

            return account.Amount > MAX_ACCOUNT_AMOUNT;

        }

Or perhaps this way:

        public static bool IsGreaterThan(this int thisNumber, int numberToCompere)

        {

            return thisNumber > numberToCompere;

        }

Either make the method a full-fleshed citizen of the world by giving it all the rights and responsibilities implied by its name, or change its name so that it can declare its true purpose in life with honesty and dignity.

And the final example gets to the heart of understanding the essence of a class, and of maintaining its simplicity:

namespace HannibalsFirstPrinciple

{

    public class Account

    {

        private int _amount;

        private readonly bool _isInterestBearing;

        public Account() { }

        public Account(bool isInterestBearing)

        {

            _isInterestBearing = isInterestBearing;

        }

        public int Amount

        {

            get

            {

                return _isInterestBearing ? (int)(1.1 * _amount) : _amount;

            }

            set { _amount = value; }

        }

    }

}

The programmer here as cluttered up a perfectly good Account class with a lot of extra nonsense that many clients of the class probably don't care about. If you have a special use for a class, specialize it! Don't introduce complexity when simplicity will do:

namespace HannibalsFirstPrinciple

{

    public class Account

    {

        public int Amount { get; set; }

    }

    public class InterestBearingAccount : Account

    {

        private int _amount;

        public int Amount

        {

            get

            {

                return (int)(1.1 * _amount);

            }

            set { _amount = value; }

        }

    }

}

These examples seem silly and simplistic because they've been constructed to shine the light of day on these problems, but in the real world these anti-patterns can easily hide amid the complexity of our code, and it's important to note that I saw examples like these in real production code just this week. These types of problems can bite any of us unless we keep our vigilance, unless we keep doctor Lecter's words of wisdom ever ringing in our ears.

Or if doctor Lecter has used too many words for you to remember, then at least remember this exhortation by one of his students, who has clearly grasped the essence and urgency of his lesson:

Safe and happy coding all!

Effect on WCF web service performance of the Tcp window size in high-latency Windows networks

In my last post I looked at the effect of a bug in WCF on Windows XP and W2K3, in which the Tcp connection used by web services that use TransferMode "Streamed" or "StreamedRequest" is closed after every call. This forces subsequent calls to re-establish the Tcp and, if in use, SSL connection(s) at the start of every call, which can have serious performance consequences.

TCP Window Size and Performance on High-Latency Networks

As a follow-up, I'd like to look at the effect of adjusting the Tcp window size on performance. This and this do an excellent job of describing what the Tcp window is, how it affects Tcp traffic in high-latency, high-bandwidth environments, and how to set it. I won't try to duplicate all that here, except to quote as a brief overview two snippets from this MSDN article on it:

TCP window size

The TCP receive window size is the amount of receive data (in bytes) that can be buffered during a connection. The sending host can send only that amount of data before it must wait for an acknowledgment and window update from the receiving host. The Windows TCP/IP stack is designed to self-tune itself in most environments, and uses larger default window sizes than earlier versions.

....

Windows scaling

For more efficient use of high bandwidth networks, a larger TCP window size may be used. The TCP window size field controls the flow of data and is limited to 2 bytes, or a window size of 65,535 bytes.

Since the size field cannot be expanded, a scaling factor is used. TCP window scale is an option used to increase the maximum window size from 65,535 bytes to 1 Gigabyte.

The window scale option is used only during the TCP 3-way handshake. The window scale value represents the number of bits to left-shift the 16-bit window size field. The window scale value can be set from 0 (no shift) to 14.

To calculate the true window size, multiply the window size by 2^S where S is the scale value.

For Example:

If the window size is 65,535 bytes with a window scale factor of 3.

True window size = 65535*2^3

True window size = 524280

Increasing this setting in high-latency, high-bandwidth environments can help improve performance because it helps prevent the sender from delivering all the bytes in its buffer before the receiver has a chance to acknowledge receipt of the packets. When that happens the sender has to pause until the ACKs start coming in, resulting in a herky-jerky, slow connection.

What the Tcp Window Size Affects

One thing I didn't understand about the Tcp Window Size setting until I conducted these tests is that it is a receive buffer. When configured on machine A, it tells any potential sending machine B the size of the buffer it should use when sending data to machine A. This was unintuitive to me. Also, machines A and B can use different Tcp window sizes during the same connection. Machine A uses the buffer size configured on machine B when machine A sends data to B, and machine B uses the buffer configured on machine A when machine B sends data to A.

Testing the Affect of Various Tcp Window Sizes

The following tests were conducted with a WCF service host running on Windows XP, with a Vista client. The Tcp window size can't be configured on Vista (or W2K8) the way it can on XP and W2K3; Microsoft has replaced it with Tcp Window Auto-tuning, which they believe renders the TcpWindowSize registry setting obsolete. We'll take a look at that as well. The tests were all conducted using 250ms latency simulated using the WANemulator, on a wireless 8011n network with approximately 30 Mbits of bandwidth.

The tests use essentially the same simple WCF client and host application that I used in my last post, except that I now have 3 web services instead of 1:

• GetStringData: A simple web service that takes a string parameter and returns it in its return value. I run two tests with this service, one in which I transfer a small "Hi mom" string back and forth, and one in which I transfer a larger string, a 277KB JPEG of my daughter:

My daughter Kaitlin

• GetStreamedData: A web service that gets a Stream from the server.
• PutStreamedData: A web service that sends a Stream to the server.

For these tests I'm using GetStreamedData and PutStreamedData to transfer a 3.9 MB movie of a bear:

A bear

Both the picture of Kaitlin and the bear video are already compressed, so there's no worry about anyone else compressing them again and skewing the results.

The Test WCF Host Application

As before, the WCF host, which is running on the XP machine, is a simple console app:

Which hosts this service:

That uses the following, simple bindings:

The Test WCF Client Application

The client uses similar bindings:

And is also a simple console app:

Results of the Tests - XP

I exercised all of the web service calls against an XP machine that was configured to use Tcp Window scale modes of 0, 1, 2 and 3. A scale mode of "0" means Tcp1323Opts (the registry setting that enables Tcp Window sizes greater than 64K) is disabled, and the TcpWindowSize is the default value of roughly 64K. Scale mode 1 means TcpWindowSize is roughly 2^1 x 64K, scale mode 2 means TcpWindowSize is roughly 2^2 x 64K, etc.

The results for the PutStreamedData call are as follows:

Seconds per PutStreamedData web service call, by TcpWindowSize scale mode. Click on the image to open it in a larger window.

This graph shows the amount of time each PutStreamedData web service call takes, based on the TcpWindowSize scale mode configured on the XP machine.

The three streamed transfer mode bindings perform the worst, with streamed NetTcp the worst of all. This matches what I found in my last post when I tested large string-based payloads (I was too lazy in that post to test web services that use Stream parameters). Binding performances get significantly better with a TcpWindowSize scale mode of 1, and after that there's no improvement. The other binding types all start out at about the same performance level, except for buffered NetTcp, which is the best of all. But they separate from one another as the TcpWindowSize is increased, and ultimately buffered BasicHttp and WS2007 perform the best, buffered NetTcp comes in second, and buffered BasicHttp with SSL comes in as the worst of the rest, but still much better than the streamed bindings. This differs from what I saw in my last post, where buffered NetTcp was the runaway performance king in all tests.

Remember that the graph above represents streamed data moving from a Vista machine to an XP machine. The TcpWindowSize has been configured as a registry setting on the XP machine. During the Tcp handshake, it has been passed from the XP machine to the Vista machine, which uses it to determine how many bytes it can send at a time, before receiving ACKs from the XP machine.

Results of the Test - Vista

Now let's look at how data that's sent from XP to Vista looks:

Seconds per GetStreamedData web service call, by TcpWindowSize scale mode on the XP machine

Here we see the bindings sorting themselves into two groups. The results are much more variable when sending data from XP to Vista than they were in the other direction, but doesn't appear to vary based on the TcpWindowSize that was configured on the XP machine. This validates the idea that Vista is relying on Tcp Window Auto-tuning, and not the TcpWindowSize configured on the host machine, to optimize the connection.

The Effect of Increased Tcp Window Sizes in a Packet Trace

The fact that the Vista machine and XP machine are using different Tcp window sizes can easily be seen in this Wireshark packet trace, taken before any TcpWindowSize registry setting was made:

Packet trace of a GetStreamedData call showing the different Tcp window sizes requested by Vista and XP

Packet trace of a GetStreamedData call showing the window size adjusting upward as the call proceeds

Packet trace of a PutStreamedData call showing the default 64KB window size being used when moving data from Vista to XP

The alert reader may notice that the Tcp session didn't end between the two web service calls. That's because for this test I changed the client code to call both web service calls on the same connection, without closing the connection between calls.

In my testing the Tcp window requested by Vista always had a scale mode of 2. This MSDN blog post says that Vista determines the scale mode based on the bandwidth delay product (bandwidth times latency). Since my tests were all conducted with the same bandwidth and latency, it's not surprising that Vista chose the same scale mode throughout.

The effect of the smaller Tcp window size used by default on XP can be seen by running a few queries in Wireshark. The total number of bytes transferred by the GetStreamedData and PutStreamedData calls are nearly identical, 5394699 v. 5394714. They are, after all, transmitting the same file across the network. But if you set the Wireshark filter to search for packets that arrived 0.2 seconds or more after the previous packet (frame.time_delta > 0.2), you see that only 3 such instances occurred during the GetStreamedData call (the one that used the larger Tcp window), while 20 occurred during the PutStreamedData call. Here's one of them:

Packet trace showing communication pausing due to a full buffer

These quarter-second pauses (equal to our round trip latency time) represent moments when the sender has completely filled its buffer and must wait for an ACK before continuing. And the discrepancy in frame time deltas is even more widespread than these 20 incidents: there are 48 deltas greater than 0.1 in the PutStreamedData communication to only 35 for GetStreamedData; 132 greater than 0.05 for PutStreamedData to 51 for GetStreamedData; 421 greater than 0.01 for PutStreamedData to 89 for GetStreamedData, and 679 greater than 0.001 for PutStreamedData to 430 for GetStreamedData. These pauses indicate delays in the communication caused by the sender's buffer momentarily filling up.

Summary of Findings on Stream Parameter Types

So to list some take-aways from the two graphs above:

Based on the PutStreamedData graph (Vista to XP data transfer)

• It would appear that WCF on XP has particularly poor performance when streamed transfer modes are used. The buffered transfer modes out-perform their streamed counterparts by 50%-75%
• For buffered BasicHttp, SSL doesn't add any appreciable overhead in the default case, but when the Tcp window size is optimally configured buffered BasicHttp is 50% faster than buffered BasicHttp with SSL
• Under the default configuration, buffered NetTcp performs best, but when optimally configured buffered BasicHttp and WS2007 perform about 40% better than buffered NetTcp.

Based on the GetStreamedData graph (XP to Vista data transfer)

• WCF on Vista appears to have particularly poor performance when SSL is used. The two bindings that use SSL perform worse than their non-SSL counterparts by 70%-75%. This is for me the most surprising finding of this entire exercise, because there was no indication that this would be the case in the large string-based payload tests that I conducted in my last post.
• Streamed NetTcp is the next worst-performing binding, about 50% worse than buffered NetTcp. No surprise there as that binding has consistently performed terribily in all the testing I've done.
• The other bindings perform roughly the same, about 50% better than the three worst-performing ones.

Mysteriously Poor Performance of SSL on Vista

As to why SSL-based bindings perform so poorly on Vista I'm at a loss to say, other than to note that I see similar-looking communications pauses in the SSL-based Wireshark traces. In one example, comparing a GetStreamedData call made by buffered BasicHttp and buffered BasicHttp with SSL:

• 6554 packets transfered in the non-SSL case, 6704 for SSL
• Pauses greater than 0.01 seconds: 194 in the non-SSL case, 225 for SSL
• Pauses greater than 0.1 seconds: 17 in the non-SSL case, 157 for SSL
• Pauses greater than 0.2 seconds: 5 in the non-SSL case, 38 for SSL

This certainly bears further investigation in a following post, which I'll get to unles I get distracted by a bright, shiny object.

Findings for String Parameter Types

The performance chart for the large string-based payload test is as follows:

Seconds per web service call, large string-based payload, by Tcp window scale mode

With the exception of streamed NetTcp, there's a slight performance gain seen in all of the bindings, ranging from about 15% - 25%, when larger Tcp window sizes are used. Overall, the results are the same as the findings of my last post: streamed netTcp is the worst-performing binding, followed by the two streamed BasicHttp bindings, followed by buffered BasicHttp with SSL, followed by the rest, with buffered NetTcp the best performing of the bunch.

And the small string-based web service payload test gives similar results to the ones in my last post: streamed BasicHttp bindings perform worst due to the WCF bug that I talked about in my last post, buffered NetTcp performs best, and the rest are in the middle:

Seconds per web service call, small string-based payload, by Tcp window scale mode

In these tests the TcpWindow has no detectable effect on performance at all.

Conclusion

If any words of wisdom come out of these last two posts, it's that all bindings are not alike, and if you want your WCF application to perform well, you had better give careful attention to the bindings you use in your application.

WCF Bug on W2K3 and XP: TCP session closes after every web service call when using HTTP transport with Streamed transfer mode

While profiling a WCF-based application recently I uncovered a bug in WCF, in which the WCF service host forcibly closes its TCP session with the client after each and every web service call. The client is helpless to prevent it, even if it keeps the client proxy open in the hope of reusing the session for subsequent calls. No exception happens when the client does make subsequent calls; instead the proxy silently negotiates a new TCP session and continues on its merry way.

A Microsoft representative that I talked to about this confirms that this is an issue in WCF services hosted on Windows 2003 and XP, if they use HTTP transport with transportMode "Streamed" or "StreamedRequest." The bug doesn't affect transportMode "StreamedResponse," and has been fixed on Vista, Windows 2008 and Windows 7.

This bug is potentially a big deal because, as I noted in my last post, initiating a new TCP session requires a synchronous round-trip to the server, which, thanks to this bug, becomes overhead added to each and every web service call. And if SSL is in use then at least one more synchronous round trip will be added to every call. These round trips are detrimental to performance, especially in high-latency environments.

Seeing the Bug in a Packet Trace

The bug is very easy to see in a network packet trace. For these traces I'm using Wireshark, though most any packet sniffer will do. See my last post for instructions on how to use Wireshark.

The Test Web Service

The service I'm using for this test is simply this:

WCF service that demonstrates the bug

You'll notice that this web service method does not have a Stream, Message or IXmlSerializable return type or parameter, which according to this MSDN article is needed to make use of WCF streaming. This post therefore covers what happens to the performance of other (non-streaming) web service methods that are part of a web service that has been configured to support streaming. An evaluation of how the bug affects web service methods that do stream will be the topic of another post, unless, to paraphrase Shrek, I change my mind, or forget.

The Test Server

For the server I used a very unremarkable Console app as the WCF self-hosting service:

Console app used as the WCF service host

With the following basicHttpBinding endpoint:

WCF service host's App.config endpoint configuration

The Test Client

The client just calls the web service twice:

WCF client code used for testing

with Streaming enabled:

WCF client binding specified in its App.config

The Bug Exposed

The bug can be seen by comparing the network traffic produced by the calls shown above using an XP server, with the traffic produced by a Vista server:

Packet trace showing multiple web service calls using the same client proxy, using Vista as the server - Click on the image to view it more clearly

Packet trace showing multiple web service calls using the same client proxy, using XP as the server  - Click on the image to view it more clearly

These packet traces show that when XP is used as the WCF service host, the TCP connection is closed and re-opened between web service calls. This is verified by the fact that on XP each call is made using a different client port, while on Vista the same port is used for each call.

Evaluating the effect of the Bug

In order to evaluate the effect that this bug has on WCF performance, I ran a set of tests, the results of which I'll describe below. The first test was simply to run the simple WCF service shown above using different binding configurations in a loop against XP and Vista, and to note the performance of each binding.

The Test Bindings

The server bindings I used for this initial test are these:

Server bindings tested for performance

I tested custom bindings designed to simulate basicHttpBindings just to verify that the issue affects any http-based transport, and not just basicHttp, but I found that the timings for those bindings were identical to the timings for the basicHttpBindings. From here on out I'm dropping them from these results, to keep the clutter down.

The Test Client

For the client I used a simple console app that calls the web service using each of the client bindings in a loop for 10 seconds, and counts the number of web service calls it's able to make:

Client code used to test the performance of various WCF bindings

The Bug on Low Latency Networks

Here are the results:

Web service calls per second on low latency network, using a small web service payload

This test was conducted on my home network using two computers, an XP machine and a Vista machine. They're connected by an 8011.n wireless network that has about 1 ms round-trip latency.

The first thing that stands out about the results is the remarkable performance of buffered NetTcp, which was able to move twice as many calls per second as the other bindings. The next thing that stands out is the fact that while all the other bindings perform about the same on Vista, on XP the basicHttp-streamed binding is about 25% slower than the others, and basicHttps-streamed is about 50% slower than the others. So even in this low latency test, the overhead of setting up new TCP and SSL sessions for every call has a measurable impact on performance.

Finally, even though the graphs above represent two different machines, the fact that the number of calls each machine is able to process per second is approximately the same gives me some confidence that I'll be able to compare absolute call times between them in the analyses that follow.

The Bug on High Latency Networks

The bug has a measurable effect even in low-latency networks, but the performance numbers shown above are still pretty good. An end-user is not likely to notice the difference between an application that's making 50 web service calls per second v. one that's making 250 calls per second. What is of more interest is how the bug behaves in high-latency networks. 

To simulate different network latency times, I used the WANEmulator, a marvelous tool that literally takes minutes to set up, and which makes an excellent Christmas gift, especially since it's free. Running the same tests with 50ms, 100ms and 200ms round-trip times produced the following results:

Seconds per basicHttp web service call on Windows XP

Seconds per basicHttp web service call on Vista

The results are not surprising. With 200ms round-trip times, streaming added 200ms to the average web service call time, due to the need to make an extra round trip to establish the TCP session. And SSL adds another 200ms to the call for establishing the SSL session. Though it's not readily visible in the packet traces I've got right now, in other traces I have seen that WCF is able to establish SSL sessions in a single round-trip, so again the result above is not surprising.

It's good to see in the results above that on Vista the problem is really fixed, that all four bindings take the same amount of time, and that the amount of time time they take is the faster of the times taken on XP (e.g. 0.4 seconds per call at 200ms).

The bad news in the results above is that latency has a dramatic impact on even the best performance numbers above - from lightning-fast at 1ms latency to 0.4 seconds per call at 200 ms latency. The reason for this is not entirely obvious. Remember that at in the tests above, we are averaging the call time between many calls, and (except for streamed bindings on XP where the bug is restarting the TCP session every time) we are reusing the TCP and the SSL sessions between calls, so the time needed to establish those sessions should hardly be visible in these results. Since my test web service is a two-way call (it doesn't have the IsOneWay operation contract attribute), each call will result in at least one synchronous round trip, but the source of any additional overhead is not obvious.

The further bad news is that when the bug is present, web service calls are again 25% slower in the streaming case, and 50% slower in the streaming+ssl case, than they should be.

Another interesting result appears if I add back the other bindings to the chart:

Seconds per call of various bindings on XP, with various network latency figures

While WS2007 and streamed  NetTcp have nearly identical results as buffered basicHttp, buffered NetTcp again stands out as being twice as fast as all the rest. In fact, its call times are almost exactly equal the round-trip time itself, which is the theoretical minimum.

The Bug with Large Web Service Payloads

Again, I'm not going to analyze the bug when streaming-based parameters are in use, for the very good reason that I don't feel like it right now, but even an unstreamed web service method can include a larger payload than the "hi mom" text I used above. To see the effect of the bug on those types of methods, I changed the client to send a gob of text that's about 277KB in length. To prevent anyone from compressing it, I serialized something that's already been compressed, a JPEG of my daughter:

My daughter Kaitlin

Like so:

Client program that sends a picture of Kaitlin to the server in a loop, using different bindings, and times the result

Naturally I had to increase some of the max size parameters in the client and server bindings to allow for larger messages:

Server bindings that allow for larger message sizes

Client bindings that allow for larger message sizes

In the client bindings above I collapsed some of the duplicate settings to save space.

The Bug on a Low Latency Network with a Large Web Service Payload 

The results are as follows:

Web service calls per second on low latency network, using a large web service payload

The graph has the same general shape as it did with a small payload, though the absolute numbers are much different - 7 or 8 calls per second at best, compared to 250 calls per second with the small payload. With a payload this large network bandwidth is no doubt affecting these numbers, but since bandwidth is fixed throughout these tests, they should work fine for determining the relative effect of latency on WCF.

Again buffered NetTcp is the runaway performance winner, but this time streamed basicHttp performs about as well as the rest, and we have a new loser: streamed NetTcp.

So the bug is not measurable with large payloads in low latency environments. This makes good sense, because each web service call is taking so much more time just to transfer its payload that the TCP and SSL session initiation time is small by comparison.

The Bug on High Latency Networks with Large Web Service Payloads

Logically, in high-latency environments the TCP and SSL session initiation time should continue to be overwhelmed by the sheer amount of time taken to deliver the payload, but let's see what the testing shows:

Seconds per basicHttp web service call on Windows XP with a large web service payload

Seconds per basicHttp web service call on Vista, with a large web service payload

To our shock and horror, we see that the bug appears to affect performance in the same proportion as in the small payload case, only now instead of increasing call times from 0.4 seconds per call to 0.8 seconds per call, it's increasing call times from 2 seconds to 6. 

The good news (if anything about the above charts can be called "good") is that the bug remains more or less fixed on Vista, where call times are uniformly close to the best call times on XP, roughly 3 to 4 seconds per call. The Vista results appear to show that there is some additional overhead involved in streaming large payloads however, which amounts to about an additional 1 second per call in the 200ms latency case.

But even if we assume that, apart from the bug, there's 1 sec. worth of "normal" overhead involved in streaming large payloads in the 200ms latency case, that still leaves 1-2 seconds of overhead that we can only attribute to the bug. It would appear that closing and re-opening the TCP session carries some additional penalty beyond the round-trip TCP session establishment time. Something called "slow start" TCP session tuning may be the culprit (sure sounds like it, don't ya think?), but to date I haven't proven it, mainly due to laziness, since I have the packet traces in which must lie the smoking gun.

Performance of Other Bindings with Large Payloads

Though it has nothing to do with the stated purpose of this post, it's fun to add back the other binding types to the chart above:

Seconds per call of various bindings on Vista, with various network latency figures, using a large web service method payload

While WS2007 performs about as well as the best of the basicHttp methods, buffered NetTcp is again the speed king, coming in at a good 1/3 faster than the best of the rest. 

But what can we say about streamed NetTcp? It's taking 15 seconds per call in the 200 ms latency case, a good 4 times slower than all the rest! Only Dr. Seuss seems adequate: 

This mess is so big,

and so deep,

and so tall,

we cannot clean it up.

There is no way at all

Granted, I'm not making any attempt to tune these bindings; other than max message size settings I'm using defaults. But note that all these bindings are blindingly fast in low latency environments. If nothing else this shows the danger of failing to take latency into account when testing your WCF services.

And that would seem like a good stopping point for this particular post. This exercise produced many more fascinating results which the margin of this blog is too small to contain, but that will have to wait for another day. Unless I change my mind, or forget.

Appendix - the Data

The industrious among you can reproduce the above graphs and many others using the following data.

Vista Data - Small Payload

Call/sec	1ms	50ms	100ms	200ms
NetTcp Buffered	258	18.04	9.62	4.8
BasicHttp Buffered	125	9.26	4.74	2.48
WS2007	117	9.52	4.72	2.48
BasicHttps Buffered	111	9.34	4.67	2.48
NetTcp Streamed	111	8.58	4.44	2.46
BasicHttp Streamed	113	8.98	4.62	2.48
BasicHttps Streamed	103	8.98	4.72	2.36

Vista Data - Large Payload

Calls/sec	1ms	50ms	100ms	200ms
NetTcp Buffered	8	1.844444	0.9166667	0.5083333
WS2007	3.7	1.147222	0.5972222	0.3111111
BasicHttp Buffered	3.74	1.144444	0.605555	0.3194444
BasicHttps Buffered	3.78	1.088889	0.5555556	0.3083333
BasicHttp Streamed	3.5	0.775	0.4222222	0.2444444
BasicHttps Streamed	3.4	0.8277778	0.44722222	0.24166667
NetTcp Streamed	1.88	0.2361111	0.1222222	0.06944445

XP - Small payload

Calls/sec	1ms	50ms	100ms	200ms
NetTcp Buffered	250	18.13333	9.48	4.86
BasicHttp Buffered	131	9.766666	4.8	2.5
WS2007	120	9.5	4.88	2.46
BasicHttps Buffered	113	9.233334	4.86	2.46
NetTcp Streamed	110	8.933333	4.66	2.48
BasicHttp Streamed	83	5.6	3.18	1.68
BasicHttps Streamed	51	4.533333	2.38	1.28

XP - Large Payload

Calls / sec	1ms	50ms	100ms	200ms
NetTcp Buffered	7.16	2.072222	1.125	0.6222222
WS2007	3.38	1.352778	0.7555556	0.3833333
BasicHttp Buffered	3.9	1.361111	0.7416667	0.4027778
BasicHttps Buffered	3.42	1.005556	0.5388889	0.2916667
BasicHttp Streamed	3.18	0.6444445	0.3277778	0.1861111
BasicHttps Streamed	3.42	0.5972222	0.3166667	0.1666667
NetTcp Streamed	1.74	0.233333333	0.12777778	0.06666667

SSL Handshaking Overview

The goal of this post is to review what happens at the TCP/IP level when an SSL connection is initiated, paying particular attention to the parts of the handshake protocol that are synchronous, i.e., that result in the client or the server waiting for a response from the other before proceeding. Most of this post comes from the SSL 3.0 Specification listed on this web site and the TLS 1.0 Specification listed here.

Initiating a TCP Session

When a client such as a web browser first contacts a web site via SSL, the first thing that happens is a new TCP/IP session is initiated between the selected client port and the port handling SSL connections on the server, usually port 443:

This is a diagram of the standard 3-way handshake that initiates a TCP connection.

The TCP protocol provides reliable packet delivery by embedding a sequence number in every packet. Whenever an endpoint receives a TCP packet it responds with an acknowledgment (abbreviated as an “ACK”) indicating the highest sequence number it has successfully received. If the sender doesn’t receive and ACK for a packet it’s sent within a certain time period, it assumes the packet was lost, and re-sends it.

When an HTTPS request is sent to a server, the first thing that happens is that a new TCP/IP connection is established with the port the server uses for SSL connections, usually port 443.

The client issues a synchronization request (abbreviated as “SYN”), in which it indicates the client port number for the conversation, and with the initial sequence number for packets originating from the client.

The server responds by ACKing the client’s request, and with a SYN of its own, which contains its initial sequence number for packets originating from the server.

In the diagram, packets originating from the client are shown in blue, and packets originating from the server are in green. Dark-colored lines indicate synchronous conversations. E.g., the client sends its initial SYN and waits for the server to respond. The server responds, and the synchronous part of the conversation is completed. The client ACKs the server’s response, and then continues immediately with the next conversation, which is the client/server hello:

The Client and Server Hellos

In this diagram the client begins by sending the SSL Client Hello message, which contains, among other things, the highest version of SSL supported by the client, the list of encryption algorithms supported by the client, and a random number that will be used as a seed value for generating the SSL master secret encryption key.

This is a good time to note that SSL is based on both PKI encryption (public-key infrastructure) and on symmetric encryption. PKI encryption is based on a pair of keys, a public key and a private key. The properties of PKI encryption that make it so useful are these:

• Anything encrypted with the public key can only be decrypted with the private key.
• Anything encrypted with the private key can only be decrypted with the public key.

The server can therefore broadcast its public key to the world, and the client can use it to encrypt its messages without fear that anyone other than the holder of the private key can decrypt it. But PKI encryption is slow, so SSL uses it only to encrypt a seed value that is used to generate a symmetric key, which is used by the client and server to encrypt the rest of the conversation. Symmetric key encryption algorithms use a single key for both encryption and decryption. These algorithms are faster than PKI, but presuppose that the participants in the conversation have a secure way to exchange the encryption key.

In SSL, the conversation’s symmetric key is called the “master secret.” The key itself is not sent over the wire. Instead, three seed values are sent across the wire that the client and server can use to generate the actual symmetric key. The seed values include a random number generated on the client and sent to the server in the clear (unencrypted), a random number generated on the server and sent to the client in the clear, and another random number generated on the client and sent to the server encrypted via PKI.

Once the client sends the Client Hello it must wait for the server to respond with a set of messages that begin with a Server Hello message and end with a Server Hello Done. The messages sent by the server in between the Server Hello and the Server Hello Done depend on whether the server authenticates itself using digital certificates, and whether it requires clients to authenticate themselves with digitial certificates.

The diagram shows the most common case, in which the server authenticates itself to the client with a digital certificate, but does not require the client to authenticate itself.

In that scenario, the server selects the strongest encryption algorithm supported by both client and server, and returns its selection in the Server Hello, along with a random number generated on the server for use in creating the symmetric encryption key. It sends its digital certificate in a Server Certificate message, and then sends a Server Hello Done message.

As with the previous diagram, the synchronous part of the conversation uses dark colors. The ACKs are in lighter colors and are not synchronous. Which is to say, the client sends the Client Hello, and then waits for the stream of messages ending with the Server Hello Done. Neither side waits for the ACKs.

The client is now ready to send the information the server will need to generate the symmetric encryption key, and to instruct the server to switch to the chosen symmetric encryption algorithm:

The Client and Server Key Exchange, Change Cipher Specs and Finished Messages

In this diagram the client generates the information necessary for the client and server to generate the “master secret,” which is the symmetric encryption key. The exact information sent differs based on the encryption algorithm used. The client sends this in an SSL Client Key Exchange message.

The client then sends a Change Cipher Specs message, which is just a flag message that contains no data payload, and then a Finished message, which is the first message encrypted using the symmetric key. The content of the message is the entire handshake conversation up to the Change Cipher Specs message, which the recipient will decode to verify that encryption is working properly.

The server must wait to receive the client key information before proceeding with its part of the conversation, but the client doesn’t have to wait for the server to do so before it starts to send encrypted content under the session, so the synchronous part of the SSL setup has effectively concluded.

The server does reciprocate with its own Change Cipher Specs and Finished message however, which again contains an encrypted copy of the entire handshaking exchange between itself and the client. The client is also required to decrypt the Finished message payload and verify that encryption is working properly.

At this point the SSL connection, and the client and server may exchange encrypted content.

Viewing the Packets in Wireshark

All this becomes more concrete when the packets are viewed in a packet sniffer such as Wireshark. Wireshark is very easy to use. Just download, install and run the application, and select Capture\Interfaces... in order to instruct Wireshark to start capturing packets on one of your network devices. If several devices are listed and you're not certain which to capture, just leave the dialog open for moment while you browse the Internet. The number in the "Packets" column in the dialog will increase on the network device being used by the browser.

Next, find a web site that uses HTTPS, and load a web page from that site in your browser. You'll want to filter out all the network traffic except packets that are going to or coming from that site. You should be able to figure out the IP address of the site you're connecting to by viewing the packet stream in Wireshark as you refresh the browser. In my case I'm using a site with IP address 72.21.210.250. Once you've figured that out, add a filter to Wireshark Filter text box of this form: ip.dst == 72.21.210.250 or ip.src == 72.21.210.250.

To get a clear picture of an entire SSL session, its best to wait a few minutes until the server you've connected to terminates your TCP connection. You'll see that happen in Wireshark when the server sends a TCP "FIN" message to your machine, which Wireshark highlights in dark gray by default. Then select Capture\Restart in Wireshark, and refresh the HTTPS page in your browser. You'll see something like this:

Initiating the TCP Session

The first message packet is the client's TCP SYN, requesting a new session containing the client port, 51805, and the starting packet sequence number, zero. The server ACKs the client's SYN and responds with a SYN of its own in the next message:

Wireshark helpfully colors the two SYN packets in dark gray to highlight the fact that they represent the beginning of a new TCP session, and includes a "SEQ/ACK" analysis feature in its Packet Details pane that shows that the ACK in this packet is acknowledging receipt of the packet sent in frame 5 above.

At this point we have a valid TCP session. The client ACKs the receipt of the server SYN, and then immediately proceeds to the Client Hello:

Client and Server Hellos

Wireshark notes that this is a TLS 1.0 (Transport Layer Security) message by identifying the protocol as TLSv1. TLS 1.0 is basically a newer variant of SSL 3.0. The aspects of the handshaking protocols that I'm reviewing in this blog post used by the two protocols are the same, with one exception that I will note below.

The server responds with two packets. The first is this:

Wireshark flags this as a "TCP segment of a reassembled PDU" (Protocol Data Unit). This is just a way of saying that a single higher-level protocol's "data unit" (a TLSv1 record in this case) has been broken up into two TCP packets for transmission.

Expanding the Transmission Control Protocol node in the Packet Details pane, we can also see that this packet contains an ACK for the packet the client last sent.

Moving on to frame 10 we can see that the server has packaged three SSL messages into a single data unit: a Server Hello, the Certificate, and the Server Hello Done:

In the Packet Details pane, Wireshark helpfully tells us that this single TLSv1 data unit has been reassembled from two TCP packets, which are shown in frames 9 and 10. Looking at the Secure Socket Layer info in the packet, we see the three messages. If we then expand the Server Hello details, we can see that the server selected the RSA PKI algorithm and the RC4 symmetric encryption algorithm using a 128-bit key, and the MD5 algorithm for hashing:

Client and Server Key Exchanges

In frame 11 the client ACKs the server hello messages, and in frame 12 it immediately proceeds to the Client Key Exchange, Change Cipher Specs, and Finished message (which Wireshark calls an "Encrypted Handshake Method"), all of which are contained in a single TCP packet:

Frame 13 is a server ACK, and in frame 14 we get the server's Change Cipher Specs and Finished messages:

And in Frame 15 we see the start of the actual SSL-encrypted content of the web page.

Another Synchronous Handshake in TLS 1.0

One interesting thing to note about these Wireshark results is that, even though the client is supposed to be able to begin sending data as soon as it completes its client Finished message, in the results above it appears to wait until the server completes its server Finished message.

This appears to be the only difference that we have encountered in this post between the SSL 3.0 spec and the TLS 1.0 spec. The SSL 3.0 spec contains the phrase "No acknowledgment of the finished message is required" in its description of the client Finished message. That phrase has been removed from the TLS 1.0 spec, which is otherwise in many places a word-for-word copy of the SSL 3.0 spec. Also the flow diagram used by TLS 1.0 has been changed to make the client and server key exchange conversations synchronous.

Therefore it would appear that for TLS 1.0 the key exchange diagram should look like this:

to reflect the fact that the key exchange messages have been made synchronous in the newer protocol.

Tom's Patterns Cheat Sheet , Part 6 - The Decorator Pattern

This post is based mainly off of the GoF Patterns Bible, Design Patterns: Elements of Reusable Object-Oriented Software. The basic Decorator Pattern is this:

Basic Decorator Pattern
(Click on the diagram to open in a separate window)

The name of the pattern is very descriptive. It involves a main class that does most of the work, represented by the ConcreteComponent class above, and one or more Decorator classes that inherits from the same base class as ConcreteComponent (the abstract Component class in the diagram above), and also holds onto a reference to a Component class.

The Decorator classes delegate most of the real work to their Component class instance, but "decorate" its functionality by tacking on their own behavior.

Note that in the diagram above the abstract DecoratorComponent doesn't add a lot of value - it defines a way to pass the reference to the Component class to the decorators, and nothing else. When there's only a single Decorator you can simplify the diagram like so:

Simplified Decorator Pattern

In fact even when there are multiple Decorator classes the base Decorator class is often omitted, as is the case in the CryptoStream example from the .NET Framework, which is shown below.

The GoF book says that another name for this pattern is the Wrapper Pattern, but in my opionion "wrapper" is a loose term that applies to a number of patterns in which one object delegates most of its behavior to another, "contained" object. In particular, I'd say "wrapper" applies to the Decorator, Fascade and Adapter patterns, but not to the Proxy pattern because in that case the object you are delegating to is not conceived of as being "contained in" the proxy.

It's not terribly easy to find real-life examples of the Decorator Pattern. One of the examples given by the GoF is also the example given in this MSDN article that describes the Decorator Pattern, which is the Stream family of classes:

Decorator Pattern Example: A CryptoStream

In this example the CryptoStream class inherits from the abstract Stream class and is also given a Stream object reference, overrides the Write method, encrypts the bytes and then calls the Write method on the contained stream to write the encrypted bytes. In fact, if you use Reflector on the .NET Framework CryptoStream class you can see that it has actually been implemented using this pattern. The CryptoStream constructor takes a Stream reference:

public CryptoStream(Stream stream, ICryptoTransform transform, CryptoStreamMode mode)
{
  this._stream = stream;
...
}

And the Write method encrypts the buffer before writing it to the stream:

public override void Write(byte[] buffer, int offset, int count)
{
  // Bunch of encryption goo...
  this._stream.Write(this._OutputBuffer, 0, num3);
}

The Decorator Pattern can provide a very elegant means of composing the behaviors of objects at run time. In the example above, because CryptoStream is passed an abstract Stream object base class reference, it can operate on any type of stream: a FileStream, MemoryStream or any type of stream that you may create in the future. And because CryptoStream itself derives from Stream, it can be passed to other decorators. So if in the future a CompressionStream class were created, you could compose a FileStream that is encrypted and compressed, or a MemoryStream that is compressed by not encrypted. All this can be done dynamically, at runtime, rather than at compile time, as would be the case if you were to attempt this via inheritance.

Pros and Cons of the Decorator Pattern, according to the GoF:

Pros:

• Allows for more flexible composition of behaviors than static inheritance.
• Allows you to break object behaviors into small components (as opposed, for example, to creating a CryptoCompressionStream class that inherits from CryptoStream)

Cons:

• Can lead to an explosion of small component classes are are difficult to understand.
• Can't rely on object identity remaining unchanged because a client's initial Concrete object may be wrapped in a Decorator at any time.

And I think I should add that creating a Component base class definition that is amenable to this kind of infinitely forward-compatible extensibility is more difficult than it looks, because the Decorator classes have no ability to change the internal behavior of the Component, as they would with inheritance. This is probably why the Decorator Pattern isn't used more often in practice.

A First Look at Model-View-ViewModel

Model-View-ViewModel (MVVM) is a pattern used extensively by WPF developers. It was first introduced in October 2005 on WPF-and-Silverlight architect John Grossman's blog, where it was billed as a variation of MVC. According to Grossman, Expression Blend was written entirely using the MVVM pattern, and it is now, as far as I can tell, far and away the most common pattern used by WPF programmers.

I'm new to WPF and to MVVM, so I'm not going to claim to be able to make any definitive pronouncements about it. Most of what I've learned about it has come from reading this MSDN article, which was written by Infragistics engineer Josh Smith, and which Grossman himself recommends, as well as from reading various blog posts and newsgroup threads. But I will attempt to give some initial impressions, which I will hopefully refine and correct over time.


What is MVVM?

First of all, even though Grossman and others refer to it as a variant of MVC, it appears to me that MVVM is exactly Presentation Model, which is why my last post was a recap of Presentation Model. So far as I can tell, there is no structural or conceptual difference between MVVM and Presentation Model that could be used to classify it as a separate pattern. It is simply the application of the simpler form of Presentation Model to WPF applications. Smith agrees with this, saying "I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms."


MVVM as an Adaptation of Presentation Model

You may recall that the simpler form of Presentation Model that I discussed in my last post was this one:

Presentation Model pattern in which the View references the Presentation Model

This is the simpler form because the view references the presentation model, and not vice versa, so the presentation model can be written without any entanglement with the view whatsoever. Also I mentioned in my last post that where data binding is present this pattern is especially simple, which is the case in MVVM. So here is the pattern as applied to WPF applications (from here on out I'll switch to the MVVM terminology and call the presentation model a "view model"):

MVVM Pattern

WPF Elements in MVVM

The diagram above is clear, but not very interesting. Here is a diagram that shows where the WPF pieces fall into the MVVM pattern (click on the image to see a larger version):

WPF Elements in the MVVM Pattern

I'll be the first to admit that I may be focusing myopically on the sample program that Smith provides with his article. I'll update this as I learn more, but meanwhile, based on that example and on a smattering of reading, this is what I see:

View: Consists of all of the XAML in the application, including the XAML for the main Application, for the Windows and for any UserControls, plus any Styles and DataTemplates. WPF data binding is used to bind controls to view model classes, and DataTemplates map view models to WPF controls for presentation.

Once the developer puts the basic view in place, they would ship it off to a UI designer in accordance with Microsoft's strategy of separating those two roles, so the view model needs to be well separated from the view.

View Model: Application, Window and UserControl XAML code-behind falls into the View Model layer, but it is strongly recommended that code-behind code be minimized, and that View Model code be placed in separate classes to the extent possible. Those classes are the view model classes shown above.

View model classes are data-bound to the view, so they need to implement INotifyPropertyChanged in order to notify the view when it needs to be updated.

They may optionally expose Command properties, which are classes that implement the ICommand interface. WPF provides built-in support for a command pattern that allows you to easily associate a single handler with a menu item, toolbar button, context menu, short cut key, etc. E.g. you can associate a single "Copy" command handler with the "Copy" menu item, toolbar button, context menu and "Ctrl-C" shortcut key. Commands therefore provide a way to encapsulate some of the behavior of the WPF application in the view model classes.

Granularity of view models appears to be roughly one per Application, Window and UserControl, but that isn't set in stone.

Domain Model: Happily, our domain model never changes as we move from pattern to pattern. That's one of the best things about these patterns. Our efforts to create controllers that can be reused from one UI technology to another only rarely prove fruitful (what are we supposed to do with all those Windows Forms MVP presenters now that we're told we should use data binding in WPF applications?) But the domain models just keep chugging right along, oblivious to the world's UI churn. They are the only (mostly) completely reusable parts of the system we have.

Anyway that's it for my first look at MVVM. I will (hopefully) try to update this as I continue to learn about WPF.

Tom’s Patterns Cheat Sheet, Part 5 – Presentation Model

Overview

Presentation Model (also called Application Model) is a pattern that is similar to the MVC family of patterns in that it consists of a domain model, a view and a "something else" that acts as a mediator between the model and the view.

That "something else" is the presentation model. A presentation model differs from the controller in MVC and the presenter in MVP primarily in the way it is conceived. A presentation model is conceptually an object model that represents the view. E.g. if your view contains two textboxes and a checkbox, you would expect to see two string properties and a boolean property in the presentation model:

Simple Presentation Model Example

In this example, the logic associated with enabling or disabling the "Offline enabled" checkbox is handled by the presentation model, as is the code that interacts with the domain model, which is in this case the authentication service.

Controllers and presenters, in contrast, are conceptually handler classes that act as conduits between the domain model and the view. A presentation model is stateful, because it is considered the "system of record" for view state, while presenters and controllers are likely to be stateless. In fact Fowler comments that "the basic MVC notion assumes that all the state of the view can be derived from the state of the model," so in classic MVC there is no view state.

Controllers, using Martin Fowler's description of MVC, tends to be very granular - one ore more controllers for every widget. Presenters tend to be more large-grained - typically one per form. Presentation models tend to be larger-grained as well, similar to presenters, although composition of presentation models is also common, particularly in the Model-View-ViewModel (MVVM) variant used by WPF developers.


Components of Presentation Model

The presentation model: An abstraction for a view's state and behaviors. Like the presenter in MVP, the presentation model is intended to be free of UI dependencies, and for the same reason: One of the primary motivations for Presentation Model is to improve the testability of the system by moving as much logic as possible out of the view, where it is difficult to test.

The view: As in MVP, the view in the Presentation Model pattern is intended to be as free of logic as possible, again to improve testability.

The domain model: The domain model is conceptually the same in Presentation Model as in MVP.


Variations of Presentation Model

Fowler identifies two variations of Presentation Model, one in which the view references the presentation model, and one in which the presentation model references the view:

Presentation Model pattern in which the View references the Presentation Model

Presentation Model pattern in which the Presentation Model references the View

Fowler provides a code sample of the first variant here. This variant is simpler than the second one, especially in cases where data binding can be used or where the Presentation Model->View observer can be dispensed with, because the presentation model has no dependencies on the view at all, or even on a view interface.

But if data binding is not available and if you want to test the code that synchronizes the presentation model's state with the view, then the presentation model will need a reference to the view, so the second option is required. Another important variation is MVVM, which is used extensively by the WPF community. I will attempt to comment on that pattern in the next post.


Pros and Cons of Presentation Model

As with MVP, one of the main motivations for using Presentation Model is to improve the testability of the system.

As with any Separated Presentation pattern, following the pattern may make it easier to support multiple views or to change UI technologies, although in practice this benefit is often overstated.

As with MVC and MVP, Presenter Model allows you to separate the UI technology from the UI logic, which makes the code easier to understand and to maintain. Compared to MVP, Presentation Model can lead to a cleaner, simpler presenter / presentation model object model, because by encapsulating view state as well as behavior the presentation model disentangles itself entirely from the view.

Presentation Model may lend itself better than MVP to situations in which you want to create an automation object model for your user interface that would be usable by SDK programmers, because the presentation model object model is closer to what a programmer would expect to see in an automation object model. Although some developers have exposed the MVP presenter for use in this way, they generally are not as user-friendly as presentation models.

On the downside, because it maintains its own view state, Presentation Model introduces the need to synchronize the view and the presentation model, although this can be mitigated by data binding. It makes use of the Observer pattern, which decreases readability and maintainability of the system. And it increases the number of moving parts in the system, which can decrease maintainability in small applications.