By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,825 Members | 2,437 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,825 IT Pros & Developers. It's quick & easy.

Is it possible to avoid loading the script for each request

P: n/a
I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.

In other words, can it function, in this sense, like a Java servlet?

Jun 1 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
On Jun 1, 3:00 am, DavidNorep <avdavid.nore...@gmail.comwrote:
I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.

In other words, can it function, in this sense, like a Java servlet?
What is the specific reason that you want to avoid loading the script
for each request?

Jun 1 '07 #2

P: n/a
To save time, to be able to respond to more requests.

I have also another question which is probably general for every CGI,
no matter in which technology it is implemented.

Suppose that a CGI is running and another request arrives, i.e., it is
invoked by another visitor to the website; will another instance of
the CGI start running or will the second request wait until the
running CGI finishes its work or is there a way to control this
behaviour.

Jun 1 '07 #3

P: n/a
Tom

"DavidNorep" <av*************@gmail.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...
To save time, to be able to respond to more requests.

I have also another question which is probably general for every CGI,
no matter in which technology it is implemented.

Suppose that a CGI is running and another request arrives, i.e., it is
invoked by another visitor to the website; will another instance of
the CGI start running or will the second request wait until the
running CGI finishes its work or is there a way to control this
behaviour.
I think programs like Apache are used to handling multiple requests at one
time. In a multi-user environment though you need to account for multiple
people making changes at the same time and the potential conflict with
people changing the same thing at the same time.

Tom
--
Newsguy.com - Unlimited Accounts
Now with 32 concurrent connections
Jun 1 '07 #4

P: n/a
On Jun 1, 2:01 pm, DavidNorep <avdavid.nore...@gmail.comwrote:
To save time, to be able to respond to more requests.

I have also another question which is probably general for every CGI,
no matter in which technology it is implemented.

Suppose that a CGI is running and another request arrives, i.e., it is
invoked by another visitor to the website; will another instance of
the CGI start running or will the second request wait until the
running CGI finishes its work or is there a way to control this
behaviour.
Read this article, particularly Tip #5:

<http://www.ibm.com/developerworks/li...-code/?ca=dgr-
FClnxw01linuxcodetips>

Jun 1 '07 #5

P: n/a
NC
On Jun 1, 12:00 am, DavidNorep <avdavid.nore...@gmail.comwrote:
>
I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for
each request.
No. But you don't have to configure your PHP setup as CGI;
configuring
it as an Apache module with an accelerator will do pretty much what
you
want; at the first call, the script will be compiled into bytecode
and
the bytecode will be cached, so beginning with the second call, the
script will not be loaded; cached bytecode will be used instead.
In other words, can it function, in this sense, like a Java servlet?
PHP is not Java. If you want something to function like a Java
servlet,
you should implement it as a Java servlet.

Cheers,
NC

Jun 2 '07 #6

P: n/a
NC
On Jun 1, 11:01 am, DavidNorep <avdavid.nore...@gmail.comwrote:
>
I have also another question which is probably general for every
CGI, no matter in which technology it is implemented.
Nope; it's highly specific to the OS and HTTP server.
Suppose that a CGI is running and another request arrives, i.e.,
it is invoked by another visitor to the website; will another
instance of the CGI start running or will the second request wait
until the running CGI finishes its work
If the second request arrives and the HTTP server has enough
resources remaining to serve a response, it will. If the second
request arrives and the HTTP server does not have enough resources
remaining to serve a response, the second client will wait as
long as it is configured to do, then time out.
is there a way to control this behaviour.
Yes, but you have to code for it. Every instance of the script
must start by checking if it is the only one running (there are
many ways to get this done). If it is, it should keep running;
if it isn't, it should issue a "Location:" header to redirect
the client to itself.

Cheers,
NC

Jun 2 '07 #7

