[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-29 19:11:53
[Download RAW message or body]

On Monday 29 January 2001 00:06, joerg habenicht wrote:
> > Basically consisting of DCOPSend, DCOPCall and DCOPReply and
> > DCOPReplyFailed. [And the more obscure DCOPReplyWait, DCOPReplyDelayed (I
> > wonder if these are still needed btw) and DCOPFind]
>
> are some of them only for internal use ?

?? What do you mean with "internal"? They are send between the dcop-client 
and the dcop-server.

[snip]

> > A small improvement could be to let DCOPData contain the total message
> > size, so that the DCOPClient could allocate enough memory for the total
> > message so that it has to do less copying.
>
> In this case we couldn't do streaming on the DCOP level,
> but noone seems to need that anyways. so ok.

DCOP doesn't support streaming. If you want streaming you should MCOP. DCOP 
provides functionality for remote function calls.

> > It could be made somewhat more efficient if we piggybacked the DCOPAcks
> > in some cases and allowed to have more than one outstanding message. E.g.
> > each message from the dcopserver could contain a sequence number. The
> > dcopclient will put the last received sequence number in all its message
> > to the dcopserver. Whenever the dcopserver receives a message it can see
> > how many messages the client still has to process. If there are too many
> > outstanding messages it will wait for an ack from the dcopclient before
> > sending any more. The dcopclient in its turn will have to compare the
> > last sequence number it send out and the latest sequence number it
> > received. If the difference becomes too large (e.g. when it receives
> > messages like DCOPSend, but never sends messages itself) it will have to
> > send an explicit DCOPAck to tell the dcopserver that it has to keep
> > sending data.
>
> looks like IP or etherframes.
> I think the AK-window protocol is easy, but the piggyback has to
> wait. The piggyback sounds a bit more error-prone if not properly
> implemented.

We better implement it properly then.

> Is the client able to process the old DCOP message entirely, when the
> server fires a new message already ?

When the client has received a complete DCOP message he can process it.

> with this, one can rely on the messges arriving "in order".

Yes, we don't want to change the order of events.

> And secondly, do messages get lost on the way between server and client ?
> I don't think so, do they ?

No. That's the whole point of this exercise.

> > We can also mutate the sequence number in a kByte counter. Instead of
> > increasing it with 1 we increase it with the number of kByte of the
> > message size. This way the difference between the last send number and
> > the last received number reflects the kByte amount of unacknowledge data.
> > The slave would need to send DCOPAck whenever it notices that this amount
> > is larger than half the size of the maximum amount of outstanding data.
>
> do we really rely on the data arriving "in order" ?

The underlying communication channel guarantees the order.

> If so, we could use this, too. But for calculating the needed frames there
> we need a bit more CPU power, 20-30 circles. It isn't much, but I like
> ideas of lean, clean and smart protocols.

The idea is to fill the comunication channel as much as possible in order to 
reduce the need to wait for ack's as much as possible. Waiting for ack's is 
very expensive in terms of response time because it adds a full 
round-trip-delay. A few CPU cycles is nothing compared to that. 

> I think just for AK-ing the data, it's just the same.
>
> > Under typical conditions and with the maximum amount of outstanding data
> > 64Kb, we would hardly ever need to send (or wait for) a DCOPAck then.
> > (Only if we send more than 32Kb to a client without the client sending
> > anything back)
>
> ?
> I think of 64k being the max. frame length.
> so the maximum outstanding data for sending a sequence would be half the
> sequnce number, ie. 8bit sequence = 265/2 frames = 128*64kb outstanding
> max.
> please correct me being wrong.

You can't have more than 64Kb of outstanding data because you would exceed 
the buffer capacity of your communication channel. That is exactly the 
problem that we need to solve, preventing that the unprocessed data exceeds 
the buffer capacity of the communication channel. What used to happen is that 
the dcopserver blocked while waiting for the data to be processed resulting 
in a complete lockup of the desktop. I have changed this, and now the 
dcopserver doesn't block but throws away the connection when this situation 
happens. In 99.9% of the cases this situation never occurs, but it 
effectively limits the size of the data that can be send via a DCOP call to 
somewhat less than 64Kb. 

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

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