Persisten connection....

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  I have a script (cgi) that sends every 5 seconds a code to the browser to
     mantain the connection open
2.  Stracing the forked index.cgi i see that the child  sends every 5
seconds the
     code for testing the status of the opened window 
3.  The index.cgi itself creates the stream and outputs the stream but this
will not
     be sent over the net, only on stdout

The expected result is to see the client window busy due to the connection
from 
server.

instead of this i see only the window withouth having the @busy@ state

I use the latest code on a Debian system

My cgi works in this manner:

the clients authenticates against mongoose/index.cgi
if the authentication is ok the cgi goes into loop and every 5 seconds
it sends a packet to the client for ensuring it's alive.

Do you have a simple example on how to do this with mongoose?
If possible, of course!

Tx, Diaolin

Original issue reported on code.google.com by diao...@gmail.com on 12 Mar 2009 at 3:41

[GoogleCodeExporter]

The code works with apache...
if this may help...

Original comment by diao...@gmail.com on 12 Mar 2009 at 4:30

[GoogleCodeExporter]

Do you use chunked transfer? Could you attach a *minimal* version of CGI script 
that
reproduces the problem?

Original comment by valenok on 22 Mar 2009 at 11:13

[GoogleCodeExporter]

Intercepted the error.

Stracing the mongoose process i see when i close the remote window a SIGPIPE 
signal.

The problem is that the signal will not be sent to the cgi itself.

And thus the cgi continues writing on STDOUT but not over the net due to the 
problem
that the window was closed and mongoose detaches the cgi from the net 
connection.

Is it possible to let mongoose pass the KILL -PIPE signal or whatever signal 
comes to 
the real cgi instead of throwing it to dev null?

I don-t know if this is the real problem but sending the same PIPE to the script
the cgi works ok.

This works even in Apache.

I-ll attach a simple text file that simulates the persistent.

just put it in a directory where you can exec cgi and from a 
remote browser call the cgi directly, every 5 seconds it changes the 
number of seconds via remote script.

When you clode the window/tab of the browser the mongoose receives a PIPE
signal but mongoose does not send the PIPE to the responsible of the socket.

Tx, Diaolin

Original comment by diao...@gmail.com on 23 Mar 2009 at 11:25

Attachments:

• test_persistent.tgz

[GoogleCodeExporter]

Mongoose now sends SIGTERM signal to the CGI process at the end of every CGI 
session.
The change is http://code.google.com/p/mongoose/source/detail?r=262
It leaves Windows version broken, which will be fixed in subsequent CL.

Original comment by valenok on 27 Mar 2009 at 9:30

• Changed state: Accepted

[GoogleCodeExporter]

Perfect, straced the process, a little bit slow, it has a 2-3 seconds of 
timeout but
it's OK, it send's
a TERM to the right process(probed with multiple process active).

Many thanks.

This work is SUPER.

Diaolin

Original comment by diao...@gmail.com on 27 Mar 2009 at 9:59

[GoogleCodeExporter]

Change http://code.google.com/p/mongoose/source/detail?r=263 cleanes up Window 
version.

As for slowness, this is not Mongoose's fault.
Mongoose cannot determine that client has closed the connection until it tries 
to
write something back to the client. And your CGI script performs writes at 5 
second
intervals, hence the delay. Reduce it in your script, and Mongoose will react 
faster.

Marking as fixed.

Original comment by valenok on 27 Mar 2009 at 10:13

• Changed state: Fixed

[GoogleCodeExporter]

Ok, no problem
Great work

Original comment by diao...@gmail.com on 27 Mar 2009 at 10:35

[GoogleCodeExporter]

Found another problem with IE any version....
The persistent connection detaches itself but it dies... immediatly.

With apache this does not happen and i don't know how to debug...

Diaolin

Original comment by diao...@gmail.com on 3 Jun 2009 at 8:02

[GoogleCodeExporter]

It might be interesting to see what versions of IE misbehave. There are lots of
problems with 8.0, such as not running Flash. Make this a new bug report, since 
this
one is marked Fixed.

Original comment by googl...@springtimesoftware.com on 28 Jun 2009 at 4:45