Loosing signal while reading bus systems under C

[Victor Andres]

Hello,
It's a struct with 6 unsigned short and a int value, so 16 Bytes.

I think it's a smalled message, isn't it?

The data are loosing immediatley after I start the receive application.

I'm using  the system bus. How can I modify the limits value of this bus?

I have done a example test with system D-Bus in my portable device. I have 
sent 10.000 signals with just only an int 32 value and it's for aprox 11 - 
12 seconds. I think it's more than 1000 signals (with only a int value) per 
seconds.
I try the same code in my Ubuntu laptop, and I send the 10.000 signals in 
less than 1 seconds.

Regards,
Víctor Andrés


----- Original Message ----- 
From: "Alban Crequy" <alban.crequy at collabora.co.uk>
To: <dbus at lists.freedesktop.org>
Cc: "Victor Andres" <victor at cymonline.com>
Sent: Saturday, November 20, 2010 3:09 PM
Subject: Re: Loosing signal while reading bus systems under C


Le Mon, 15 Nov 2010 11:19:37 +0100,
"Victor Andres" <victor at cymonline.com> a écrit :

> Hello,
> I'm trying to use dbus to send information from one process to other,
> using low level C. The frecuency that this application send signal is
> about 1200 per seconds, and each signal is a struct of 4 or 7 basic
> datas (there are 2 different signals). I think I'm writing signal
> correctly (at less I can monitory them correctly from dbus-monitor
> utility), but when I'm reading it from the other application, I have
> some loosing data (or not received signal) randomly.

How big are your D-Bus messages in bytes? Can the data be lost
immediately after you start your applications, or only after a while?

I wonder if the receiving queue of the other application is full (127MB
by default on the system bus). In that case, dbus-daemon will not
deliver the signal.

By default (for the system bus):
      parser->limits.max_incoming_bytes = _DBUS_ONE_MEGABYTE * 127;

In /etc/dbus-1/session.conf for the session bus:
  <limit name="max_incoming_bytes">1000000000</limit>

That said, I agree that other solutions should be considered.

Regards,
Alban