Posted by Jerry Stuckle on 06/03/07 16:10

amygdala wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> schreef in bericht
> news:Zb2dnQwpjKM2RP_bnZ2dnUVZ_v6tnZ2d@comcast.com...
>> amygdala wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> schreef in bericht
>>> news:YrqdnQcjBsSkq__bnZ2dnUVZ_j6dnZ2d@comcast.com...
>>>> amygdala wrote:
>>>>> "Alexey Kulentsov" <crimaniak@crimaniak.com> schreef in bericht
>>>>> news:4661b521$0$90262$14726298@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.
jstucklex@attglobal.net
==================

[Back to original message]