connect() is called infinitely on Win32 for hosts that are down (was: Re: bug in HTTCP.c)

Greetings,

Can anyone tell me if there is a patch available to fix the issue
described below?  I'm having the same problem using the current release
of libwww.  If there's not, I'll just try doing what Jose described...

Thanks,

Tim Serong
-- 
tim.serong@conceiva.com
http://www.conceiva.com

> -----Original Message-----
> From: "Jens Meggers" <jens@meggers.com>
> To: <jose.kahan@w3.org>
> Cc: <www-lib@w3.org>
> Date: Tue, 8 Aug 2000 09:30:52 +0200
> Subject: Re: bug in HTTCP.c
> 
> Jose,
> 
> You are right, it is better to use the error codes given by
WSAAsyncSelect()
> to fix the problem. As soon as I have some time left, I will have a
look on
> it, how to fix it in the best way.
> 
> Best Regards,
> 
> Jens
> 
> ----- Original Message -----
> From: <jose.kahan@w3.org>
> To: "Jens Meggers" <jens@meggers.com>
> Cc: <www-lib@w3.org>
> Sent: Monday, August 07, 2000 5:47 PM
> Subject: Re: bug in HTTCP.c
> 
> 
> > Hello Jens,
> >
> > I was able to reproduce the bug you signaled. It doesn't occur under
Unix.
> >
> > Your patch may work OK in some cases. However, to make it more
robust, I
> > think we should use the system error codes so that we can really
detect
> > when there was an error in the connection.
> >
> > The problem seems to be in trying to do succesive connects() to find
out
> > if there was an error. While this works under Unix, it doesn't work
well
> > under Windows.
> >
> > Further reading of the WinSock API reveals that when using
WSAAsyncSelect,
> > the errors are given in the lParam of the callback. We can get these
> > error codes using the WSAGETSELECTERROR macro.
> >
> > I did a small test and changed the async window event handler in
> HTEvtLst.c
> > so that the error returned by WSAGETSELECTERROR would be copied
using
> > WSASetLastError. I then changed the HTDoConnect() so that is
socerrno
> > is set, I won't call connect, but set the status to SOCKET_ERROR
right
> away.
> >
> > I was then able to catch the errors that you describe.
> >
> > I'm not sure if using WSASetLastError() is the best way to catch the
> error.
> > According to the doc, the WSASet/GetLastError() only indicate the
last
> > socket error in the thread where we're calling them.
> >
> > We could also change the HTEvent_dispatcher function and pass the
lwparam
> as
> > a parameter.
> >
> > What do you think? I'm not sure what's the best way to proceed now.
> >
> > Jens, do you have some time to work on this?
> >
> > Thanks,
> >
> > -Jose
> >
> > In our previous episode, Jens Meggers said:
> > >
> > > When HTDoConnect() enters the state TCP_NEED_CONNECT, it starts
> connect(). On Win32, the results is always WSA_WOULDBLOCK because the
TCP
> connection is not initiated immediatly. The event system simply calls
that
> code portion again after receiving a FD_CONNECT event. Thus, the
conenct()
> is called again and again, always returning WSA_WOULDBLOCK. It seems
that
> the retry-counter of HTHost.c provides the right solution to stop
connection
> retries after some time, however the counter seems not to be used and
is not
> set up.
> >

Received on Thursday, 24 July 2003 20:35:36 UTC