W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2000

Re: bug in HTTCP.c

From: Jens Meggers <jens@meggers.com>
Date: Tue, 8 Aug 2000 09:30:52 +0200
Message-ID: <002e01c0010a$95064250$1002a8c0@pille>
To: <jose.kahan@w3.org>
Cc: <www-lib@w3.org>

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,


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:53 UTC