HTTP.hs with slow execution

Warrick Gray
Sun, 09 Jun 2002 03:02:55 +1200

[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

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
		   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:


PS - nice trace.

Get your FREE download of MSN Explorer at