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

List:       kde-core-devel
Subject:    Re: PATCH: DCOPServer hanging on non responding client.
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-01-25 21:58:06
[Download RAW message or body]

On Tuesday 23 January 2001 16:49, Matthias Ettrich wrote:
> On Wednesday 24 January 2001 00:44, Waldo Bastian wrote:
> > The following patch seems to solve this problem beyond my wildest
> > expectations.
> >
> > Cheers,
> > Waldo
>
> What danger of potential data loss does this method have?

Ok.. forget about the 16Kb I mentioned earlier. The limitting factor is the 
sendbuffer which is 64Kb by default on linux. When that fills up the client 
is effectively beyond help, (e.g. if you send 4 times 16Kb).

Ice then gets a write error (EWOULDBLOCK) and we can't recover from that 
because we don't know how much has been written. The only error handling that 
we can do is to close the connection with the client.

I have now added the following ioError() handler:

   qWarning("DCOPServer: ioError()");
    DCOPConnection* conn = clients.find( iceConn );
    if ( !conn ) {
        qWarning("DCOPServer::ioError from unknown connection.");
        return;
    }
    qWarning("DCOPServer: ioError from %s", conn->appId.data());
    IceSetShutdownNegotiation (iceConn, False);
   (void) IceCloseConnection( iceConn );

And this kills off nicely the client when its buffer fills up. The only 
possible problem I have is that it also gets called when a DCOP application 
exits. Could this cause any problems?

For the short term, this solution will prevent the dcopserver hanging on 
non-responding clients, but I'm not happy with it for the long term, because 
it makes it impossible to send data larger than 64Kb. And I don't want to go 
down in history as the one who said 64Kb ought to be enough for everyone :-)

A possible long term solution would be to implement queuing in DCOP and to 
send large messages in parts. I have no idea how we can detect that we will 
be able to write a message of a certain size though. (E.g. select tells us 
that we can write, but I don't think it specifies in any way how much we will 
be able to write.)

We might be able to implement our own IceWrite function though, it seems to 
simply write out the data to the socket with this rather wierd 
_IceTransWrite() function (Which is some obscure define (?))

Cheers,
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com

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