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 !

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

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?

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.

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 :-/

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

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 ?

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.

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".

Broadcast/multicast is out of scope.