[RESOLVED] is timing out a problem?

gjwalsh

I am in the final stages of preparing a set of psych test instruments - as many as 13 in a service. I certainly don't want to depend on JavaScript, nor do I want to throw item validations back and forth for each item for very obvious reasons.

So ... my plan at the moment is to present a full test section to the client, validation taking place upon submission at the server. The items will be extracted from a MySQL data base, and submitted data will be written to the data base upon validation.

The client can be expected to take anywhere from 10 minutes to an hour to complete the work of a test section. Is PHP5 going to introduce any timeout problems of which I am not now aware? We also plan to use PHP5 to re-present unanswered items - this being the 'friendly way - do accomplish that job.

We are also planning to use PHP5 to allow a candidate to freely submit an incomplete test and select another one, just as he might in a paper and pencil situation.

This is an involved project and I want to ensure the underlying design considerations are sound.

If I am asking the impossible, please set me straight, but somehow I feel this can be done.

Weedpacket

PHP's execution timeout defaults to 30 seconds, but if that's what you're thinking it won't be an issue: there won't be a single PHP program running the whole time the client is taking the test - PHP only runs for the duration necessary to take the data supplied from the client at the previous page, process it, and deliver the content for the next page. That should take under a second.

To tie all these pages (rather, request/response transactions between the client computer and the server) together into a single process you'd require some sort of session management (without it there would generally be no way to tell which transactions are related).

PHP's default is to assume that any two consecutive transactions in the same session are no more than 1440 seconds apart (I don't know why 24 minutes was chosen); so as long as the client is communicating with the server more often than that, the session will remain live for as long as necessary.

