From kde-core-devel  Thu Jun 20 11:29:03 2002
From: Thiago Macieira <thiagom () wanadoo ! fr>
Date: Thu, 20 Jun 2002 11:29:03 +0000
To: kde-core-devel
Subject: Re: QSocket problem with transconnect (proxy)?
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=102457280519039

Michael Goffioul wrote
>Simon Hausmann wrote:
>> 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.
>
>I don't think that's what happening. As I explained above, the first
>connect attempt establish the connection immediately, this can
>happen even if the socket is non-blocking (for example on a LAN).
>The socketnotifier being enabled, an event is fired, triggering
>QSocket::sn_write() -> QSocket::tryConnection(). The latter again
>tries to establish the connection, but the problem is that now it
>is using d->addr, which contains 0.0.0.0, it's not the same fd.
>This is the only place in the whole qsocket.cpp file where
>d->addr is used, I couldn't find any place where this might be
>set to something else. No surprise then that it contains 0.0.0.0.
>But trying to connect on 0.0.0.0 fails using transconnect.
>Don't know where's the fault, though.

I think I may have found the bug:
when you call connectToHost(), it creates a QDns to do the lookup and conne=
cts=20
it to QSocket::tryConnecting(). When that slot gets called, it'll fetch the=
=20
connection lookup results and try to connect to the first (and only the=20
first) of the returned values, after placing the socket in non-blocking mod=
e.

What happens is that it expects connect() to return with failure (errno =3D=
=20
EINPROGRESS). What happens is that the local connection is established=20
immediately and the connection then is successful. The QSocket class never=
=20
leaves the QSocket::Connecting state.

By the first time QSocket::sn_write() gets called, it'll see the=20
QSocket::connecting state and instead call QSocket::tryConnection(). That's=
=20
an error, because:
a) the socket is already connected
b) d->addr has never got set
    (actually, I couldn't find where it is ever set)

The solution is this:
Index: qsocket.cpp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/kde/qt-copy/src/network/qsocket.cpp,v
retrieving revision 1.24
diff -u -3 -p -r1.24 qsocket.cpp
=2D-- qsocket.cpp 2002/03/15 19:31:56     1.24
+++ qsocket.cpp 2002/06/20 11:28:09
@@ -358,6 +358,13 @@ void QSocket::tryConnecting()
        // The socket write notifier will fire when the connection succeeds
        if ( d->wsn )
            d->wsn->setEnabled( TRUE );
+
+       // Actually, the connection has already succeeded (returned TRUE=20
above)
+       // -thiago
+       d->state =3D Connected;
+       emit connected();
+       if ( d->rsn )
+           d->rsn->setEnabled( TRUE );
     }
 #endif
 }

Note: I haven't tested that

Note 2: I hope you're not developing a KDE application

=2D-=20
  Thiago Macieira - UFOT Registry number: 1001
 thiagom@mail.com
   ICQ UIN: 1967141  PGP: will create new keys. Erase the old ones!
     Registered Linux user #65028