[redirecting to haskell-cafe]
Hi Jens, I think I have it.
>I think I found an issue with the HTTP.hs library when
>making a short-lived non-persistent connection to a server
>from a slower machine (i486). I can also reproduce it by
>running my program with strace or ltrace on a faster machine
>(PIII).
Last two meaningful recv call:
>recvfrom(3, 0x500a3878, 1000, 0, 0x500a3c68) = 555
>getpeername(3, 0x500a3c8c, 0x500a3ca4, 0x080dfda0, 1) = 0
>recvfrom(3, 0x500a2008, 1000, 0, 0x500a23f8) = 0
>getpeername(3, 0x500a241c, 0x500a2434, 0x080dfda0, 1) = 0
After no data is received the sending part of the TCP stream is closed:
>shutdown(3, 1, 0x0805b85f, 0x080e018c, 1) = 0
Being polite, the library ensures that all incoming data has been consumed,
forgetting for a moment that the incoming stream has already closed:
>recvfrom(3, 0x500a2440, 1000, 0, 0x500a2830) = 0
>getpeername(3, 0x500a2854, 0x500a286c, 0x080e018c, 1) = -1
The "recvfrom" seems fine, the "getpeername" call comes from the definition
of Network.Socket.recvFrom, which features:
flg <- sIsConnected sock
-- For at least one implementation (WinSock 2), recvfrom() ignores
-- filling in the sockaddr for connected TCP sockets. Cope with
-- this by using getPeerName instead.
sockaddr <-
if flg then
getPeerName sock
else
peekSockAddr ptr_addr
...Leading to the error in question:
>strerror(107) = "Transport endpoint is
>not connec"...
The answer I guess is to alter all calls to 'recvFrom' to 'recv' calls
(done), or replace socket reference with ConnClosed at the first sign of a
closed socket. Unfortunately the second will have to wait, but the first is
implemented and available in the latest version:
http://homepages.paradise.net.nz/warrickg/haskell/http
Warrick.
PS - nice trace.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
