My Fiddler Session in Sela’s Dev Days

Today was my last session in the Dev-Days conference, and this time it was about Fiddler.

In this 1-day session we saw how Fiddler can be used to sniff communication, use it as a reverse proxy, manipulate the communication, and how to extend Fiddler with your own custom inspectors and request/response tampering code.

We also saw several extensions for fiddler such as the SyntaxView, the request code generator, and the FiddlerScript utility that enables you to edit the Fiddler’s script using intellisense.

You can download the presentation and the code samples (including two sample inspectors I wrote) from here.

Hope to see you again in our next conference.

ServicePointManager.DefaultConnectionLimit == 2? The Depends continues…

A few days ago I posted about the missing documentation about ServicePointManager.DefaultConnectLimit and that its default value is not always 2 (the value actually depends on the target server, if it’s a remote server or your localhost).

Yesterday, after my advanced WCF course, I got an email from one of the attendees that pointed out that indeed the default value is 2 for remote servers, but only in desktop applications (console, win forms…). In WCF services that are hosted in a web application, the default value for outgoing connections is actually 12 times the number of cores.

First of all, thanks Miron for noticing this behavior of web applications, and I’ll just want to add some more information about this setting in web environemnts:

1. The change in the default value comes from System.Web.HttpRuntime, meaning it will be for any web hosted application, such as ASP.NET, WCF, and ASMX Web Services.
2. The documentation in MSDN indeed mentions a changed setting with ASP.NET: “When used in the server environment (ASP.NET) DefaultConnectionLimit defaults to higher number of connections, which is 10”.
   As you can see, this documentation is also outdated…

Hope you can use this information for better configuring your desktop clients, web applications, and services (self-hosted, or IIS hosted).

My WCF Crash Course and Advanced Workshop in Sela’s Dev-Days

Yesterday we started Dev-Days at Sela – 5 days, 15 experts, 25 session, and a whole lot of people (around 600 people registered for this week).

Yesterday Erez Harari and I had our WCF Crash Course – going from 0 knowledge to a 100 in 9 hours. We talked about services, contracts, hosting, monitoring, RESt, security, reliability, and extensibility. There were about 40 people that attended the session, and I enjoyed it a lot. To those of you who attended the lectures, and to those who just want to take a peek at what we talked about, I’ve uploaded the presentation and the code samples:

http://bit.ly/wcfcrashcourse201106

Today I had my session about advanced WCF. The classroom was packed with about 50 people, and we had a lot to talk about:

• Monitoring – WMI, Performance counters, WCF end-to-end tracing, AppFabric, Message logging, and sniffers
• Performance – instancing, throttling, concurrency, thread pool, async services, timeouts, and all sorts of hidden settings
• Security – transport and message security, certificates, negotiation, impersonation, and delegation
• Client – REST clients, Silverlight clients, client proxy and ChannelFactory<T> best-practices
• Extensions – custom behaviors and extensible object

This presentation and its demos is also available for download:

http://bit.ly/advancedwcf201106

This week is not over for me yet, tomorrow I will give a short presentation about entity framework and distributed applications, on Wednesday I will join Yaniv in his lecture about parallel programming and high-performance computing (HPC), and on Thursday I will have a full day workshop about Fiddler and web debugging.

There are still some available seats for my fiddler presentation, so if you want to learn how to monitor traffic, manipulate traffic, and how to write your own custom inspectors, register to this last day of Sela’s Dev-Days.

WMI and WCF

One of the ways to monitor WCF is by using the Windows Management Instrumentation (WMI) provider. In short, WMI provides you with a way to view information about running services in your machine and in other machines in the network. You can view their process information, service information, endpoint configuration, and even change some of the service’s configuration in runtime, without needing to restart the service.

Little has been written about this feature. The basics of it is document of course on MSDN, which tells you what to set in your configuration to make the WMI provider work. The MSDN article also provides a link to download the WMI Administrative Tools which can be used to look at the information of running services by using WMI.

Aside from MSDN, there is a also quite a good blog post from Pablo Cibraro on how to use the WMI Object Browser (part of the WMI Administrative Tools) to view information about running services, and also on how to change some of the service’s settings through the WMI Object Browser. For example, you can use WMI to change the message logging level of a running WCF service, and instruct it to enable/disable logging messages at the transport level or at the service level.

This feature works, and it is actually very cool, except for one issue – the WMI Administrative Tools where written back in 2002, and work well with 32-bit operating systems, but don’t work too good with 64-bit systems. Unfortunately my machine is running a 64-bit Windows 7, and I can’t get the damn thing to work.

I tried some other WMI utilities, such as the WMI explorer, but none seemed to give the same capabilities of the WMI Administrative Tools. So I went on to look for a different way to control my WCF services through WMI.

At first I thought about writing a .NET application, but eventually I used PowerShell to write a short script (it took me about an hour to write it, mainly because this is only the third time I’m using PowerShell, so I had to learn a bit of syntax).

To run the script, you need to give it the name of your service (class name, without the namespace), the type of the logging level – transport/service, and whether to turn logging on or off, for example the following command will turn off the transport level message logging of service myService which is running currently in the machine:

.\SetMessageLogging.ps1 myService transport off

If you configured your service to use the WMI provider, the script will find it and change its configuration, whether it runs in a self-hosted application, or in IIS. Your service doesn’t need to be restarted and connected clients don’t even need to reconnect to the service.

To be able to use this script, you also need to prematurely add listeners to your <system.diagnostics> section in the service configuration, before starting the service.

You can download the script from my skydrive folder. Enjoy!

BTW, I will show this script next week in my advanced WCF workshop, which I will host in Sela’s DevDays. So if you want to learn more about the hidden gems of WCF, I suggest you hurry up and register, maybe you’ll be the last one who manages to squeeze into my class.

ServicePointManager.DefaultConnectionLimit == 2? Depends…

“Depends” is my favorite answer when teaching .NET-related courses, because behind this simple word lies the implementation of the CLR and BCL, which sometimes lead us to answers we didn’t expect.

For example, take the question in the topic: according to MSDN, the default value of System.Net.ServicePointManager.DefaultConnectionLimit is 2. So I wrote some code that tries to open a lot of connections from a console application to a WCF service, and to my amaze, I was able to send dozens of requests at a time, without hitting the two connection limit.

So I used my debugging skills, and found out that although the default value for the connection limit was 2, the ServicePoint.ConnectionLimit for my connection was set to 2147483647 – I didn’t expect that!

If you look at the MSDN page for ServicePoint.ConnectionLimit you can clearly see that it says: “The value of the ConnectionLimit property is set to the value of the ServicePointManager.DefaultConnectionLimit property when the ServicePoint object is created”. If the DefaultConnectionLimit has the default value of 2, that should have also set the ConnectionLimit value to 2, or am I wrong? I’m probably wrong thinking it’s that obvious.

Therefore, I went to reflector to see what I was doing wrong, and after searching around a bit, I found the following implementation in the ServicePoint.ConnectionLimit get property:

public int get_ConnectionLimit()
{
  if ((!this.m_UserChangedLimit && (this.m_IPAddressInfoList == null)) 
  && (this.m_HostLoopbackGuess == TriState.Unspecified))
  {
    lock (this)
    {
      if ((!this.m_UserChangedLimit && (this.m_IPAddressInfoList == 
         null)) && (this.m_HostLoopbackGuess == TriState.Unspecified))
      {
        IPAddress address = null;
        if (IPAddress.TryParse(this.m_Host, out address))
        {
          this.m_HostLoopbackGuess = 
            IsAddressListLoopback(new IPAddress[] { address }) 
            ? TriState.True : TriState.False;
        }
        else
        {
          this.m_HostLoopbackGuess = 
            NclUtilities.GuessWhetherHostIsLoopback(this.m_Host) ? 
            TriState.True : TriState.False;
        }
      }
    }
  }
  if (!this.m_UserChangedLimit && 
  !((this.m_IPAddressInfoList == null) ? 
  (this.m_HostLoopbackGuess != TriState.True) : 
  !this.m_IPAddressesAreLoopback))
  {
    return 0x7fffffff;
  }
  return this.m_ConnectionLimit;
}

If you look at the above code, you will notice something that pops at you right away – loopback.

Apparently the property checks if you are trying to access your own machine before deciding which limit to use. In my case I was connecting to my machine, and I ended up getting the value of 0x7fffffff which translates to 2147483647 – which is what I saw while debugging.

I went and made a quick change, found an available server, installed my testing service in it, changed the address, and voila – the ServicePoint.ConnectionLimit returned 2, and I could see that only two connections were executing at any given time.

Now let’s go back to the question I asked and ask it again:

Is ServicePointManager.DefaultConnectionLimit == 2? It depends:

1. If you are calling a remote service, then yes, it will be 2 by default

2. If you are calling to your local machine, then no, the default will be Int32.MaxValue

For best performance, the recommendation is to set the ServicePointManager.DefaultConnectionLimit to 12 times the number of cores in your client machine (for example, I have an 8 core machine, therefore 12*8=96 connections).

“Depends”, I love that answer.

By the way, next week we’re having our DevDays at Sela, and I’m going to give an advanced course in WCF. If you thought this anecdote was interesting, come and learn more about some hidden features and settings of WCF. I promise lots of fun and a lot of “it depends” answers.

My lectures at Visual Studio Live! 2011

In October I’m going to attend the Visual Studio Live! 2011 conference at Microsoft HQ in Redmond, this time not as a listener, but as a presenter.

I’m going to have two sessions in the conference, the first one will be about the new features of WCF 4, and the other one will be about the new “face” of ASP.NET, which is of course ASP.NET MVC.

I have a lot to tell you about these technologies, so were going to have lots of fun (and hopefully learn something new in the process).

But before that, I will have three full-day sessions about WCF 101, advanced WCF, and Fiddler 101, in the upcoming Sela’s DevDays that will be between 26-30 of June.

Hopefully you’ll be able to attend one or more of these conference, if not, I assume some of the sessions will be recorded so you can watch them later on.