Comments on: Creating Comet applications with ASP.NET http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/ Thu, 25 Feb 2010 20:23:05 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: mtranda http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-848 mtranda Fri, 18 Dec 2009 13:06:22 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-848 It's a pretty interesting read. I've always wondered how this could be achieved in IIS. The part that I was missing was to turn the response buffering off. I do have another question though: how can one detect when the connection has closed? Currently, the thread remains active even after the client leaves the page. I'm thinking I could probably call some IIS API to figure out whether the connection is still active or not, but maybe there's a better way. I've tried a Request.UserHostAdress on each iteration, but apparently it's only supplied to the server upon the page's first execution, and there's no way to actually detect whether the client is still there or not. Anyway, lovely read. It’s a pretty interesting read. I’ve always wondered how this could be achieved in IIS. The part that I was missing was to turn the response buffering off. I do have another question though: how can one detect when the connection has closed? Currently, the thread remains active even after the client leaves the page.

I’m thinking I could probably call some IIS API to figure out whether the connection is still active or not, but maybe there’s a better way. I’ve tried a Request.UserHostAdress on each iteration, but apparently it’s only supplied to the server upon the page’s first execution, and there’s no way to actually detect whether the client is still there or not.

Anyway, lovely read.

]]> By: HowToCode: Reverse AJAX / Http-Push / "Comet" – Kann der Server Clients aktiv infomieren? | Code-Inside Blog http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-800 HowToCode: Reverse AJAX / Http-Push / "Comet" – Kann der Server Clients aktiv infomieren? | Code-Inside Blog Wed, 21 Oct 2009 21:03:35 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-800 [...] Creating Comet applications with ASP.NET [...] [...] Creating Comet applications with ASP.NET [...]

]]> By: Karel Boek http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-754 Karel Boek Sat, 26 Sep 2009 11:06:32 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-754 Have a look at the sample I posted today http://kboek.blogspot.com/2009/09/using-ihttpasynchandler-and.html Have a look at the sample I posted today http://kboek.blogspot.com/2009/09/using-ihttpasynchandler-and.html

]]> By: StreamHub Comet Server http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-739 StreamHub Comet Server Wed, 02 Sep 2009 23:24:25 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-739 StreamHub have just added a Streaming Adapter for .Net so you can push data from a .NET client on the server and receive the updates in the browser. Worth checking out. StreamHub have just added a Streaming Adapter for .Net so you can push data from a .NET client on the server and receive the updates in the browser. Worth checking out.

]]> By: Jerod Venema http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-719 Jerod Venema Mon, 27 Jul 2009 21:14:26 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-719 We have a fully scalable (horizontal + vertical) comet server written in c# for IIS. Works like a champ. We've seen it support over 30k+ concurrent users, with throughput breaking 20k messages/sec. Check it out: www.frozenmountain.com/websync We have a fully scalable (horizontal + vertical) comet server written in c# for IIS. Works like a champ. We’ve seen it support over 30k+ concurrent users, with throughput breaking 20k messages/sec.

Check it out: http://www.frozenmountain.com/websync

]]> By: Morris Johns http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-670 Morris Johns Wed, 22 Apr 2009 05:42:36 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-670 The async approach is used by this control which looks like it has source code available: http://www.codeproject.com/KB/aspnet/CometGrid.aspx the article specifically says that threads are not blocked... The technique should be able to handle thousands of concurrent COMET connections. The async approach is used by this control which looks like it has source code available: http://www.codeproject.com/KB/aspnet/CometGrid.aspx

the article specifically says that threads are not blocked… The technique should be able to handle thousands of concurrent COMET connections.

]]> By: mike http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-650 mike Thu, 26 Mar 2009 16:01:15 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-650 spender, did you get any further with your suggested async approach? spender, did you get any further with your suggested async approach?

]]> By: spender http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-625 spender Wed, 04 Mar 2009 12:53:58 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-625 sure thing... just ironing out the deadlocks at the mo. :( sure thing… just ironing out the deadlocks at the mo. :(

]]> By: Aaron http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-623 Aaron Wed, 04 Mar 2009 03:32:27 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-623 Thanks spender. Of course the example above is naive - it's an example! Keep in mind I was attempting to illustrate the concepts behind COMET, not necessarily promoting best practices. If I had production experience implementing this (and not just doing it for fun) I would have a lot more to share. I look forward to you posting a comment here with a link to your blog post that will contain an exhaustive treatise of the correct way to do things, given that what you described (which is fairly accurate) basically means that true "push" COMET is not possible outside a "long poll" approach. :) Thanks spender. Of course the example above is naive – it’s an example! Keep in mind I was attempting to illustrate the concepts behind COMET, not necessarily promoting best practices. If I had production experience implementing this (and not just doing it for fun) I would have a lot more to share. I look forward to you posting a comment here with a link to your blog post that will contain an exhaustive treatise of the correct way to do things, given that what you described (which is fairly accurate) basically means that true “push” COMET is not possible outside a “long poll” approach.
:)

]]> By: spender http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/comment-page-1/#comment-622 spender Wed, 04 Mar 2009 03:25:08 +0000 http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/#comment-622 The example above is somewhat naive. Any Comet server that uses techniques such as thread.sleep is doomed. With more than about 20 users, the .net threadpool will be saturated and spin up new threads. It does this slowly, because it is designed with the idea that the tasks it excutes are short-lived and don't block, and is attempting to find an optimal number of threads to service the queue. This will lead to high latency connection times. Using Flash in the manner described above is also not so good because the socket API for flash does not use browser settings for proxy information. There is a way to do this correctly in IIS. A couple of people mention it above. Deal with the request (quickly) then go async. Thread is returned to threadpool, threadpool remains responsive. When there's something to reply, end the async op, quickly borrow a thread from the pool and send the response. Most of the time nothing happens. Blocking many threads to do nothing is inefficient, and ultimately the server will spend more time swapping thread contexts than serving data. The neverending download style is also perilous because several proxy server implementations will not send to the client until the response is complete, and IE's XMLHTTP also doesn't give you a look in until the response is complete So, all in all, the techiques above should be considered harmful. ;-) The example above is somewhat naive. Any Comet server that uses techniques such as thread.sleep is doomed. With more than about 20 users, the .net threadpool will be saturated and spin up new threads. It does this slowly, because it is designed with the idea that the tasks it excutes are short-lived and don’t block, and is attempting to find an optimal number of threads to service the queue. This will lead to high latency connection times.

Using Flash in the manner described above is also not so good because the socket API for flash does not use browser settings for proxy information.

There is a way to do this correctly in IIS. A couple of people mention it above. Deal with the request (quickly) then go async. Thread is returned to threadpool, threadpool remains responsive. When there’s something to reply, end the async op, quickly borrow a thread from the pool and send the response. Most of the time nothing happens. Blocking many threads to do nothing is inefficient, and ultimately the server will spend more time swapping thread contexts than serving data.

The neverending download style is also perilous because several proxy server implementations will not send to the client until the response is complete, and IE’s XMLHTTP also doesn’t give you a look in until the response is complete

So, all in all, the techiques above should be considered harmful. ;-)

]]>