P: n/a
DavidNorep wrote:
I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I
call it endless connection) long time ago, before AJAX era. It was PHP
script on server-side and javascript on client-side. You need
set_time_limit() to prevent timeout on server so you can't do it in safe
mode. And you need to send periodically something to prevent timeout on
client. Request sent to additional short script who put it to database
or another place. Main script in endless loop checks for new requests,
process it and sends result back to client.
Now here is no reasons to do such things.
Jun 2 '07 #8

P: n/a

"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk...
DavidNorep wrote:
>I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I call
it endless connection) long time ago, before AJAX era. It was PHP script
on server-side and javascript on client-side. You need set_time_limit() to
prevent timeout on server so you can't do it in safe mode. And you need to
send periodically something to prevent timeout on client. Request sent to
additional short script who put it to database or another place. Main
script in endless loop checks for new requests, process it and sends
result back to client.
Now here is no reasons to do such things.
Correct me if I'm wrong here, but I thought there was some sort of solution
for this, using sockets. Or is this perhaps what you are refering to
already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up on
that anymore. But I had the feeling though that this little script could
easily be ported to some webserver environment. Probably not too a stressful
environment, but still.

@ DavidNorep: you mentioned the use of a JAVA applet. I don't know much
about JAVA but I assume JAVA has some socket interfaces itself too, no? This
could rule out client timeouts I think.

Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input on
the socket. I'll have look around to see if I can find the script.

In the meanwhile do a search for sockets. That should give you some
direction.
Jun 3 '07 #9

P: n/a

"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .
>
"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk...
>DavidNorep wrote:
>>I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I call
it endless connection) long time ago, before AJAX era. It was PHP script
on server-side and javascript on client-side. You need set_time_limit()
to prevent timeout on server so you can't do it in safe mode. And you
need to send periodically something to prevent timeout on client. Request
sent to additional short script who put it to database or another place.
Main script in endless loop checks for new requests, process it and sends
result back to client.
Now here is no reasons to do such things.

Correct me if I'm wrong here, but I thought there was some sort of
solution for this, using sockets. Or is this perhaps what you are refering
to already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up on
that anymore. But I had the feeling though that this little script could
easily be ported to some webserver environment. Probably not too a
stressful environment, but still.

@ DavidNorep: you mentioned the use of a JAVA applet. I don't know much
about JAVA but I assume JAVA has some socket interfaces itself too, no?
This could rule out client timeouts I think.

Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input on
the socket. I'll have look around to see if I can find the script.
Forget what I said about not having to loop. It *did* need to loop. I found
the core of the script I used in the PHP manual under Socket Functions. I
remember again.

HTH
Jun 3 '07 #10

P: n/a
amygdala wrote:
"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk...
>DavidNorep wrote:
>>I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I call
it endless connection) long time ago, before AJAX era. It was PHP script
on server-side and javascript on client-side. You need set_time_limit() to
prevent timeout on server so you can't do it in safe mode. And you need to
send periodically something to prevent timeout on client. Request sent to
additional short script who put it to database or another place. Main
script in endless loop checks for new requests, process it and sends
result back to client.
Now here is no reasons to do such things.

Correct me if I'm wrong here, but I thought there was some sort of solution
for this, using sockets. Or is this perhaps what you are refering to
already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up on
that anymore. But I had the feeling though that this little script could
easily be ported to some webserver environment. Probably not too a stressful
environment, but still.
Good thing you didn't follow up with this though. A socket-attached
script is much different than a web-based one.
@ DavidNorep: you mentioned the use of a JAVA applet. I don't know much
about JAVA but I assume JAVA has some socket interfaces itself too, no? This
could rule out client timeouts I think.
Yes, java has socket interfaces. But it doesn't rule out client timeouts.
Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input on
the socket. I'll have look around to see if I can find the script.

In the meanwhile do a search for sockets. That should give you some
direction.

As I said - socket interfaces are much different that web-based ones.
For one thing - sockets typically stay open as long as the chat (or
whatever) session is active. Sockets used for HTTP are closed at the
end of each page.

A BIG difference.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 3 '07 #11

