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 Tuesday, 8 August 2000 03:31:56 UTC