Incidentally Elv, if you're still working on this project I'll add it to the "projects" section as "Shining Ajax" (unless you have another name for it
)| Pages: 1 [2] |  |
AJAX - A Viable Option? (Read 33591 times)
January 09, 2007, 10:10:09 am
Administrator
Shining Sideburns 
Posts: 837
Logged
Re: AJAX - A Viable Option?
"Reverse Ajax" sounds much more useful any kind of online game or chat application. It would certainly decrease the load for larger games.
Incidentally Elv, if you're still working on this project I'll add it to the "projects" section as "Shining Ajax" (unless you have another name for it)
Incidentally Elv, if you're still working on this project I'll add it to the "projects" section as "Shining Ajax" (unless you have another name for it
)
January 11, 2007, 03:48:18 am 
Posts: 230
Logged
Re: AJAX - A Viable Option?
IIS seems to have a default script timeout of 90 seconds. You might be able to extend that but it's not really necessary, a request every 90 seconds is no load at all, plus in a normal application workflow you shouldn't get to 90 seconds anyway.
We don't even need to avoid the timeout. Your Ajax object on the client will probably trigger its httpError event if the server times out, so you will be able to detect when this happens.
On the server we could hold the request with a loop:
But if possible we'd rather have the worker process go to sleep instead of having it spin in a loop, taking up CPU time. For example:
Then on the client the idea is to always have a request down at the server. Anytime the server returns, the client immediatly sends another request to the server. The way i see it we'll have two Ajax objects, one for sending, and one for receiving. The Ajax sender object will send stuff to the server at any time, and so works just like a regular Ajax object. The receiver Ajax object on the other hand immediatly contacts the server. The server holds the receiver's request until it has something. When the receiver's request returns, either because of timeout or because the server returned some value, the receiver triggers an event, OnReceive for example, and immediately contacts the server again.
For example:
Jax is an Ajax object that i did for cross-browser compatibility. Once we have this in place the Ajax socket is pretty easy to use. It has a method for sending and an event for receiving, which is all we need. This is a reverse Ajax implementation.
We don't even need to avoid the timeout. Your Ajax object on the client will probably trigger its httpError event if the server times out, so you will be able to detect when this happens.
On the server we could hold the request with a loop:
Code:
while(this.HasNothingToReturn){}
return SomethingToReturn;
But if possible we'd rather have the worker process go to sleep instead of having it spin in a loop, taking up CPU time. For example:
Code:
while(this.HasNothingToReturn){
Sleep(1000); //sleep for 1 second
}
return SomethingToReturn;
Then on the client the idea is to always have a request down at the server. Anytime the server returns, the client immediatly sends another request to the server. The way i see it we'll have two Ajax objects, one for sending, and one for receiving. The Ajax sender object will send stuff to the server at any time, and so works just like a regular Ajax object. The receiver Ajax object on the other hand immediatly contacts the server. The server holds the receiver's request until it has something. When the receiver's request returns, either because of timeout or because the server returned some value, the receiver triggers an event, OnReceive for example, and immediately contacts the server again.
For example:
Code:
AjaxSocket = function(serverPath){
this.Receiver = new Jax(serverPath);
this.Receiver.handler = this;
this.Sender.onComplete = function(msg){
this.handler.OnReceive(msg);
this.handler.Listen();
}
this.Sender.onHttpError = function(err){
this.handler.Listen();
}
this.Sender = new Jax(serverPath);
this.Listen();
}
AjaxSocket.prototype.Send = function(msg){
this.Sender.GETRequest(pathToServerSenderScript, false);
}
AjaxSocket.prototype.Listen = function(){
this.Sender.GETRequest(pathToServerReceiverScript, false);
}
AjaxSocket.prototype.OnReceive = function(msg){
//this event gets called when we receive something
}
Jax is an Ajax object that i did for cross-browser compatibility. Once we have this in place the Ajax socket is pretty easy to use. It has a method for sending and an event for receiving, which is all we need. This is a reverse Ajax implementation.
May 08, 2007, 01:24:01 am
Posts: 230
Logged
Re: AJAX - A Viable Option?
I have my Reverse Ajax setup ready. There's a few challenges in implementing Reverse Ajax.
For example, web servers (IIS in my case) have a thread pool per hosted web application. The typical size of the thread pool is 20-25 threads, and though it may have a growth coefficient, there's a maximum number of threads that the thread pool can hold.
If the thread pool has a max of 25 threads and 100 requests come in, then 75 requests are queued until a thread becomes available. If the first 25 requests are Reverse Ajax requests which usually sleep until a given condition is true (i.e. an instant message is received), then those 25 requests might take a while to complete. I'd say possibly up to 5 minutes. meanwhile more and more threads queue up, some which might also be reverse Ajax requests, and in no time the web server will be completely overloaded.
To avoid this scenario, we need to spawn new non-web-server threads to service Reverse Ajax Requests. This way though they may take a while to service they will not hold up the web server.
With this approach however, if 1000 Reverse Ajax requests come in, then 1000 threads are spawned. To eliminate this possibility we actually need a custom thread pool, similar to the web-server's thread pool, which has a maximum number of allowed threads, and which queues any requests which can't be serviced immediately.
On top of this, you also need IIS to be able to service requests asynchronously i.e. IIS should move Reverse Ajax requests to the Reverse Ajax thread pool, continue with its business, then return to finalize the request once the Ajax thread pool is done with it.
Surprisingly ASP.NET has very good support for all of this. I don't know for example, if this could be done in PHP.
In ASP.NET we can use the IHttpAsyncHandler for asynchronous requests. Creating a custom thread pool is a little more work, but there is at least one available on the web. This is a useful link which i used alot:
http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx
For example, web servers (IIS in my case) have a thread pool per hosted web application. The typical size of the thread pool is 20-25 threads, and though it may have a growth coefficient, there's a maximum number of threads that the thread pool can hold.
If the thread pool has a max of 25 threads and 100 requests come in, then 75 requests are queued until a thread becomes available. If the first 25 requests are Reverse Ajax requests which usually sleep until a given condition is true (i.e. an instant message is received), then those 25 requests might take a while to complete. I'd say possibly up to 5 minutes. meanwhile more and more threads queue up, some which might also be reverse Ajax requests, and in no time the web server will be completely overloaded.
To avoid this scenario, we need to spawn new non-web-server threads to service Reverse Ajax Requests. This way though they may take a while to service they will not hold up the web server.
With this approach however, if 1000 Reverse Ajax requests come in, then 1000 threads are spawned. To eliminate this possibility we actually need a custom thread pool, similar to the web-server's thread pool, which has a maximum number of allowed threads, and which queues any requests which can't be serviced immediately.
On top of this, you also need IIS to be able to service requests asynchronously i.e. IIS should move Reverse Ajax requests to the Reverse Ajax thread pool, continue with its business, then return to finalize the request once the Ajax thread pool is done with it.
Surprisingly ASP.NET has very good support for all of this. I don't know for example, if this could be done in PHP.
In ASP.NET we can use the IHttpAsyncHandler for asynchronous requests. Creating a custom thread pool is a little more work, but there is at least one available on the web. This is a useful link which i used alot:
http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx