[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QSocket problem with transconnect (proxy)?
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-06-20 8:10:36
[Download RAW message or body]

On Wed, Jun 19, 2002 at 11:15:59AM +0200, Michael Goffioul wrote:
> Hi,
> 
> I found a weird behavior in QSocket but I don't know if it's a bug
> or not. I found the problem when using QSocket along with transconnect,
> a utility that redirect "connect" calls to a HTTP proxy by preloading
> a dynamic library.
> 
> The problem appeared when trying to make a connection on localhost:631.
> I traced the process inside QSocket and here's what's happening (more
> or less):
> 1) perform a host lookup
> 2) tried to connect on the first address found (127.0.0.1)
> 3) in my case the connection is established immediately, that is
>    d->socket->connect() returns true. The write socket notifier
>    is enabled.
> 4) the notifier fires an event on QSocket -> QSocket::tryConnection()
> 5) tries AGAIN to connect but this time using d->addr and d->port,
>    however d->addr == 0.0.0.0. I looked into qsocket.cpp and this is
>    the only place where d->addr is used, so I don't know if d->addr
>    can be different from 0.0.0.0, and where it might be set to something
>    different.
> 
> I found it because when you use transconnect, each connect is analyzed
> by this utility: the first address 127.0.0.1 is usually covered and
> considered as local such that no proxy is used. However the second
> one 0.0.0.0 is not covered as local address and the utility tries to
> use the proxy and just fails.

I think this is a bug in transconnect, or rather: A missing feature.

What QSocket does is to make the socket non-blocking. Then it issues
the first connect(), which immediately returns with EINPROGRESS, as
the socket is non-blocking. As the socketnotifier indicates
writability, QSocket issues a second connect() (on the same fd) ,
which (in the normal case) returns 0, indicating a connection
success.

Interesting though is that the man-page says that the 'right' way to
determine whether the connection succeeded is to use getsockopt( fd,
SOL_SOCKET, SO_ERROR, ... ) and check for the error being zero.

Simon
[prev in list] [next in list] [prev in thread] [next in thread]