[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:       joerg habenicht <j.habenicht () stud ! uni-hannover ! de>
Date:       2001-01-29 8:06:31
[Download RAW message or body]

On Sat, 27 Jan 2001, Waldo Bastian wrote:

> Well, Ice already provides a sort of transport layer. It just doesn't behave 
> like we would like. We currently have something like:
> 
> DCOP -> ICE -> unix socket (or possibly tcp)
> 
> If we want to fold in a transport layer, we would have to do that between 
> DCOP and ICE, because we don't have proper access to the ICE -> unix socket 
> part.
> 
> DCOP sends a limited number of ICE messages:
> 
> 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 ?

> 
> The ICE message header contains, among others, the length of the message 
> and a 'opcode' that defines the type of message (DCOPSend, DCOPCall, etc.)
> 
> The dcopserver is a central server, and has 1:1 links with all the clients. 
> The only things we need to do is to make sure that 
> a) we send messages that fit completely in the output buffer 
> b) the client has read the previous message before we send another one.
> 
> To satisfy a) the dcopserver needs to disassemble messages that are to big in 
> parts and the clients need to reassemble them, for b) the client needs to 
> send an acknowledgement to the dcopserver that it has received the message or 
> message part.
> 
> A simple scenario could work like this:
> 
> Message that is smaller than outbut buffer:
> a) DCOPServer sends message [DCOPReply, DCOPCall, DCOPSend etc.] to client
> b) DCOPServer waits for DCOPAck
> c) DCOPClient receives message.
> d) DCOPClient sends DCOPAck.

yes, I thought of something like this.

> 
> Message that is larger than output buffer:
> a) DCOPServer sends 1st part of message in DCOPData message to client
> b) DCOPServer waits for DCOPAck
> c) DCOPClient receives messages
> d) DCOPClient send DCOPAck
> e) DCOPServer repeats for part 2...n-1
> f) DCOPServer sends last part of message in DCOPReply, DCOPCall etc. to 
> client.
> g) DCOPClient receives messages and reassembles the total message.

would be sufficient for a first implementation.
In fact I think this scenario is just .1% of all transmission cases.


> 
> 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.

> 
> 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.

Is the client able to process the old DCOP message entirely, when the
server fires a new message already ?
with this, one can rely on the messges arriving "in order".

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


> 
> The advantage of this last method is that we have less messages going back 
> and forth. Many messages is bad for perfromance, because each message needs 
> to wake up the process causing context switches and all that.

would be easier, if the server sets up a shared memory segment and tells
the client to receive the data over there, readonly. The Client would have
to tell the server, that the segment isn't needed anymore or destroy it
itself. That way there could be more than 64kb transmitted with only a
single wakeup call.
just a thougt.

well, thinking some more of this, it would mean, that at start time of the
client, there already has to be a shm segment of some bytes between client
and server. that wouldn't work out. :-\

> 
> 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" ?
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.
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.

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


cu,
Joerg

-- 
THE full automatic planets host
:-)                            http://www.planetsserver.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GE/CS/IT d- s+:- a- C++ ULS+++>++++ P++ L+++>++++$ 
E W++ N+(+++) !o? !K? w--(---) !O(++) !M !PS !PE !Y? PGP+ 
t-- 5-- X-- tv+ b++ DI+() D-(+) G>+ e++>+++ h+(*) r% y? UF
------END GEEK CODE BLOCK------
"Man sollte das Leben nicht so ernst nehmen, 
 Du überlebt es sowieso nicht."

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