RE: Futzing w/ HTTP response/request model
- From: "Peter Bromberg [C# MVP]" <pbromberg@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 21 Feb 2006 16:26:28 -0800
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
- Follow-Ups:
- Re: Futzing w/ HTTP response/request model
- From: Rein Petersen
- Re: Futzing w/ HTTP response/request model
- References:
- Futzing w/ HTTP response/request model
- From: Rein Petersen
- Futzing w/ HTTP response/request model
- Prev by Date: ComboBox bound to Datasource problem
- Next by Date: Re: serialization on static values
- Previous by thread: Futzing w/ HTTP response/request model
- Next by thread: Re: Futzing w/ HTTP response/request model
- Index(es):
Relevant Pages
|
