Re: Is there a Perpetual Listener or Server Push concept?

In order to do my method you have to have control of the server. Apache is not set up to do this out of the box. You need to write your own server that keeps the connections open. And yes, it does block one of the 2 available connections for a typical browser. You can manually increase that but you can not increase it via code. So increasing the number of connections is not practical under normal circumstances.

Generally when I think about someone writing a web application, I automatically think they are writing both ends of the app, not just a client part, that wouldn't make sense. I guess I am spoiled as we wrote the entire server from scratch so we can pretty much do what we want with the port connections.

There is a product that can be obtained (I don't know if it is free or for a fee) called WebOrb that has an open connection to the server, but you need to use their server code in order to make it happen. To the best of my knowledge, it is not possible to do what you want to do by hitting a generic server that doesn't have some sort of custom code running on it.

Jim

On Fri, Jun 26, 2009 at 5:31 AM, Gene Amtower <gene@...> wrote:

Jim/Deech,

I'm wondering what this is going to look like on the server end, and if Apache or whatever web server is being called will consider this a hung server thread and close it?  If one has control over the server end, that might be configurable, but otherwise it might be hit or miss.  Besides the web server, I think PHP has a time limit for responses as well, but you didn't say what environment you're using on the server.  I remember having an old Apache 1.0 server drive itself into oblivion from hung server processes many years ago.  Each connection process consumes server memory, and too many open connections may cause the server behavior to become erratic or non-responsive.  If you have too many clients running the application at one time, this could be a significant concern for scalability of the app.

Deech, does it have to be real-time, as in immediate, instead of waiting for an update request communication to happen periodically (every few seconds)?  Do you have complete control over the configuration of the server in this case?  Are there other sites or applications running on the same server instance?  How often do you expect communications from the server to occur?  When you do get a response from the server, will communications come in bursts or singly? 

>From your question, it sounds like you're concerned about the time between one response and the time required to setup the next request.  Another idea might be to have two requests queued up at any given time, and initiate a new replacement when one of them gets a response.

Streaming media probably has a similar use case, but it keeps the connection alive through continuous data transfer or repeated requests - I'm not sure which.  I haven't implemented any streaming media applications, but it's functionality seems similar to your requirement.  Maybe there's a clue in how that type of application is implemented.

HTH,

   Gene

On Thu, 2009-06-25 at 21:18 -0700, Jim Hunter wrote:

If I was going to do this, I would set the timeout of the qooxdoo request object to something very high, then on the server side when you get the request from the client, don't respond until you heve something to send to the client. Then once that request is complete simply do it again.

Jim

On Thu, Jun 25, 2009 at 2:42 PM, aditya siram <aditya.siram@...> wrote:

Hi all,
I would like to set up continuous communication channel with the server. Right now I am trying to model this by having a button automatically requery the server with a dummy variable once it's request has been completed.

However because the Request object is 'dispose()'ed after a 'completed' event, there is a latency between the end of this request and the beginning of the next.

Is there a better way of doing this? If not is there some way for the server to push changes to the client?

-deech


------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel