From kde-core-devel Tue Jan 30 08:30:45 2001 From: joerg habenicht Date: Tue, 30 Jan 2001 08:30:45 +0000 To: kde-core-devel Subject: Re: PATCH: DCOPServer hanging on non responding client. X-MARC-Message: https://marc.info/?l=kde-core-devel&m=98084358608037 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."