IIS and ASP .NET Internals Articles

AppDomain in Short

http://www.c-sharpcorner.com/UploadFile/nagryum/Appdomain07102007081415AM/Appdomain.aspx

ASP .NET and AppDomain

http://odetocode.com/articles/305.aspx

http://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-_2D00_-AppDomain-recycles_2C00_-more-common-than-before.aspx

IIS application pool, worker process and AppDomain

http://stackoverflow.com/questions/2659571/how-does-application-pool-work-in-iis

http://stackoverflow.com/questions/452845/are-appdomains-are-created-for-every-request

http://www.iis.net/learn/manage/scripting/managing-worker-processes-and-appdomains-in-iis-with-wmi

IIS and ASP .NET

http://www.dotnetfunda.com/articles/article821-beginners-guide-how-iis-process-aspnet-request.aspx

http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization

IIS Architecture

http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture

ASP .NET Internals

http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp

Advertisement

Should we trust IIS for WebSocket ?

IIS 8 has already support WebSocket as I mention previously in my blog post. But I take a look at my notes again and see that there is a problem with IIS for maintaining long running service. I’m not familiar with IIS internal structure and still learning about that lately.

The problem is in IIS Recycle.

Here’s a couple discussion from NServicebus mailing list about that.

 

 

Here’s from another blog.

http://weblogs.asp.net/dwahlin/archive/2008/06/16/pushing-data-to-a-silverlight-client-with-wcf-duplex-service-part-i.aspx

Take a look at the first commenter

Monday, June 16, 2008 11:23 PM by Rob Eisenberg

Just for the record…this type of HTTP push technique is often referred to as Comet.  The real question is, how scalable is the server going to be?  From everything I’ve been able to determine, it’s pretty much impossible to build a scalable Comet server for IIS.  This is due to the way connections and threads are handled.  I’ve tried to get some information from Microsoft about this, but they don’t have answers yet.  Only time/experimentation will tell if the server is scalable enough to build a multi-player game or chat application.  I’m hopeful, because the amount of work it takes to create a truly scalable socket server is tremendous.

I track it down from Udi Dahan blog post

http://www.udidahan.com/2008/07/30/scaling-long-running-web-services/

You also quickly notice that is the reason why publishing message from the web server is a bad idea after dig deeper into NServiceBus.

http://www.udidahan.com/2010/02/01/nservicebus-2-0-release-candidate-2-available/

 

The mostly used websocket server in .NET is SuperWebSocket. I see a interesting discussion about should we host websocket server into IIS or standalone windows service.

http://superwebsocket.codeplex.com/discussions/338277

You’d better deploy it as a Windows Service. Because if you host it in IIS, you don’t know when the IIS will recycle the application pool.

 

So ? What do you think ?

 

Cheers

welcome async/await, goodbye BackgroundWorker

There are a lot of choice for us for doing asynchronous  work in UI. Which one is the best ? Can async/await replace BackgroundWorkder completely

async/await should replace your old BackgroundWorker. That’s it ! Why ?

MSDN explain about this.. Check this out

 

The async-based approach to asynchronous programming is preferable to existing approaches in almost every case. In particular, this approach is better than BackgroundWorker for IO-bound operations because the code is simpler and you don’t have to guard against race conditions. In combination with Task.Run, async programming is better than BackgroundWorker for CPU-bound operations because async programming separates the coordination details of running your code from the work that Task.Run transfers to the threadpool.

Ok. async/await is cool. But how to show the progress with async/await ? Can we do that. We need progress and cancel feature !

Of course we can !

You should visit this awesome blog post.

http://blogs.msdn.com/b/dotnet/archive/2012/06/06/async-in-4-5-enabling-progress-and-cancellation-in-async-apis.aspx

 

Cheers

Start Menu .. we miss you…

Installed windows 8 ? Great !

Have a headache because your beloved start menu missing ? You are not alone.

However you can get it back with the third party. Thanks to Windows native and Win32 geeks out there.

You should check this post

http://forums.mydigitallife.info/threads/38128-Windows-8-Start-Menu-alternatives-thread

 

Cheers

Websocket, Firewall and Proxy oh my…

You have already create a websocket apps for your realtime data ? That’s good.

Already tested and work on your localhost machine and LAN ? Great

How about deploy it into internet jungle ? What problem do you think will appear ?

The internet is very complex world. Take a look at this one.

 

You can dig deeper from this article. http://www.infoq.com/articles/Web-Sockets-Proxy-Servers. I quote some of the important thing you need to know.

Without any intermediary servers (proxy or reverse proxy servers, firewalls, load-balancing routers and so on) between the browser and the WebSocket server, a WebSocket connection can be established smoothly, as long as both the server and the client understand the Web Socket protocol. However, in real environments, lots of network traffic is routed through intermediary servers.

 

Today, most transparent proxy servers will not yet be familiar with the Web Socket protocol and these proxy servers will be unable to support the Web Socket protocol. In the future, however, proxy servers will likely become Web Sockets-aware and able to properly handle and forward WebSocket traffic.

there’s a some solution about that, but we doesn’t guarantee 100% success of websocket connection.

If an encrypted WebSocket Secure connection (wss://) is used, then in the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if an encrypted WebSocket connection is used.

 

If you have already visited and try this site. You will find this note that state the above problem too.

In some environments the WebSocket connection may fail due to intermediary firewalls, proxies, routers, etc. In that case take advantage of WebSocket’s secure capability and check Use secure WebSocket (TLS). Even if you have no issues you can still feel free to test using a secure connection.

 

So the conclusion is it’s better to create wss connection than plain ws, not only for security purposes but also to increase the success rate of websocket connection establishment.

 

Cheers