This is a multi-part message in MIME format.
--------------7C020204CBADAF83FC40C812
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thiago Macieira wrote:
> 
> 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 connects
> it to QSocket::tryConnecting(). When that slot gets called, it'll fetch the
> connection lookup results and try to connect to the first (and only the
> first) of the returned values, after placing the socket in non-blocking mode.
> 
> What happens is that it expects connect() to return with failure (errno =
> EINPROGRESS). What happens is that the local connection is established
> immediately and the connection then is successful. The QSocket class never
> leaves the QSocket::Connecting state.
> 
> By the first time QSocket::sn_write() gets called, it'll see the
> QSocket::connecting state and instead call QSocket::tryConnection(). That's
> 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)
> 

I modified the patch a little bit to emit the connected signal after the
read notifier has been enabled, as in tryConnection(). However I still
don't know how d->addr can be different from 0.0.0.0.

I tested it with transconnect, and it solves the problem.

Michael.

-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul@imec.be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------
--------------7C020204CBADAF83FC40C812
Content-Type: text/plain; charset=us-ascii;
 name="qsocket.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="qsocket.diff"

Index: qsocket.cpp
===================================================================
RCS file: /home/kdecvs/kde/qt-copy/src/network/qsocket.cpp,v
retrieving revision 1.24
diff -u -3 -p -r1.24 qsocket.cpp
--- qsocket.cpp	15 Mar 2002 19:31:56 -0000	1.24
+++ qsocket.cpp	20 Jun 2002 12:52:21 -0000
@@ -359,6 +359,12 @@ void QSocket::tryConnecting()
 	if ( d->wsn )
 	    d->wsn->setEnabled( TRUE );
     }
+
+	// If we got here, the connection has been established
+	d->state = Connected;
+	if ( d->rsn )
+		d->rsn->setEnabled( TRUE );
+	emit connected();
 #endif
 }
 

--------------7C020204CBADAF83FC40C812--