P: n/a

"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Yr******************************@comcast.com. ..
amygdala wrote:
>"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk. ..
>>DavidNorep wrote:
I do not know PHP, consider to write a CGI with this technology and
have the following question.

Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I call
it endless connection) long time ago, before AJAX era. It was PHP script
on server-side and javascript on client-side. You need set_time_limit()
to prevent timeout on server so you can't do it in safe mode. And you
need to send periodically something to prevent timeout on client.
Request sent to additional short script who put it to database or
another place. Main script in endless loop checks for new requests,
process it and sends result back to client.
Now here is no reasons to do such things.

Correct me if I'm wrong here, but I thought there was some sort of
solution for this, using sockets. Or is this perhaps what you are
refering to already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up
on that anymore. But I had the feeling though that this little script
could easily be ported to some webserver environment. Probably not too a
stressful environment, but still.

Good thing you didn't follow up with this though. A socket-attached
script is much different than a web-based one.
>@ DavidNorep: you mentioned the use of a JAVA applet. I don't know much
about JAVA but I assume JAVA has some socket interfaces itself too, no?
This could rule out client timeouts I think.

Yes, java has socket interfaces. But it doesn't rule out client timeouts.
>Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input on
the socket. I'll have look around to see if I can find the script.

In the meanwhile do a search for sockets. That should give you some
direction.

As I said - socket interfaces are much different that web-based ones. For
one thing - sockets typically stay open as long as the chat (or whatever)
session is active. Sockets used for HTTP are closed at the end of each
page.

A BIG difference.
Hmm, I probably didn't express myself good enough then. Or perhaps I'm
missing essential knowledge here. But the point I was hoping to get accross
was, that perhaps because JAVA can handle socket connections it wouldn't
have to be an HTTP socket that the applet connects to. Rather it could
maintain a statefull connection on some port? Does that make any sense? Or
am I talking complete rubbish here? Could very well be. ;-) Cause my
networking knowledge is very poor.
Jun 3 '07 #12

P: n/a
amygdala wrote:
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Yr******************************@comcast.com. ..
>amygdala wrote:
>>"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk.. .
DavidNorep wrote:
I do not know PHP, consider to write a CGI with this technology and
have the following question.
>
Is it possible to invoke a PHP script and let it endlessly wait for
requests from a website (a Java applet in my case) and serve the
requests when they arrive? I want to avoid loading the script for each
request.
Yes, but only for output. I done web chat with this technology (I call
it endless connection) long time ago, before AJAX era. It was PHP script
on server-side and javascript on client-side. You need set_time_limit()
to prevent timeout on server so you can't do it in safe mode. And you
need to send periodically something to prevent timeout on client.
Request sent to additional short script who put it to database or
another place. Main script in endless loop checks for new requests,
process it and sends result back to client.
Now here is no reasons to do such things.
Correct me if I'm wrong here, but I thought there was some sort of
solution for this, using sockets. Or is this perhaps what you are
refering to already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up
on that anymore. But I had the feeling though that this little script
could easily be ported to some webserver environment. Probably not too a
stressful environment, but still.
Good thing you didn't follow up with this though. A socket-attached
script is much different than a web-based one.
>>@ DavidNorep: you mentioned the use of a JAVA applet. I don't know much
about JAVA but I assume JAVA has some socket interfaces itself too, no?
This could rule out client timeouts I think.
Yes, java has socket interfaces. But it doesn't rule out client timeouts.
>>Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input on
the socket. I'll have look around to see if I can find the script.

In the meanwhile do a search for sockets. That should give you some
direction.
As I said - socket interfaces are much different that web-based ones. For
one thing - sockets typically stay open as long as the chat (or whatever)
session is active. Sockets used for HTTP are closed at the end of each
page.

A BIG difference.

