Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Rusty Brooks [EMAIL PROTECTED] wrote: Internet explorer does not, from my examination of the available literature, support server push, at least not in any way I could get it to work. You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. *chuckle* -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On Thu, 20 Dec 2001, Dossy wrote: You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. ...or a Java applet, or a Tclet, or some other _non-HTTP_ solution. That's what I was saying -- HTTP is the wrong protocol for this. Doesn't mean HTTP isn't a good protocol, it just means it wasn't designed for this type of dialog control. Pete.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
This is a variant of your worker-thread problem from earlier, isn't it? I'll begin with a sermon -- if you brought your hymnal, please turn to the appropriate page; if you don't want to be bored by my opinion, please skip to the next paragraph. Worker threads and progress notification are a hallmark of modern UI design, and help give users of software feedback on the progress of the system. The problem is that these devices require an underlying mechanism that provides adequate latency for issuing progress notification. HTTP is terrible at doing this, because the protocol is designed to be silent between request and response, this denying the application author the opportunity to let the visitor know what's going on -- you can't talk to them until you're done. In short words, the Web ain't Windows. It is customary and acceptable on the web to provide a warning before the visitor hits the big long request button that this will take a while -- go get coffee/soda/Tolstoy so you can just do the request and let the visitor take the consequences. It's not the best UI design, but it is pretty good client-server design. If you really need to control the dialog with low latency, you need a client other than a web browser. Again, this entire paragraph is my opinion, and you're welcome to disagree. Now to solutions: If you were to just generate the data and return it through a normal ns_return (or through an .adp), and if the output channel were to die because the visitor cancelled the request, AOLserver would discard the data. Your process will have spent time and money generating the data, but is it otherwise harmful? One problem I can think of with this approach is that you might get an inadverdent denial-of-service from folks who think the system is just slow, and keep hitting reload. In this case, you could have an nsv counter for a number of processors you want to allow; increment when you start generating, decrement after; if too many are in process (you would need to define too many), then you could return a too busy -- try later page to the visitor. If you really want to control the dialog with the visitor then one approach would be to go back to your worker-thread approach, but the worker-thread doesn't return anything to the visitor. The initial request generates a request ID and sends a page with a refresh back to the visitor that says something like click here to get your results, or your browser will automatically check for them every n seconds. On subsequent refreshes, you can just display the same request to the visitor, or you could give them an option to click here if you're so bored you don't care anymore, in which case you could signal the worker-thread somehow that it can stop now and release its resources. On your intermediate status page, you could even display a progress notifier that could show what percent of the data generation is complete, if you have that information. This approach avoids the immediate denial-of-service, because you give more immediate feedback, but you might still want to constrain how many worker threads you are willing to spin off, using an nsv counter again. On Wed, 19 Dec 2001, Ramin Naimi wrote: Is it possible for a module to get notified that a GET or POST request was cancelled by the client? My procedure will take a long time to process and I would like to know (during processing) if the request was cancelled. I suppose I can do a Ns_ConnPuts during my processing and check for it's return value and assume that if it failed then the request was cancelled. Is there a more cleaner way?
Re: [AOLSERVER] How does a module know a GET or POST request was
But here's the thing -- what does it waste to keep running when the client is gone? For most web applications (in my opinion), I think it doesn't hurt anything to finish generating the result even when nobody's listening anymore, and it makes programming significantly more complex. If generating the result is going to cost you something, then don't generate the result unless you know someone's going to use it. If you can't do that, and it's still going to cost you something, then you need to control how many requests you'll process at any one time. Programming it this way is simple, and will work in any web application framework. I really think trying to control the dialog with the visitor, even if only to notice that they aren't listening anymore, is the wrong paradigm for web programming. Pete. On Wed, 19 Dec 2001, Jim Wilcoxson wrote: I don't know how to do it (tried a bunch of things), but agree it would be nice to know if the browser side of the connection has died because of a user hitting escape or whatever. Some processes may take several minutes. If a user gets impatient or double-clicks, it's a waste to keep running when the client is gone. Some way to poll for this would be cool...
Re: [AOLSERVER] How does a module know a GET or POST request was
Pete, you said don't generate the result unless you know someone's going to use it. That's the point of having a way to poll if the browser is still there - to see if they are going to use it. We do control # of requests, but it isn't straightforward. All of the code has to be very controlled with catches around everything to ensure that if any error occurs, the count of current requests gets decremented, no error returns while the count is incremented, etc. If someone double-clicks, it's much easier to just add if client has died, stop rather than a shared data structure to see if they are running twice, and you still have the problem of how to stop the first process when the second one starts up (because of double-clicking). If someone says show me a traffic summary for the last 2 years, by week, ordered by blah, it may not be trivial to generate that kind of report. So it does hurt to keep on doing it when no one is listening. Jim But here's the thing -- what does it waste to keep running when the client is gone? For most web applications (in my opinion), I think it doesn't hurt anything to finish generating the result even when nobody's listening anymore, and it makes programming significantly more complex. If generating the result is going to cost you something, then don't generate the result unless you know someone's going to use it. If you can't do that, and it's still going to cost you something, then you need to control how many requests you'll process at any one time. Programming it this way is simple, and will work in any web application framework. I really think trying to control the dialog with the visitor, even if only to notice that they aren't listening anymore, is the wrong paradigm for web programming. Pete. On Wed, 19 Dec 2001, Jim Wilcoxson wrote: I don't know how to do it (tried a bunch of things), but agree it would be nice to know if the browser side of the connection has died because of a user hitting escape or whatever. Some processes may take several minutes. If a user gets impatient or double-clicks, it's a waste to keep running when the client is gone. Some way to poll for this would be cool...
Re: [AOLSERVER] How does a module know a GET or POST request was
I'd have to agree with most of what you wrote, although I still think you can get around most of the problems (except double-clicking) with a stern warning -- perhaps an interstitial page -- that provides an estimate of how long the process will take; those estimates may not be trivial to come up with, but I think the cost of creating the estimates needs to be compared to the cost of waste. Regarding double-clicking, the most effective solution I've seen to this is to generate a request ID embedded in the request page, so that when you accept the request, you compare the request ID to the available results, and return the result, if available. If not, you can wait until it is available. The first process doesn't have to be stopped, and the second would just be waiting for the first to complete; this only wastes a thread, but it may be cheaper than reengineering ns_conn. I really do get that there are times when it would be nice to halt processing that no one will listen to, but I think it will be more expensive to implement this feature than to engineer the UI to minimize the number of times that happens. But that's just my opinion.
Re: [AOLSERVER] How does a module know a GET or POST request was
I guess I'll have to look at the AOL code sometime when I get a chance. It seems like when a browser closes a connection, a select event will occur on that fd, something will get marked, and creating an ns_conn polling command that said whether the fd is closed would not be a big deal... But maybe that's not the way it happens. I think a big point not to overlook is that I could develop what you are talking about, having used AS for many years. A new user probably couldn't. So what is just nice for me becomes necessary for them. Jim I'd have to agree with most of what you wrote, although I still think you can get around most of the problems (except double-clicking) with a stern warning -- perhaps an interstitial page -- that provides an estimate of how long the process will take; those estimates may not be trivial to come up with, but I think the cost of creating the estimates needs to be compared to the cost of waste. Regarding double-clicking, the most effective solution I've seen to this is to generate a request ID embedded in the request page, so that when you accept the request, you compare the request ID to the available results, and return the result, if available. If not, you can wait until it is available. The first process doesn't have to be stopped, and the second would just be waiting for the first to complete; this only wastes a thread, but it may be cheaper than reengineering ns_conn. I really do get that there are times when it would be nice to halt processing that no one will listen to, but I think it will be more expensive to implement this feature than to engineer the UI to minimize the number of times that happens. But that's just my opinion.
Re: [AOLSERVER] How does a module know a GET or POST request was
On Wed, 19 Dec 2001, Jim Wilcoxson wrote: I think a big point not to overlook is that I could develop what you are talking about, having used AS for many years. A new user probably couldn't. So what is just nice for me becomes necessary for them. So maybe we should create a module or Tcl library that implements this so it's easy for newcomers. I'd rather promote good UI engineering than try to hack to system to accomodate (what I regard as) less than good UI engineering. In my copious spare time...
Re: [AOLSERVER] How does a module know a GET or POST request was
If someone says show me a traffic summary for the last 2 years, by week, ordered by blah, it may not be trivial to generate that kind of report. So it does hurt to keep on doing it when no one is listening. Jim But is there an efficient way to determine the connection has been broken? From what I've seen in the code, AOLserver detects broken connections the *next* time it tries a write or read of a connection. When someone clicks on a bring-your-server-to-the-knees-query, after AOLserver hands it to your code, nothing else is done on that connection until your code tries to return a page. At that point, the write will get a connection broken error. Is it possible for a TCP based connection to know when a socket is broken *as it happens*? If possible is that an efficient manner to run webserver based communications? Jerry Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: If you really need to control the dialog with low latency, you need a client other than a web browser. Again, this entire paragraph is my opinion, and you're welcome to disagree. I agree, but you didn't recommend a third, very useful solution: Server push. Explanation and implementation is left as an exercise for the reader. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was
On 2001.12.19, Jerry Asher [EMAIL PROTECTED] wrote: When someone clicks on a bring-your-server-to-the-knees-query, [...] I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of query or functionality? Doctor, doctor, it hurts when I code things poorly! Is it possible for a TCP based connection to know when a socket is broken *as it happens*? Depends. If the remote end tears down the socket connection, it will send a FIN. The server sees the FIN and knows that the remote end wants to tear down the connection, so it sends back an ACK, then its own FIN (when it starts to tear down the connection, via close() or whatever). Then it expects an ACK from the remote end. This is typically what happens when a user hits stop in their browser. If the remote end disappears off the network, no FIN will arrive. In this case, the only way to know if the remote end is still listening is to send it a datagram and wait for the ACK ... and if you get no ACK, then the connection is dead. This typically happens when people are connected via dialup, and their modem hangs up. If possible is that an efficient manner to run webserver based communications? If it was, don't you think that's the way most webservers would be implemented? AOLserver could probably get away with it if the thread handling the socket connection was seperate from the thread executing the code generating the page to return ... but is it really worth it, if you design your web applications properly? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
The last time I looked at server push, there was one example on the netscape site, and it appears that the mechanism used is no longer widely supported by the browser. Can you point this interested reader to a better example? On Wed, 19 Dec 2001, Dossy wrote: I agree, but you didn't recommend a third, very useful solution: Server push.
Re: [AOLSERVER] How does a module know a GET or POST request was
On Wed, 19 Dec 2001, Dossy wrote: I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of query or functionality? I just needed to correct this point -- I'm arguing for managing visitor expectations better. Sometimes a bring-your-server-to-its-knees request is OK, as long as it's understood beforehand that the request will have this effect.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: The last time I looked at server push, there was one example on the netscape site, and it appears that the mechanism used is no longer widely supported by the browser. Can you point this interested reader to a better example? One way of doing it (which isn't great, but it's easy to implement) is: http://aolserver.com/docs/devel/tcl/tcl-api.adp#ns_adp_stream Another way is hand-crafting your own HTTP response using multipart MIME, with each part being of type text/html (or whatever is appropriate). Every so often, before the timeout elapses, either send the keep-alive part (can't remember what it is off the top of my head) or your actual content part. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2001, Dossy wrote: I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of query or functionality? I just needed to correct this point -- I'm arguing for managing visitor expectations better. Sometimes a bring-your-server-to-its-knees request is OK, as long as it's understood beforehand that the request will have this effect. I still think it's a design issue. If there's something that's going to take a long time, then kick off the request in a worker thread, return the user to the website but provide them a link somewhere in the navigation that lets them bring up the long-running process when it's done. This implies session management has been implemented as well, but hey, nobody said life was easy. You could also use the dslreports.com trick. One page kicks off the expensive, potentially long-running query but returns a page that says processing ... with an animated GIF. The GIF pretends to be a status bar, and the last frame of the GIF (it's non-looping) says done! click here to view your results. The image is a link to the next page which pulls the results (from a database?) and displays them. If a user clicks on the image early, the results page displays no info. available placeholders for what's still being computed. It's trickery, but it's still better than having a user sit watching a spinning globe ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On Wed, 19 Dec 2001, Rusty Brooks wrote: print out a please wait type page, with enough text that it gets written out right away. This was done with ns_write in an adp. I suggested something like this earlier, although with an asynchronous worker thread. I think that better than please wait would be to offer an estimate of time remaining, or some other concrete progress implementation (% done), so the user has some idea how long to wait.
