So, the other day I ran into a scalability problem within the .NET Framework which I've started calling the "Noah's Ark Effect" (i.e. 2x2 critters). The problem System.Net.HttpWebRequest is hobbled by the fact that it makes calls into WinInet. You see the HTTP 1.1 spec (RFC 2616) 'mandates' that clients never create more than two simultaneous connections to a given HTTP 1.1. Endpoint/Server. I think that's a GREAT rule for browsers -- and I applaud MS for sticking to standards. Unfortunately with MS, the browser and the OS are linked at the hip; so much so that System.Net.HttpWebRequest on, oh, say... Windows 2003 Server runs into these limitations. Because the Framework ties into WinInet to do the actual implementation, your requests to a given, single, endpoint will queue in the TCP/IP stack and go out 2x2. It's pathetic, you can just watch them queue up like critters waiting to board the Ark.
Oh, sure there's a KB article that pretends to have a solution, but the hack it recommends simply doesn't work. Even if the hack DID WORK, it's still a nasty workaround as it would have to be implemented for the USER in question (imagine gettting your app up and working, then 2 years later a security audit finds that a better user would be suited to handling the app in question.. the daemon's underlying account is changed, and the App starts exhibiting "Noah's Ark" behavior...)
How did I get around this problem Well, luckily an associate from the world of AspAdvice.com suggested a 3rd party solution: /n Software's IP*Works. I'd heard of the product before, and seen ads here and there on various sites. What's so special about /n software's IP*Works! anyway Well, their .NET solution is a 100% .NET library, but it isn't implemented on top of WinInet -- so their Http Component would be like writing your own, non-crippled HttpWebRequest class -- only /n software has had oodles of experience writing these types of libraries. (Put another way, their Http Component allowed me to do my XML post/response screen-scrape without the Noah's Ark Effect.)
After a little bit of contact with Eric in their marketing department, who made me a great deal on a license (more about this below), I was able to effortlessly download and install IP*Works! and IP*Works! SSL (both for .NET). The installer was awesome and coddled me through the deployment process... it even wired up extra goodness for me in VS.NET.
Once I was done installing, I went to the first place I always look to judge a 3rd party component: the docs. Suffice it to say, these guys have some of the best docs on their product in the market. A nice .chm covering all of the components, with a breakdown for all properties/methods/ AND configuration settings made it easy to navigate to which options are available for each component. Moreover, the descriptions don't appear to succomb to some of the tech-writing horrors of describing a technical term with the term itself, ala "Dog: a dog is a dog-shaped animal that eats dog-food and makes dog sounds." (I can't tell you how much I hate crap like that.) Instead, everything was nice and succinct. That, and there were oodles of examples. Complete Examples at that.
The object model, which I'm very critical of in 3rd party components is quite logical and very sound. Everything was concise: no messy side-effects or coupling nightmares.
Licensing was a concern for me going forward, since I knew that /n software wanted to protect their IP, but I knew that I'd be deploying my solutions built on their components elsewhere. Happily they've just put a lot of security around downloading and installing their components on developer boxes -- once it's there (you have to get a registry key update from their site (virtually painless, and the installer does it for you)), they just use Microsoft's .NET licensing scheme where as long as you have a licenses.licx file in your solution that enumerates in plain text which components are licensed everything just works out magically. In other words... there's a small hoop to jump through while you BUILD your solution (i.e. if you use an IP*Works! component, just make sure you have a licenses.licx text file in your solution with the namespace.objectname of the component and treat it as an embedded resource -- that's it). Once it's built, you can just deploy a single .exe or .dll -- no nasty .lic files or other evil in your output solutions.
In the end, I really have to say that I'm very impressed with /n software, and with IP*Works. They obviously feel very comfortable about the caliber of product they've created as they agreed to grant me a great deal on a license in exchange for a write-up of my experience -- all before I'd so much as downloaded and used their product (and I can be VERY critical of stuff that lets me down). I had one tiny snafu, due to my own stupidity, and made contact with /n software for a wee bit of help. They almost beat down my door with responsiveness, and I was able to quickly solve my own problem even BEFORE they got back to me (it took them all of 10 minutes to get back to me) by playing around on their existing KB.
Final result: Awesome product. Awesome Experience. And having the ability to pull a tried-and-tested component off the shelf for a time-sensitive, critical project: priceless.
