[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-30 8:30:45
[Download RAW message or body]

On Mon, 29 Jan 2001, Waldo Bastian wrote:

> On Monday 29 January 2001 00:06, joerg habenicht wrote:
> >
> > 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.

by "internal" i meant messages to be sent only between the transport
protocol layers and not the above laying users.


> 
> [snip]
> 
> 
> > 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.

well, I wanted to know, if the client can be interrupted by a second
message while processing the first one.

> 
> > with this, one can rely on the messges arriving "in order".
> 
> Yes, we don't want to change the order of events.

I don't want to change them, too.
But I wanted to know, whether my computer thinks in a different way and
changes the packets being sent.
(but it doesn't seem to be)


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

(see above)

> 
> > do we really rely on the data arriving "in order" ?
> 
> The underlying communication channel guarantees the order.

aaahhh :-)

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


yes, but we could achive that by sending frame sequence numbers, too.

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

Well, I must have been unclear about this.
With "outstanding data" I meant that part, which had not been send to the
client. I'm totally aware of the 64kb restriction, that's why I send
those mails at all.

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


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]