Messages order and real time behaviour

[fabien.vitiello]

Hi,

I read the really interesting paper concerning "Robust and Efficient Communication for Real-Time Multi-Process Robot Sotware".

The introduction part tells us "The library, called Ach, provides a message-bus or a publish-subscribe communication [...] but with the distinguishing feature of favoring newer data over old."

In a project I have, we are looking for quietly the same kind of IPC as ACH which is capable of real time behaviour and which doesn't suffer from HOL blocking but not only with the distinguishing feature of favoring newer data over old but also with a capacity to keep the order of all messages received.

This feature is essential for us to keep an history of what happened in the past.

Thus, I was wondering if we could use ACH in order to keep the order of messages?

And how the real time behaviour is ensured (using priorities?) ? 

Could we attribute priorities to some type of messages ? 

As an example, M1 message type is urgent and when appears a M1 message it will be examined before all other M2 messages type (which are standard messages).

Fabien

[Neil Dantam]

> Thus, I was wondering if we could use ACH in order to keep the order of
> messages?

Yes, Ach does preserve message order / provide in-order delivery.

> And how the real time behaviour is ensured (using priorities?) ?
>
> Could we attribute priorities to some type of messages ?

"Priorities" refers to process priorities rather than message
priorities. If two processes are attempting to access the same
channel, the process with the higher priority will run and receive
the data first. This is in contrast to a P2P socket approach where
a sender with multiple receivers may not account for the receivers'
priorities in order to first send data to the highest priority
receiver.

Cheers,
-ntd

On 03/28/2014 09:33 AM, fabien.vitiello wrote:
> Hi,
>
> I read the really interesting paper concerning "Robust and Efficient
> Communication for Real-Time Multi-Process Robot Sotware".
>
> The introduction part tells us "The library, called Ach, provides a
> message-bus or a publish-subscribe communication [...] but with the
> distinguishing feature of favoring newer data over old."
>
> In a project I have, we are looking for quietly the same kind of IPC as
> ACH which is capable of real time behaviour and which doesn't suffer
> from HOL blocking but not only with the distinguishing feature of

> favoring newer data over old but also with _a capacity to keep the order
> of all messages received_.

> This feature is essential for us to keep an history of what happened in
> the past.
> Thus, I was wondering if we could use ACH in order to keep the order of
> messages?
>
> And how the real time behaviour is ensured (using priorities?) ?
>
> Could we attribute priorities to some type of messages ?
> As an example, M1 message type is urgent and when appears a M1 message
> it will be examined before all other M2 messages type (which are
> standard messages).
>
> Fabien
>

> --
> You received this message because you are subscribed to the Google
> Groups "ach-help" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ach-help+u...@googlegroups.com
> <mailto:ach-help+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[climbfo...@gmail.com]

Le vendredi 28 mars 2014 21:31:04 UTC+1, Neil Dantam a écrit :
>
> "Priorities" refers to process priorities rather than message
>
> priorities. If two processes are attempting to access the same
>
> channel, the process with the higher priority will run and receive
>
> the data first. This is in contrast to a P2P socket approach where
>
> a sender with multiple receivers may not account for the receivers'
>
> priorities in order to first send data to the highest priority
>
> receiver.
>

Does the realtime term used in the paper just means low-latency ? Is there a mechanism inside ACH (except process priorities) which allow realtime IPC ?