Subject: [clisp-list] Refering to "CLISP & flushing on socket-stream"

From: Martin Atzmüller <[email-masked]>
Date: Wed, 7 Jun 2000 18:53:34 +0200 (MEST)

Hi

I just read the lisp newsgroup and found the article by Rafal Strzaliski,
regarding the above subject.

Maybe I can elaborate a bit on this.
Recently I wrote a HTTP-server for Clisp. When sending a POST-reply back
to Netscape, sometimes Netscape insisted that it had not seen all the data
before the connection was closed.
I used write-byte-sequence to write the data over the socket-stream.
When I inserted (sleep 1) or even (sleep 0.1) _before_  I closed the
connection, all worked fine.
I am not really sure, why.

I tried to use force-output or finish-output, but this did not help a lot.
When I looked at the sourcecode, I noted one thing:
In my opinion force-/finish-output do nothing on unbuffered streams, and a
socket-stream is an unbuffered stream, or am I wrong here?

Comments?

Cheers,

Martin

-- 
Homepage: http://jove.prohosting.com/~ygrats/
Mail: [email-masked]

Sent through GMX FreeMail - http://www.gmx.net

---

From: Eric Marsden <[email-masked]>
Date: 08 Jun 2000 11:35:22 +0200

>>>>> "ma" == Martin Atzmüller <[email-masked]> writes:

  ma> Recently I wrote a HTTP-server for Clisp. When sending a
  ma> POST-reply back to Netscape, sometimes Netscape insisted that it
  ma> had not seen all the data before the connection was closed.

I have also run into this problem: Netscape says "server closed
connection prematurely". The same code used to work with older
versions of CLISP; maybe something has changed with the buffering
code?

Shouldn't closing a socket automatically flush all pending unwritten
data?
  
-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden>

---

From: [email-masked] (Don Cohen)
Date: Wed, 14 Jun 2000 09:50:53 -0700 (PDT)

Martin Atzmüller
  Hi

  
  
  Comments?
  
How much data were you writing?
Also what OS?
Have you tried watching the packets?  
The fact that clisp thinks this stream is unbuffered suggests that
it thinks the stream just goes to the tcp code, so finish output is a 
noop, whereas in reality the stream goes to the tcp on the other end 
of the connection.  Therefore finish output should wait for the ack to 
come back indicating that all the data has been received.  
I wonder how easy that is.

---

From: [email-masked]
Date: Thu, 15 Jun 2000 08:03:59 +0200 (MEST)

> How much data were you writing?
Exacltly 76 bytes.

> Also what OS?
Slackware Linux, Kernel 2.2.16, glibc 2.1.2.
I also tried it on a debian system, same results.

> Have you tried watching the packets?  
no.

> come back indicating that all the data has been received.
Yes.
> I wonder how easy that is.
Me too. :)

Well, I tested it again, today, and it worked _sometimes_. Approximately 8
out of 10 trials it failed.
I tried this using Netscape 4.7 and Netscape 4.04.
A telnet got it all right, though.
I want to explore a bit further, and then I might have some sample code
(hopefully).

Well, one thing people might be able to reproduce is the following.
Newer CLISP-versions (CVS) have a #'inspect.
And this does not work in my setup, if I use the option ':frontend :http'.

For example:
(setq a "bla")
(inspect a :frontend :http)

results in the following message from Netscape:
"A network error occurred while Netscape was receiving data. (Network
Error: Connection reset by peer.)"

I looked at inspect.lisp.
The code that is responsible for that seems to be the macro
"with-html-output".
If I inserted a (sleep 1) just before (close sock), e.g. before the socket
was closed, Netscape at least displayed something.

I'm not really sure, if this is a Unix thing, or a Clisp bug, but I'd be
happy if somebody could reproduce this.

Martin