[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:       aleXXX <alexander.neundorf () rz ! tu-ilmenau ! de>
Date:       2001-01-26 16:02:26
[Download RAW message or body]

On Friday 26 January 2001 16:33, joerg habenicht wrote:
>
>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.
>cu,
>Joerg

Although I don't know that much about DCOP, I'd like to mention two things.

Would apps compiled and linked with the current DCOP still work with this one 
? If not, it has to wait until KDE 3.

I think adding 4 bytes would be better than adding 3 bytes (for processing, 
speed, portability), then 3 bytes could be used for the size (gives 16 MB 
size)

Bye
Alex

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