Is it possible to avoid loading the script for each request

[DavidNorep]

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?

[ZeldorBlat]

Re: Is it possible to avoid loading the script for each request

On Jun 1, 3:00 am, DavidNorep <avdavid.nore.. .@gmail.comwrot e:

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?

[DavidNorep]

Re: Is it possible to avoid loading the script for each request

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.

[Tom]

Re: Is it possible to avoid loading the script for each request


"DavidNorep " <avdavid.norepl y@gmail.comwrot e in message
news:1180720872 .320392.295500@ q75g2000hsh.goo glegroups.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

[ZeldorBlat]

Re: Is it possible to avoid loading the script for each request

On Jun 1, 2:01 pm, DavidNorep <avdavid.nore.. .@gmail.comwrot e:

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-
FClnxw01linuxco detips>

[NC]

Re: Is it possible to avoid loading the script for each request

On Jun 1, 12:00 am, DavidNorep <avdavid.nore.. .@gmail.comwrot e:

>
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

[NC]

Re: Is it possible to avoid loading the script for each request

On Jun 1, 11:01 am, DavidNorep <avdavid.nore.. .@gmail.comwrot e:

>
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

[Alexey Kulentsov]

Re: Is it possible to avoid loading the script for each request

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.

[amygdala]

Re: Is it possible to avoid loading the script for each request


"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
news:4661b521$0 $90262$14726298 @news.sunsite.d k...

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.

[amygdala]

Re: Is it possible to avoid loading the script for each request


"amygdala" <noreply@norepl y.comschreef in bericht
news:46622008$0 $25488$9a622dc7 @news.kpnplanet .nl...

>
"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
news:4661b521$0 $90262$14726298 @news.sunsite.d k...

>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

[Jerry Stuckle]

Re: Is it possible to avoid loading the script for each request

amygdala wrote:

"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
news:4661b521$0 $90262$14726298 @news.sunsite.d k...

>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.
jstucklex@attgl obal.net
=============== ===

[amygdala]

Re: Is it possible to avoid loading the script for each request


"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
news:YrqdnQcjBs Skq__bnZ2dnUVZ_ j6dnZ2d@comcast .com...

amygdala wrote:

>"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
>news:4661b521$ 0$90262$1472629 8@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.

[Jerry Stuckle]

Re: Is it possible to avoid loading the script for each request

amygdala wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
news:YrqdnQcjBs Skq__bnZ2dnUVZ_ j6dnZ2d@comcast .com...

>amygdala wrote:

>>"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
>>news:4661b521 $0$90262$147262 98@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.
jstucklex@attgl obal.net
=============== ===

[amygdala]

Re: Is it possible to avoid loading the script for each request


"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
news:Zb2dnQwpjK M2RP_bnZ2dnUVZ_ v6tnZ2d@comcast .com...

amygdala wrote:

>"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
>news:YrqdnQcjB sSkq__bnZ2dnUVZ _j6dnZ2d@comcas t.com...

>>amygdala wrote:
>>>"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
>>>news:4661b52 1$0$90262$14726 298@news.sunsit e.dk...
>>>>DavidNore p 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_li mit() 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.

[Jerry Stuckle]

Re: Is it possible to avoid loading the script for each request

amygdala wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
news:Zb2dnQwpjK M2RP_bnZ2dnUVZ_ v6tnZ2d@comcast .com...

>amygdala wrote:

>>"Jerry Stuckle" <jstucklex@attg lobal.netschree f in bericht
>>news:YrqdnQcj BsSkq__bnZ2dnUV Z_j6dnZ2d@comca st.com...
>>>amygdala wrote:
>>>>"Alexey Kulentsov" <crimaniak@crim aniak.comschree f in bericht
>>>>news:4661b5 21$0$90262$1472 6298@news.sunsi te.dk...
>>>>>DavidNor ep 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
>>>>>>request s from a website (a Java applet in my case) and serve the
>>>>>>request s 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_l imit() 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.
jstucklex@attgl obal.net
=============== ===