we’re have a client that needs to get interactive messages from a server, from clients that are distributed around the world behind all kinds of firewalls with all kinds of ports closed. The only thing we can rely on is HTTP port 80 (and HTTPS 443).
The design is basically modeled after XMPP (the Jabber protocol), using our client and IIS. The client issues GET requests to a .NET Handler; the handler holds the request open for a while looking for messages. If any messages arrive, they are immediately sent to the client; if not, after a timeout the connection is closed with a ‘no-data’ response. The client immediately reopens the communication.
Well, theoretically.
What’s actually happening is first, IIS can’t handle more than about 100 simultaneous requests – others are all queued, and there can be a several minute lag between ‘connected’ and IIS recognizing that the client called in. Second, about half the time the client times out without any response from the server (the client timeout is five minutes longer than the server’s).
POST always works. Other data served on the same web server works. Web services on the same server work. This is an out-of-the-box installation on Windows 2K3 Server.
Is there a configuration option we’re missing, or is there something else I should look at to address this?
Thanks.
I think you’re hitting ASP.NET thread pool limits, rather than IIS ones. Look into creating a asynchronous HTTP handler (
IHttpAsyncHandler) as when they block/wait they aren’t tying up the thread pool (they use completion ports instead).Update: Came across this recently that seems to concur with my thinking: CodeProject: Scalable COMET Combined with ASP.NET