Futzing w/ HTTP response/request model

[Rein Petersen]

Hi All,

I've recently been intrigued with this notion of "Service Streaming":

http://ajaxpatterns.org/HTTP_Streaming

in which you make use of the webserver and browsers ability to maintain
a connection using a loop on the web server. I know those of you
familiar with how IIS/asp.net (aspnet_isapi.dll) handles
HttpApplication threads (a pool) are probably very offended by this
idea but I would ask that you hear me out before flaming me :)

Performance issues aside (for a moment), I have had pretty good success
implementing a handler that keeps my connection open so that in the
browser, an AJAX-style XmlHttpRequest can remain connected and respond
to onreadystatechange events as the server pushes data.

In fact, it was rather easy : in my class implementing IHttpHandler and
within the ProcessRequest method, I merely included the following:

while(loop) { if (!context.Response.IsClientConnected) loop = false; }
context.Response.End();

where "loop" is a bool initialized as true;

The implication is that we can "futz" with HTTP response/request model
to allow a web server to act as an intermediary between clients limited
only by the number of simultaneous threads (connections) a given web
server can bear. It means chat or peer-style applications over port 80.

But I am realizing that asp.net's HttpApplication is a rather
largish-object possessing a ton of overhead one really wouldn't need
for the purpose of such applications. Basically you would be stuck with
a pretty small amount of connections that you could handle on a web
server.

I found another complication (it doesn't work and I understand there
are garbage collection issues) when I tried to implement static events
on my class that inherited HttpApplication so I could inform all
connected clients of an event (hence cause a push of data to some or
all).

I've created a few HttpModules in my time and I know that it is also
bound to HttpApplication (the HttpApplication object is pushed into
event handlers implemented in your class inheriting HttpModule) and I
realize that I can't any go further up the chain of processing (to
bypass it) without writing my own C++ Isapi filters - something I hoped
to avoid. I could write my own webserver but that is also not on my
radar.

Anyway, I was hoping for advice, comments, thoughts, suggestions on the
topic because I think it is worth investigating and could usher in a
new breed of HTTP applications now that we have AJAX support in an
increasing number of browsers.

Thanks, Rein

[Peter Bromberg [C# MVP]]

Rein,
Always a challenge to venture into uncharted territory, eh?

It's certainly an interesting concept, but as I am sure you already
understand, it completely goes against the whole concept of how HTTP protocol
works.

For now, I'm happy to use whatever Remote Scripting ("AJAX") implementation
to either poll or just do regular client script callbacks to refresh my DOM
on the client. There are enough problems doing that, and maintaining the
stateful context of the page, at least in ASP.NET.

I am sure there will be other comments.

My 2 cents.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Rein Petersen" wrote:

Hi All,

I've recently been intrigued with this notion of "Service Streaming":

http://ajaxpatterns.org/HTTP_Streaming

in which you make use of the webserver and browsers ability to maintain
a connection using a loop on the web server. I know those of you
familiar with how IIS/asp.net (aspnet_isapi.dll) handles
HttpApplication threads (a pool) are probably very offended by this
idea but I would ask that you hear me out before flaming me :)

Performance issues aside (for a moment), I have had pretty good success
implementing a handler that keeps my connection open so that in the
browser, an AJAX-style XmlHttpRequest can remain connected and respond
to onreadystatechange events as the server pushes data.

In fact, it was rather easy : in my class implementing IHttpHandler and
within the ProcessRequest method, I merely included the following:

while(loop) { if (!context.Response.IsClientConnected) loop = false; }
context.Response.End();

where "loop" is a bool initialized as true;

The implication is that we can "futz" with HTTP response/request model
to allow a web server to act as an intermediary between clients limited
only by the number of simultaneous threads (connections) a given web
server can bear. It means chat or peer-style applications over port 80.

But I am realizing that asp.net's HttpApplication is a rather
largish-object possessing a ton of overhead one really wouldn't need
for the purpose of such applications. Basically you would be stuck with
a pretty small amount of connections that you could handle on a web
server.

I found another complication (it doesn't work and I understand there
are garbage collection issues) when I tried to implement static events
on my class that inherited HttpApplication so I could inform all
connected clients of an event (hence cause a push of data to some or
all).

I've created a few HttpModules in my time and I know that it is also
bound to HttpApplication (the HttpApplication object is pushed into
event handlers implemented in your class inheriting HttpModule) and I
realize that I can't any go further up the chain of processing (to
bypass it) without writing my own C++ Isapi filters - something I hoped
to avoid. I could write my own webserver but that is also not on my
radar.

Anyway, I was hoping for advice, comments, thoughts, suggestions on the
topic because I think it is worth investigating and could usher in a
new breed of HTTP applications now that we have AJAX support in an
increasing number of browsers.

Thanks, Rein

[Rein Petersen]

Hey thanks Peter,

You're right, it is against the grain of what we have become accustomed
to with HTTP. But I find myself resisting that notion lately and
recently dug up the HTTP1.1 spec and found HTTP1.1 has allowed for
persistant connections to resolve the extra data requests (load) that
client pull presents. Check out 'Persistant Connections' section from
rfc2616:

http://www.w3.org/Protocols/rfc2616/...c8.html#sec8.1

The rfc even mentions "pipelining" requests and responses which is
exactly what I'm hoping to do to create responsive HTTP applications
that use bandwidth efficiently. Maybe this idea is not so crazy - it
seems they have opened the door to it.

But doing it with IIS is another story - I've dug and dug some more and
I can find no reasonable way of stepping in front of ASP.NET's
HttpApplicationFactory - an annoying thread pool of HttpApplication
objects that limits my ability to receive and hold onto many HTTP
connections. The only way is to drop IIS and create my own web server.

Cassini is an option - looks pretty efficient and all you have to do is
change line 132 in the source of Request.cs and replace:

HttpRuntime.ProcessRequest(this)
// 'this' is the Cassini.Request class that inherits from
SimpleWorkerRequest

with your own method call. Once you have wired up your own (static)
method to process a Cassini.Request object you have complete control. I
would still use a loop mechanism to keep the connection open but
instead use Thread.Sleep to wait for data sent from the client
(Cassini.Connection) or events raised from Cassini.Host ( this object
creates and listens on sockets for connections).

Cassini.Host uses WaitCallback to multithread the connections and as
far as I can tell, it should be able to handle some fair load because
it is very simple.

It's kind of like this server from Lightstreamer:
http://app.lightstreamer.com/StockListDemo/

It's a java server so I'm not really interested. But I think I could do
the same with .NET - it could be interesting...

Rein