Hmm, I probably didn't express myself good enough then. Or perhaps I'm
missing essential knowledge here. But the point I was hoping to get accross
was, that perhaps because JAVA can handle socket connections it wouldn't
have to be an HTTP socket that the applet connects to. Rather it could
maintain a statefull connection on some port? Does that make any sense? Or
am I talking complete rubbish here? Could very well be. ;-) Cause my
networking knowledge is very poor.

You made a comment: "My goal was to write a little http chat app."

Is this an http app? If so, the client will get timeouts - it can't be
helped. It's part of the protocol (and built into the browsers), no
matter what port you're running on (and no, http is not restricted to
port 80, although that's the most common one). But in general you'll
want some kind of webserver to help with the connections and processing.

If it's not a http app, you have more control over timeouts, although
they can still occur. But you won't be able to use browsers.

You can set up connections on many ports. But there's a lot more to
handling network connections than just opening a port - especially if
you're going to have multiple people connecting. And that's true in any
language.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 3 '07 #13

P: n/a

"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Zb******************************@comcast.com. ..
amygdala wrote:
>"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Yr******************************@comcast.com ...
>>amygdala wrote:
"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk. ..
DavidNorep wrote:
>I do not know PHP, consider to write a CGI with this technology and
>have the following question.
>>
>Is it possible to invoke a PHP script and let it endlessly wait for
>requests from a website (a Java applet in my case) and serve the
>requests when they arrive? I want to avoid loading the script for
>each
>request.
Yes, but only for output. I done web chat with this technology (I
call it endless connection) long time ago, before AJAX era. It was PHP
script on server-side and javascript on client-side. You need
set_time_limit() to prevent timeout on server so you can't do it in
safe mode. And you need to send periodically something to prevent
timeout on client. Request sent to additional short script who put it
to database or another place. Main script in endless loop checks for
new requests, process it and sends result back to client.
Now here is no reasons to do such things.
Correct me if I'm wrong here, but I thought there was some sort of
solution for this, using sockets. Or is this perhaps what you are
refering to already?

I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up
on that anymore. But I had the feeling though that this little script
could easily be ported to some webserver environment. Probably not too
a stressful environment, but still.

Good thing you didn't follow up with this though. A socket-attached
script is much different than a web-based one.

@ DavidNorep: you mentioned the use of a JAVA applet. I don't know
much about JAVA but I assume JAVA has some socket interfaces itself
too, no? This could rule out client timeouts I think.

Yes, java has socket interfaces. But it doesn't rule out client
timeouts.

Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input
on the socket. I'll have look around to see if I can find the script.

In the meanwhile do a search for sockets. That should give you some
direction.
As I said - socket interfaces are much different that web-based ones.
For one thing - sockets typically stay open as long as the chat (or
whatever) session is active. Sockets used for HTTP are closed at the
end of each page.

A BIG difference.

Hmm, I probably didn't express myself good enough then. Or perhaps I'm
missing essential knowledge here. But the point I was hoping to get
accross was, that perhaps because JAVA can handle socket connections it
wouldn't have to be an HTTP socket that the applet connects to. Rather it
could maintain a statefull connection on some port? Does that make any
sense? Or am I talking complete rubbish here? Could very well be. ;-)
Cause my networking knowledge is very poor.

You made a comment: "My goal was to write a little http chat app."
Yes you are right, my bad, slip of the tongue. I was implying a chat app
which would be build in a website (hence the 'incorrect' http comment). I
understand this is not correct terminology. I on occasion mix up
terminology. I tend to think people see through that and get the big picture
I'm getting after. But I need to watch my terminology better I guess. Mea
culpa ;-)
Is this an http app? If so, the client will get timeouts - it can't be
helped. It's part of the protocol (and built into the browsers), no
matter what port you're running on (and no, http is not restricted to port
80, although that's the most common one). But in general you'll want some
kind of webserver to help with the connections and processing.

If it's not a http app, you have more control over timeouts, although they
can still occur. But you won't be able to use browsers.

