AppDomain in Short
ASP .NET and AppDomain
IIS application pool, worker process and AppDomain
IIS and ASP .NET
ASP .NET Internals
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.
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
You also quickly notice that is the reason why publishing message from the web server is a bad idea after dig deeper into NServiceBus.
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.
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 ?
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.
Of course we can !
You should visit this awesome blog post.
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
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
CONNECTis 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.
Just notice something when watching pluralsight videos..
i think you are agree that async await in c# 5 is a really cool feature. I will explain in the future blog post more detail about this. The problem now how if you want to use this feature in .NET 4.0. Let say that you can’t change the production environment to the latest .NET framework (4.5).
Firstly I have already installed Visual Studio 2012 in my machine. I try to change the target framework to .NET 4
At first I’m very happy because the async keyword is appear in my editor. But the red squiggly wipe all the happines.
You can see a cause of the problem at error window. Seems there are a missing type or assembly.
The answer to our problem is :
You can gain the simplicity and beauty of asynchronous to make your apps performance better.
Maybe you see there is no executable download in the previous link. That’s because you have to get the required library through Nuget.
Search “Microsoft.CompilerServices.AsyncTargetingPack” from nugget package manager. And install the package. That’s strange that the package is for Visual Studio 11. Well. Let’s try to give it a shoot.
After you install it the red squiggly disappear. You can dive into detail what’s contained in this package from object browser
There are a a lot of extensions method contain in AsyncCompatLibExtensions.
Then writes your codes.
Compile and run it asynchronously. If you see the IL with Diassembler you can see that our async await compiled into the same result as .NET 4.5. You should thanks the compiler baby.