cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Socks5 works on Linux but not on Windows?

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 26 Oct 2005 09:55:05 +0200 (CEST)

On Wed, 26 Oct 2005, Shmulik Regev wrote:

>> At what point does it fail and report this error back, you know?

> The problem starts at sendf.c:251
> bytes_written = (ssize_t)swrite(sockfd, mem, len);
> this fails and return -1 for bytes_written and WSAENOTCONN as the error.

Gosh. According to this page[1] I found on microsoft.com that error would be
returned if "The socket is not connected". It would then indicate that there
is a problem in the connect code that makes libcurl proceed before it knows
that the socket is truly connected.

What speaks against that theory, is the fact that we _never_ see this error
for any other case and if it would be that stupid I can't see why we wouldn't
see this error happen all the time.

I fear we have a much more obscure and less obvious problem here.

>> The socks code is not in a perfect state. For example it always assume that
>> it can send data without blocking, as if it can't it will blatantly fail.

> What is the difference between the socks implementation and the normal
> operation as far as socket handling is concerned?

The difference is simply that the SOCKS code is not written to nicely deal
with the fact that Curl_write() might return an error in cases where the
writing would block.

> How come there are no such errors with normal HTTP activities?

Because that code _is_ written to take such considerations into account.

SOCKS is rarely used, and thus the libcurl code for it is poorly maintained
and written. There are no test cases for SOCKS so changing it is hazardous and
error prone (unless you have an actual socks proxy to test against, which I do
not).

I welcome fixes that improve this situation.

> Just for the sake of it I've added the following sleep call prior to sending
> any data. Guess what? It works.

...

> I hate the code above but I'll continue running with it enabled for a while
> and see whether the problem disappears.

If that hack works as a fix, I would say that it feels more like a Microsoft
TCP/IP stack flaw more than anything else.

[1] =
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50lrfsend.asp

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2005-10-26