It is said that IIS is not recommended for Comet programming. If that is true, how is it that other web servers are able to handle this vis a vis IIS. So what is it that other web servers do additionally which allows them to scale out.
+1
A:
A Comet connection means a HTTP connection between the server and the client (the Web page itself) which is left open for a longer time period. The server needs to have the following capabilities set up correctly:
- Multiple parallel connections to the same browser (the maximum number of connections per client has to be set at least to 2)
- The connection timeout (inactivity) has to be set high enough and the Web page must be capable of re-initiating lost Comet connections.
- The server has to be able to run server side scripts for an extended time period, so the "processing timeout" has to be set high enough, e.g. 1800 seconds or so.
- It is useful to support HTTP 1.1, but not required for Comet.
The easies way is to use a JavaScript framework with built-in support for Comet. See the framework's manual for more instructions on how to configure various Web servers (like ISS) correctly for Comet.
fviktor
2009-12-14 04:13:39
+2
A:
For some reason, this myth is still around. It's certainly possibly to do this with IIS, as demonstrated in our IIS-based comet server, WebSync.
The myth started with standard ASPX pages (which, if you hold open, will crap out around maybe 100 or so requests tops). It got better with async pages and handlers (which idle using much lower memory and virtually no CPU), and, with some clever working, can scale as well as, if not better than, many other comet solutions.
jvenema
2009-12-14 23:33:50
Aside from the framework and functionality that makes it easier to program Comet with ASP.NET/IIS using WebSync, how is WebSync so much faster than straight Comet programming against IIS with a custom http handler or *.ashx or web service? I just checked it out as we use Comet a lot but I didn't see any technical details on the site of how WebSync achieves the performance you claim (I'm not disputing, just looking for more informatino).
Sam
2010-06-10 06:38:04
@Sam: for the performance, we've got custom threading/threadpool management that's designed to scale in IIS without starving the threadpool, massive optimizations to the serialization/deserialization of the messages to minimize request processing and memory, a whole pickup/distribution methodology to handle distributed loads and server clusters, etc. Lots of things go into making it hit those numbers :)
jvenema
2010-06-10 16:28:54
@jvenema, when a request comes into IIS on a worker thread, how do you take over that request on a separate thread and later send back a response but still return the original worker thread back to ASP.NET? That's the part that has me curious.
Sam
2010-06-10 16:56:49
@Sam: the async handlers from .NET automatically drop back into the wait pool once you've handled the beginprocessrequest, but the request is completely idle until you complete it, so as long as you properly track your resources, you just let the request sit around, using virtually no resources, until you need it again. See http://msdn.microsoft.com/en-us/magazine/cc164128.aspx#S4
jvenema
2010-06-10 19:21:20
@jvenema, thanks for the link, that's exactly what I was asking about.
Sam
2010-06-10 20:19:16
A:
We have moved away from using IIS to using a custom web server built using HttpListener. IIS imposes resource limits and screws up debugging any other ASP.NET web application you have. Running it on a different App Domain minimizes but does not resolve the problem.
mythz
2010-02-16 13:23:16
+1
A:
I'd also suggest checking out aspcomet.googlecode.com - open source and runs in IIS.
Neil Mosafi
2010-04-23 11:07:54