Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000006Taste[All Projects] Generalpublic2010-08-05 08:262018-07-10 12:01
Assigned Tomaxime 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version

Broadcast/Multicast feature


Rovsing asked for the possibility to have multicast or broadcast in the
code we generate.

In practice it means giving the possibility to connect one RI to several
PIs and when the user calls the RI, the machinery would be responsible for
putting the message in each PI's thread message queue.

Do you see any problem with doing this?
(AADL semantics, system analysis, ...)


TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0000789closedmaxime 

Support multiple fan-out


-  Notes
2010-10-29 14:55

To keep track of comments about this bug, I propose to continue the discussion here. Especially because I don't remember why we didn't implement this feature. As long as I remembered, Jerome had a good rationale for not implemeting this. But I don't really remember the reason.

Else, if there is no blocking point, we can go ahead and implement that !

hugues (administrator)
2011-01-12 12:09

There is no problem to implement it, we did during ASSERT, check the MPC example:
we connected one port of a process (sender) to two remote processes using ethernet
this result in N messages being sent. The example exists only for Ada, perhaps because we never tried it with C, I do not know whether Ocarina has the required machinery generated in this case. So you may first try with this example

true multicast (IP multicast) should be transparent, simply registering N nodes to the same multicast group

for other, we would have to send N messages

you'll run into some issues with scheduling analysis, since you'll have to make it explicit that you send N messages (e.g. with MARTE) or with cheddar (more tricky I think). Also, it breaks many hypothesis used by these tools.

But for the AADL and PolyORB-HI/Ada, the support is already there

maxime (administrator)
2011-12-06 08:46

When you say:

"you'll run into some issues with scheduling analysis, since you'll have to make it explicit that you send N messages (e.g. with MARTE) or with cheddar (more tricky I think). Also, it breaks many hypothesis used by these tools."

What do you mean?
At the moment, users (provided interfaces) are allowed to call several sporadic required interfaces during an activation.

Don't analysis tools support that ? Do they expect only one RI call per activation?

maxime (administrator)
2011-12-06 08:50

Julien> "how do we provide support for such a functionality ?"

It requires a lot of work in buildsupport and some graphical support in TASTE-IV.

Unless there is an immediate need, I propose to postpone the implementation.

2011-12-06 09:44

Jerome, I know that PolyORB already support that. But I taslk in terms of TASTE support. As Maxime said, we need to change buildsupport wrappers and TASTE-IV representation so on our side, it would require a big effort.

So, indeed, it may break assumptions made by Cheddar/Marwhin/MAST. But in that case, we could also envisage a modification of these tools and ask for a support in Cheddar/Marwhin, especially since Ellidiss also support these tools.

And finally, we can postpone the implementation of such a functionality but I think we could plan it very soon. As far as I remember, it was asked by some projects (Andread already asked for such a support) and it is required by SOIS. So, having such a functionality would really make sense and from a user point-of-view, this is probably one in the top priority :-/

hugues (administrator)
2011-12-06 10:56

As I wrote, I'm not sure MARTE properly support multiple RI, I think its computational model just supports one, but I may be wrong

In any case, I agree that if there is an agreement to support this, we must make sure all analysis tools are capable of handling it correctly. but this is business as usual

2011-12-06 14:22

Maybe I misunderstood your comment but why do we care about MARTE ? As far as I know, we don't have any connection with this language or maybe I missed something ?

hugues (administrator)
2011-12-06 14:35

Sorry, I meant MAST, a name collision in my head. I'm not sure MAST supports this. Last time I looked at their transaction model, it was not obvious this was possible.

2011-12-06 16:03

I don't know either. However, considering either Cheddar or MAST, there are a lot of things that would need to be reorganized regarding the way we interface our models with this validation/verification tools. At that time, it is clear that it is not an objective to provide accurate metrics and/or results and it shall be considered as "proof of concept".

maxime (administrator)
2016-10-15 19:25

Broadcast/multicast is out of scope.

- Issue History
Date Modified Username Field Change
2010-08-05 08:26 user2 New Issue
2010-09-14 10:39 ttsiodras Severity

minor => feature

2010-10-29 14:55 user2 Note Added: 0000060
2011-01-12 10:29 maxime Summary

Request for feature to be reviewed by the development team => Broadcast/Multicast feature

2011-01-12 12:09 hugues Note Added: 0000232
2011-12-06 08:46 maxime Note Added: 0001411
2011-12-06 08:50 maxime Note Added: 0001413
2011-12-06 09:44 user2 Note Added: 0001417
2011-12-06 10:56 hugues Note Added: 0001420
2011-12-06 14:22 user2 Note Added: 0001421
2011-12-06 14:35 hugues Note Added: 0001423
2011-12-06 16:03 user2 Note Added: 0001424
2016-10-15 19:25 maxime Note Added: 0002719
2016-10-15 19:25 maxime Status

new => closed

2016-10-15 19:25 maxime Assigned To

=> maxime

2016-10-15 19:25 maxime Resolution

open => won't fix

2018-07-10 11:58 maxime Reporter

user2 => maxime

2018-07-10 12:01 maxime Relationship added

has duplicate 0000789

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker