[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-26 15:33:54
[Download RAW message or body]

On Fri, 26 Jan 2001, 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.

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

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