Well, here's my patch for this, in case anybody is interested. It
should only be considered a workaround, IMO.
Just joined the list a few minutes ago. I searched the archives a bit
earlier today, and found a thread a few weeks ago about SOCK5 support
on Windows. I use cygwin, and I'm having similar problems.
The first download uses curl_easy_perform, and works fine. Subsequent
downloads use curl_multi_perform, and fail. When setting
CURLOPT_VERBOSE to 1, I get messages like:
* About to connect() to proxy.roc.crcnet1.com port 1080
* Trying 192.168.0.10... * Send failure: Transport endpoint is not
* Unable to send initial SOCKS5 request
* Closing connection #0
While tooling through the libcurl code trying to get an understanding
of the problem (and possibly fix it), I added a extra infof() call
after singleipconnect, and this actually made several of the subsequent
downloads with curl_multi_perform() succeed. Assumedly, this is
related to someone previously noting that adding a call to sleep() made
things work better.
Any thoughts on how I can get this to work? The original poster's code
for fixing this bug wasn't included in the message below and I couldn't
find it in the archives, so maybe there's something I'm missing?
On Wed, 26 Oct 2005, Shmulik Regev wrote:
>> At what point does it fail and
this error back, you know?
> The problem starts at sendf.c:251
> bytes_written = (ssize_t)swrite(sockfd,
> this fails and return -1 for bytes_written
and WSAENOTCONN as the error.
Gosh. According to this page I found on microsoft.com that
returned if "The socket is not connected". It would then indicate that
is a problem in the connect code that makes libcurl proceed before it
that the socket is truly connected.
What speaks against that theory, is the fact that we _never_ see
for any other case and if it would be that stupid I can't see why we
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
it can't it will blatantly fail.
> What is the difference between the
implementation and the normal
> operation as far as socket handling is
The difference is simply that the SOCKS code is not written to
with the fact that Curl_write() might return an error in cases where
writing would block.
> How come there are no such errors with
normal HTTP activities?
Because that code _is_ written to take such considerations into
SOCKS is rarely used, and thus the libcurl code for it is poorly
and written. There are no test cases for SOCKS so changing it is
error prone (unless you have an actual socks proxy to test against,
which I do
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
TCP/IP stack flaw more than anything else.