Subject: Re: [clisp-list] socket-shutdown and broken http inspect server o n win32

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu May 16 09:01:05 2002

Hi,

>another thing is that the page you mention suggest Ws2_32.lib while we
>are using wsock32.lib.
>could you please check whether this matters?
Thanks to the attentive reader!
However it doesn't change anything in the observed behaviour.

2. MSDN doesn't seem to document wsock32's closesocket, only the new one is mentioned.
I mean I could find any documentation whether this matters.

3. from the winsock2 architecture picture I figured out that ws3_32 is the correct thing to use, since clisp includes winsock2.h. But nothing changed.
Why does CLISP compiled and link with wsock32.lib? Mistery. Maybe winsock2.h is not really needed, but who cares?

My suspicion is that the timeout until FD_CLOSE is sent internally by the TCP/IP stack is extremely small ("implementation dependent"), thus it's sent only slightly after closesocket() is invoked, and the remote client gets it too early???

Should we add setsockopt(linger,1 minute)? 10 minutes?
Then, passing the :ABORT argument of CLOSE to low_socket_close would begin to make sense.

BTW, I observe the same behaviour on MS-Woes98.

BTW, you have that dysfunctional experimental #+keep-alive-line hack in inspector.lisp left in CVS r1.15. Please remove.

>> shutdown(SD_BOTH) is no help
>> shutdown(SD_SEND) slightly helps: i.e. a local web browser doesn't get
>> an error anymore, but a remote connection only gets part of the output
>this is weird since the spec appears to say that SD_BOTH ==> SD_SEND

My *supposition* (i.e. attempt at logical explanation) is that the open input channel is also sent a shutdown signal, which is received much faster by the client than the remaining output data. So the client translates as "connection reset by peer" or some such.
WINSOCK Error 10054 Connection reset by peer
The error about reset connection also appears when I shutdown(SD_RECEIVE) before shutdown(SD_SEND).

What makes me wonder is this text:
"If SO_LINGER is set with a nonzero time-out interval on a blocking socket, the closesocket call blocks on a blocking socket until the remaining data has been sent or until the time-out expires. This is called a graceful disconnect. If the time-out expires before all data has been sent, the Windows Sockets implementation terminates the connection before closesocket returns."
I read it as: after timeout, the connection is reset *not* gracefully.

I believe it's time to peek at what other SW does (e.g. python, some Scheme, whatever one has)...

	Jorg Hohle

---

From: Sam Steingold <[email-masked]>
Date: Thu May 16 12:33:02 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] socket-shutdown and broken http inspect server o n win32"
> * Sent on Thu, 16 May 2002 18:00:45 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> My *supposition* (i.e. attempt at logical explanation) is that the

don't look for logic where you did not put it yourself!

> open input channel is also sent a shutdown signal, which is received
> much faster by the client than the remaining output data. So the
> client translates as "connection reset by peer" or some such.  WINSOCK
> Error 10054 Connection reset by peer The error about reset connection
> also appears when I shutdown(SD_RECEIVE) before shutdown(SD_SEND).

please try the appended patch.

> Scheme, whatever one has)...

can you do it?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Whom computers would destroy, they must first drive mad.

--- stream.d.~1.272.~	Tue May  7 12:24:34 2002
+++ stream.d	Thu May 16 12:36:47 2002
@@ -14074,7 +14074,10 @@
 local void low_close_socket (object stream, object handle) {
   begin_system_call();
  #ifdef WIN32_NATIVE
-  if (shutdown(TheSocket(handle),SHUT_RDWR)) { SOCK_error(); }
+  # this has to be done in this particular order and should not be
+  # replaced with a single SHUT_RDWR due to the Woe32 peculiarities
+  if (shutdown(TheSocket(handle),SD_SEND))    { SOCK_error(); }
+  if (shutdown(TheSocket(handle),SD_RECEIVE)) { SOCK_error(); }
  #endif
   if (!( closesocket(TheSocket(handle)) ==0)) { SOCK_error(); }
   end_system_call();

---

From: Sam Steingold <[email-masked]>
Date: Thu May 16 13:07:06 2002

> BTW, you have that dysfunctional experimental #+keep-alive-line hack
> in inspector.lisp left in CVS r1.15. Please remove.

you want CLISP to honor keep-alive or discard it?
what works better?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
If You Want Breakfast In Bed, Sleep In the Kitchen.

---

From: Arseny Slobodjuck <[email-masked]>
Date: Sat May 18 02:09:02 2002

Hello Joerg-Cyril,

Friday, May 17, 2002, 2:00:45 AM, you wrote:

Joerg-Cyril> My  suspicion  is that the timeout until FD_CLOSE is sent
Joerg-Cyril> internally   by  the  TCP/IP  stack  is  extremely  small
Joerg-Cyril> ("implementation   dependent"),   thus   it's  sent  only
Joerg-Cyril> slightly  after  closesocket() is invoked, and the remote
Joerg-Cyril> client gets it too early???

Joerg-Cyril> Should  we  add  setsockopt(linger,1 minute)? 10 minutes?
Joerg-Cyril> Then,   passing   the   :ABORT   argument   of  CLOSE  to
Joerg-Cyril> low_socket_close would begin to make sense.

Hold on, jedi knights are on the way (I'm reading my winsock book) !
I already found that call to WSACleanup() not exists in sources.
It's already something.

-- 
Best regards,
 Arseny                            mailto:[email-masked]