[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Paparazzi bus MQ wrapper

From: Gerard Toonstra
Subject: Re: [Paparazzi-devel] Paparazzi bus MQ wrapper
Date: Wed, 28 Jan 2015 14:12:55 -0300

Alexandre, you're right.

Felix, at the moment it's a string like ivy. It's possible to work with the message definition at the bus level, 
but if I understand this correctly, you'd get binary dependency and requirements to recompile the bus if a 
message definition changes (switching branches?). So it's mostly about having alternatives for changing the
underlying transport mechanism and interfacing with other systems.

The reason for adding the sender parameter is how I saw that the regex's were used in general. Usually there's
no filter, so the app doesn't care about the sender, but in some regex's you get a "1" for the ac_id or a 
"ground" at the start. The regex is pretty difficult to parse and make sense of, so I made this an explicit
function of the API instead.

I imagine that an API call for bindings on the bus would then eventually look like this, without regex's:

bind_id PprzBusBind( MsgCallback callback, const char *msg_name, const char *sender );

An option is probably also needed to split data arguments or not, because telemetry messages split the 
data arguments into an arg list before returning, whereas the gcs and server just return the msg_name+data
as one single line.



On Wed, Jan 28, 2015 at 11:42 AM, Felix Ruess <address@hidden> wrote:

I would be in favour of trying to create some sort of abstract pprzbus that can have multiple backends...
The difficult part is really finding an appropriate API for this and what paradigm it should use.
i.e. message based pub/sub or something like ivy?

Right now you are using redis in basically the same way as Ivy, the pprzbus layer has no idea about the message definitions.
Meaning you also end up with just string representations of the message in redis (just like on the Ivy bus).
I'm not really convinced that this makes that much sense in the end.

I don't quite understand the addition of a paramter to filter on sender. Why did you add that?

Cheers, Felix

On Wed, Jan 28, 2015 at 2:03 PM, Alexandre Bustico <address@hidden> wrote:
Le 28/01/2015 13:09, Gerard Toonstra a écrit :
  * The regex is executed against each received message in each process, which eventually becomes CPU
    intensive and laggy.

On this specific point, it's not. regexp filtering is done on the emitter side, just once time by regexp : even if
several agents bind the same regexp (exactly the same, it's implemented as a hashtable, key is regexp,
value is list of agents which bein the regexp). only filtered results are sent over network.


Paparazzi-devel mailing list

Paparazzi-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]