[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-28 6:58:09
[Download RAW message or body]

On Friday 26 January 2001 07:33, joerg habenicht wrote:
> > Well, this leads to some sort of transport protocol,
> > streaming the data in 64k chunks.
> > Shouldn't be that hard.
>
> I dig into a bit further, and set up 2 versions of a transport frame for
> discussion.
> The transport layer is designed to have as little impact on througput and
> CPU as possible to get the initial idea of DCOP.
> Therefore it should add as little overhead as possible for transmitting
> small memory chunks like 2 Bytes.
> A checksum is skipped, because with a local transport within the computer
> there shouldn't be data errors
> and on network transport the tcp/udp layer should handle this.
>
>
> the first version of the transport layer adds 3 bytes header to the data
> with
> the length of data 16bit,
> a boolean "more data follows" 1bit,
> and 7bits reserved.
> Within the 7 bits there could be 4 bits used for the protocol version for
> backwards compatibility.
>
> [len of data, 16bit | more data ? 1 bit | 3 bit reserved | version 4 bit |
> data ]
>
>
> the second approach is to post the total length with the data and the
> number of the frame. the length of the data in the data part could be
> calculated on the receiving side. would be like:
>
> [total len of data, 64 bit | frame number 64-16=48bit | data ]
> This one adds 14 Bytes a header.
>
>
>
> I definetly vote the first one, because of the smaller size of header.
> Additionally one could implement streaming with the first version.
> The drawbacks are:
> no frame number. I rely on receiving the data "in order" and no dataloss
> of frames. (For this, there could be 8-16 bits for a serial number added.)
> no end mark. The client doesn't know, when the data ends. A 1 bit field
> has to be added.
>
>
> To get the transport protocol right, I need to know further:
> Is streaming a "nice to have" or definitly not needed ?
> Is DCOP a method for transporting >2^64byte data or is it "enough for
> everyone" ? ;-)
>
> please give me some comments.

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]

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.

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.

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.

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.

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.

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.

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)

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

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