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 Monday, 7 August 2000 11:47:30 UTC