- From: Tim Serong <tim.serong@conceiva.com>
- Date: Fri, 25 Jul 2003 10:39:13 +1000
- To: <www-lib@w3.org>
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