|
|
Posted by amygdala on 06/03/07 15:24
"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.
Navigation:
[Reply to this message]
|