You can set up connections on many ports. But there's a lot more to
handling network connections than just opening a port - especially if
you're going to have multiple people connecting. And that's true in any
language.
I can easily imagine this to be true Jerry, but then, that's not what the OP
asked. The OP asked whether it was possible.
Jun 3 '07 #14

P: n/a
amygdala wrote:
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Zb******************************@comcast.com. ..
>amygdala wrote:
>>"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Yr******************************@comcast.co m...
amygdala wrote:
"Alexey Kulentsov" <cr*******@crimaniak.comschreef in bericht
news:46***********************@news.sunsite.dk ...
>DavidNorep wrote:
>>I do not know PHP, consider to write a CGI with this technology and
>>have the following question.
>>>
>>Is it possible to invoke a PHP script and let it endlessly wait for
>>requests from a website (a Java applet in my case) and serve the
>>requests when they arrive? I want to avoid loading the script for
>>each
>>request.
> Yes, but only for output. I done web chat with this technology (I
>call it endless connection) long time ago, before AJAX era. It was PHP
>script on server-side and javascript on client-side. You need
>set_time_limit() to prevent timeout on server so you can't do it in
>safe mode. And you need to send periodically something to prevent
>timeout on client. Request sent to additional short script who put it
>to database or another place. Main script in endless loop checks for
>new requests, process it and sends result back to client.
> Now here is no reasons to do such things.
Correct me if I'm wrong here, but I thought there was some sort of
solution for this, using sockets. Or is this perhaps what you are
refering to already?
>
I once ran a very small test with socket connections as a command line
script. My goal was to write a little http chat app. I didn't follow up
on that anymore. But I had the feeling though that this little script
could easily be ported to some webserver environment. Probably not too
a stressful environment, but still.
>
Good thing you didn't follow up with this though. A socket-attached
script is much different than a web-based one.

@ DavidNorep: you mentioned the use of a JAVA applet. I don't know
much about JAVA but I assume JAVA has some socket interfaces itself
too, no? This could rule out client timeouts I think.
>
Yes, java has socket interfaces. But it doesn't rule out client
timeouts.

Also, I vaguely recall the script didn't need to loop, it would just
listened to a socket, and started doing things as soon as it got input
on the socket. I'll have look around to see if I can find the script.
>
In the meanwhile do a search for sockets. That should give you some
direction.
As I said - socket interfaces are much different that web-based ones.
For one thing - sockets typically stay open as long as the chat (or
whatever) session is active. Sockets used for HTTP are closed at the
end of each page.

A BIG difference.

Hmm, I probably didn't express myself good enough then. Or perhaps I'm
missing essential knowledge here. But the point I was hoping to get
accross was, that perhaps because JAVA can handle socket connections it
wouldn't have to be an HTTP socket that the applet connects to. Rather it
could maintain a statefull connection on some port? Does that make any
sense? Or am I talking complete rubbish here? Could very well be. ;-)
Cause my networking knowledge is very poor.
You made a comment: "My goal was to write a little http chat app."

Yes you are right, my bad, slip of the tongue. I was implying a chat app
which would be build in a website (hence the 'incorrect' http comment). I
understand this is not correct terminology. I on occasion mix up
terminology. I tend to think people see through that and get the big picture
I'm getting after. But I need to watch my terminology better I guess. Mea
culpa ;-)
>Is this an http app? If so, the client will get timeouts - it can't be
helped. It's part of the protocol (and built into the browsers), no
matter what port you're running on (and no, http is not restricted to port
80, although that's the most common one). But in general you'll want some
kind of webserver to help with the connections and processing.

If it's not a http app, you have more control over timeouts, although they
can still occur. But you won't be able to use browsers.

You can set up connections on many ports. But there's a lot more to
handling network connections than just opening a port - especially if
you're going to have multiple people connecting. And that's true in any
language.

I can easily imagine this to be true Jerry, but then, that's not what the OP
asked. The OP asked whether it was possible.

Yes, and there's a big difference between *possible* and *practical*.

It's possible for me to build a 747. All the technical details are
easily available. But it's not practical.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 3 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.