The <iframe> tag defines an inline frame that contains another document and is supported in all major browsers.
- Declare Iframe in the page.
- Hide the Iframe.
- Point the src of the Iframe to the web handler.
- Get Iframe to initiate request from the the browser client to the web server when the page loads.
- Get the web handler to flush response on task state changes.
- Perform DOM manipulation on the parent container.
This is a regular web handler and you may be wondering why am I sending 256 dummy bytes. This is a workaround to make IE work properly because IE accepts a message from the server after the first 256 bytes.
This technique is handy when we do not know about the message size and we can avoid any unexpected event by sending 256 dummy bytes before sending the – message.
The end user gets immediate feedback on task state changes and do not need to wait until the entire response download. When the task is complete it invokes the "hide" function to hide the loader image. This is what it looks like.
Asynchronous web handlers
I discussed a little bit about asynchronous web handlers in earlier post and I promised that I will talk about it later – so I do so. It is recommended to use asynchronous web handlers for long/ lengthy tasks. An asyncchronous web handler implements IHttpAsyncHanddler – this means it implements two additional methods BeginProcessRequest and EndProcessRequest. The idea here is to spawn custom threads by hand to run the lengthy portion of the task and not block important ASP.NET work threads from the threadpool. I have discussed about why we should spawn an additional thread in great length in this post, and I am not going to go through that again here, I am jumping straight in to the implentation of Asynchronous web handler.
Here this asynchronous web handler implements the IHttpAsyncHandler. The BeginProcessRequest performs all the lengthy bits inside request.BeginProcessRequest method asynchronously and signals when the task is completed. This executes the EndProcessRequest method. The AsycWebHandlerRequest class is a custom hand written class and I paste the code below.
Here I spawn custom Threads by hand to invoke the LongTask method. Long task has exact same code as we have seen in the regular web handler ProcessRequest method above, except the last line where it signals that the task is complete by invoking "requestState.CompleteRequest" method. Here the Response.Flush method does all the hard work to notify the connected browser about the task state changes and end user can enjoy immediate feedback from the server. You may be wondering about the AsyncRequestState class. I have used the exact same class during implementation of the Asynchrounous Page and can be found here.
I have indicated earlier that a web handlers is recommended for performance critical web pages. I have done some load tests to compare the result of regular web handler, asynchronous web handler and the asynchronous page that pretty much does the exact same operation. The test result of load tests that I have performed in exact same environment can be found below.
Fig: Load test of Iframe and asychronous web handler that uses custom thread
Fig: Load test of Iframe and regular web handler
Fig: Load test of asynchronous web page that implements custom thread
You can see that the asynchronous web handler that spawns custom thread is the clear winner. And when you compare Asynchronous page with web handler – we see web handler is superior.
For a “real-time” application ( i.e. chat application, airline timetable ) a polling / long polling mechanism is more suitable where the server keeps looping for infinite period – produces the latest content and store it in a persistent layer – example a database/file, or in the application memory. The browser polls the latest response periodically, performs DOM manipulation to updates the page – and the user gets to see the latest record. Lets look at the polling techniques in my next post.