As I said, that's the default: it can be adjusted (to an hour or more if you wish), but I'd also consider breaking the sections down further (but I'm saying that without knowing what each section entails or why it might take so long, of course - I can certainly think of cases where that would be unreasonable).

Furthermore, (by default) PHP won't kill off a "stale" session immediately it runs over its time limit. Such garbage collection is a bit time-consuming so its operation has been built to be probabilistic ... rather than go into detail I've decided to just refer you to the "forgotten documentation": the php.ini file where these things are configured.

So; you'll need session management. With that in place, assuming that you configure it to allow plenty of time for the user to complete each page/section of the test, you shouldn't have any timeout issues.

gjwalsh

Thanks, 'Weedpacket', you make for an understanding helper and it is truly appreciated.

Although I have been involved with Unix -> Linux since 1969, that has been almost exclusively with C although I did run an extensive travel site for a consortium which brought me up to speed with JavaScript and then (thank God) the blessings of W3C and CSS.

So .... I readily understand session control and the need for it. The sections I talk about are entities in themselves and cannot be broken apart logically. Yes, I can extend the time limits in .ini, but your helpful suggestions gave me something else to consider - a way to protect the client from frustration with possible lost data. (Because we test for power, not speed, we never want to make the client feel he is being timed for any purpose!)

Is it conceptually possible to force an update 'behind the scenes' - in the manner of OOo spreadsheets for example? I know this would be tricky - maybe like my implanting a hidden submit of some sort to write the responses into the raw scoring array in MySQL, or simply embedding an 'update' at appropriate intervals in the test items? That would not be foolproof, but I think most folks would follow along with it. I don't want to annoy the 'fast writers' by sectioning the tests but if there is no other way then I guess that's the path I must walk down.

Sorry about the length of this - it is sometimes difficult to convey a design concept when the person trying to help is not conversant with the 'whole picture'.

Be that as it may, I am VERY appreciative of your input while I coax the power I need out of PHP.

Again, my thanks!

George

Weedpacket

It would indeed be possible; since it relies on the browser initiating communication with the server it would involve using Javascript.

Every once in a while, a Javascript routine runs that gathers the current state of the form and, using an XMLHttpRequest (nothing fancy; this would be good enough), upload it to the server. The page it submits to updates the database.

Even that is more complicated than necessary (though it adds a degree of robustness should the testee suffer any loss at their end); all that needs to happen is that the client connects sends a request to the server, which can probably get away with running little more than

<?php session_start(); ?>
I hear you.

in response. As long as the server continues to receive that "heartbeat" signal from the client, the session's lifetime will continue to be reset.

gjwalsh

I like your 'heartbeat' analogy. And I understand the need to rely on JavaScript to trigger things from the client's end.

The design criteria I am trying to meet for some of the institutions we would be working with prefers a stiff 'no' to client-side script - one of the factors which got me looking so seriously at PHP in the first place, although now I am liking it for its own sake.

One of them suggested that because I have a very definite web page design - ie fixed and stated 'window' sizes, and because I have created more of a 'book' look than a 'screen' look, the way to go is simply use PHP to update the data bases at the end of eech defined 'page' . What appeals to me there is the clients is just doing what comes naturally and 'turning the page'. I'm going to play with that next week. It might be a good compromise; more small bits of data being exchanged but no loss beyond responses to the current page. One other advantage, too. Printing out test sections would be too messy for the client to be bothered with!

I'm not really that paranoid .... but some of our work is going to be made available to corrections people on both sides of the border.

Again, you have been very helpful.

gjwalsh

One follow up note: The privacy statement we have written in plain english! - is a tough one. You can see it at www.dscdirectionalservices.com/privacy.html if you'd like.

Following your suggestions, and a strong cup of cffee, I've decided to work through this the hard way and try one of the test sections using the alternatives for scripting, but not conveying this to the beta testing group. Then I'll ask for comments about speed of response and ease of use and take it from there.

I'm hoping I can engineer a win for PHP!!!

Again, my sincere thanks .....

Weedpacket

gjwalsh wrote:
The design criteria I am trying to meet for some of the institutions we would be working with prefers a stiff 'no' to client-side script - one of the factors which got me looking so seriously at PHP in the first place, although now I am liking it for its own sake.

As long as the session timeout is large enough to begin with you should be okay without the client-side scripting; if you specify a maximum lifetime of one hour then page requests for a given session can occur up to one hour apart. This can go on for as long as necessary.

And since garbage collection is only probabilistic (whenever session_start() is called there is by default a 1% chance that old sessions will be deleted), there may even be a bit of slack. One hundred people making five requests in the space of a single hour makes for five hundred requests, meaning you can expect garbage collection to happen five times. So once a given session has been idle for an hour, it can expect (to a very rough first approximation) a further ten minutes' grace before being gc'd. Needless to say, if you wanted the extra time, it would be more reliable to set the session lifespan to an hour and ten minutes 🙂

From the privacy policy:

This is an easy one for us. We simply do not write cookies to your computer for any reason.

This may be an irritation. For PHP's session management to work it needs to provide a session ID token that the client presents whenever it makes a request. Ideally, this is stored in a session cookie (a cookie that has had its lifetime set to 0 and is therefore destroyed when the client shuts down). The token itself is meaningless, existing merely to uniquely identify the session (it doesn't even identify the client, since a different session from the same client will have a different session ID). Since this cookie only lasts on the client while it is running, most clients would not have any need to save it anywhere on the user's machine.

If cookies are not available, PHP's fallback mechanism is to embed the session ID in all the URLs in the page that point back to the site. It's covered more fully in the manual of course, but suffice it to say that having the session ID in the URL is very much a fallback position (even when sent over an encrypted connection that URL with its embedded ID may be visible to others - e.g., your server's activity logs, their browser's address bar).

gjwalsh

I will extend the time limit as you suggested after splitting into two parts the one test which could be expected to exceed one hour. Also, I will reword the privacy policy to clearly define the sole situation where test sessions require a token, and I will describe the limitations on that token.

Once again, I appreciate your guidance so very much. Amid all the other decisions being made to pull all of this site together, you have calmed some of the waters and I acknowldge that and will, in time, be happy to do my part in helping others.

richa

Hi, regarding dealing with session timeouts, this may be helpful:
http://freeajaxscripts.net/directory/Ajax_Forms/Prevent_PHP_session_timeout_during_form_entry/details.html

It is some Ajax to validate the session is still valid, and prevent form entry if not.
Rich