[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:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-01-26 16:59:11
[Download RAW message or body]

   Hi!

On Fri, Jan 26, 2001 at 09:04:29AM +0100, joerg habenicht wrote:
> On Thu, 25 Jan 2001, Waldo Bastian wrote:
> 
> > 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.)
> 
> Well, this leads to some sort of transport protocol,
> streaming the data in 64k chunks.
> Shouldn't be that hard.

Just to mention one thing: it might be an idea to do DCOP-over-libmcop instead
of DCOP-over-libICE, and this for a number of reasons:

 * it makes us independant from third-party code (i.e. libICE is something
   we can't adapt to our needs)
 * it unifies the protocols KDE uses
 * the MCOP protocol/io-management code is already written
 * further optimizations (like using shared memory for transmitting large
   messages) will impact both implementations in the future
 * security mechanisms, like encryption and secure identification will only
   have to be implemented once

I had this idea for quite some time already, and it shouldn't be too hard to
get that running, as DCOP doesn't require too much from the underlying
transport thingy.

Of course the number of lines of code of libmcop (and that way the complexity)
might be an argument against it (although it's hardly more than libICE, that
is, bogo-bench: libICE: 7521 LOC, libmcop: 9657 LOC).

   Cu.. Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

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

Configure | About | News | Add a list | Sponsored by KoreLogic