[riot-devel] ns3 question about global variable in RIOT

Emmanuel Baccelli Emmanuel.Baccelli at inria.fr
Tue Mar 4 12:12:46 CET 2014

Hi Daniel,
I think what you suggest makes sense. RIOT and ns3 are living projects, so
will evolve and it is not reasonable to fix one version of any to achieve
the port. Fortunately, the core of RIOT and of ns3 should be stable enough
for it to be worth it to design the thin layers-based middleware you
propose. Let's refine this idea, I think this is the right direction.

On Fri, Feb 28, 2014 at 2:36 PM, Daniel Camara <danielcamara at gmail.com>wrote:

>  Even though I have a close relation with the ns-3 community, and I have
> no information whatsoever, on changes that could affect the adaptation, I
> can't guarantee this will not happen in the future.  The only way to be
> fully independent of changes would be to fix a version and go with that for
> ever, and NO, I don't think it is a good idea.
>  The other way to be independent is to create a thin specific control
> layer, with a generic interface.  If something change in any one of the
> sides (RIOT is also  a living project, things will change for sure in the
> future) just the thin implementation need to be changed, the rest will stay
> the same.
>   As I understand the adaptation work should be done is as it was a
> Middleware between RIOT and ns-3. For RIOT ns-3 will be like a new
> architecture, a new sensor where it will be running and for ns-3, RIOT will
> be just a new kind of node, one should be as blind about the behavior of
> the other as possible. Something like:
> +-------------------------------------------------------+
> |            Standard RIOT distribution                 |
> +-------------------------------------------------------+
> O         Generic API RIOT/Middleware API               |
> u       -  All the required primitives e.g.:            |
> r          get_time, send/receive packets,              |
>           request scheduling, wakeup...                 |
> M          This is the part that REALLY                 |
> i           knows how to talk to RIOT                   |
> d-------------------------------------------------------+
> d               Adaptation Middleware                   |
> l            (Greatest part of the work)                |
> e           Where we will really connect                |
> w       the "wires" and provide, for example,           |
> a      the implementation of the shared memory          |
> r            and semaphores control etc...              |
> e-------------------------------------------------------+
>            Generic API ns-3/Middleware API              |
> i             Similar to the previous                   |
> m          This is the part that REALLY                 |
> p            knows how to talk to ns-3                  |
> l                                                       |
> +-------------------------------------------------------+
> |            Standard ns-3 distribution                 |
> +-------------------------------------------------------+
> On Fri, Feb 28, 2014 at 1:42 PM, Emmanuel Baccelli <
> Emmanuel.Baccelli at inria.fr> wrote:
>> Hi Daniel
>> Le 28 févr. 2014 11:15, "Daniel Camara" <danielcamara at gmail.com> a écrit
>> :
>> >
>> > Hi Emanuel,
>> >
>> >   Don't get me wrong, I am not judging, complaining, or something like
>> that, just stating the fact that we have two VERY distinct clients here,
>> just that! Even though this obvious for me, it needs to be clear to all.
>> Well, I guess, even if the only clients were RIOT developers, it would
>> already worth the effort... not that cool, we could do better, but probably
>> would already pay the price.... and the ways to implement the adaptation
>> could be highly dependent on it.
>> >
>> >  So yes I agree with you, we need to focus on hows, but I also
>> partially disagree because this specific point may impact the way the
>> adaptation will be made. If you decide the public is just the RIOT
>> development team... and you don't care for the second class of users (what
>> is completely fair), more "home made" and code dependent options could be
>> considered.... , for example, we wouldn't need something that is fairly
>> independent of versions of ns-3.  You could fix your code over, lets say,
>> version 19 and that is it would be more than enough for you.
>> >
>> >  Once more, don't get me wrong! Not judging, just trying to understand
>> :).
>> >
>> Ok, I think I get your point. In short: within or without the ns-3
>> context, RIOT's goal is to provide a platform that (distributed) IoT
>> application developers can build upon. So we do not only aim at the RIOT
>> devel crowd and we do care a lot about other users ;)
>> So what is the impact of this on the "how" to port RIOT on ns-3, in more
>> details? In particular, we do need to be as independent of ns-3 versions as
>> possible, in my opinion.
>> Cheers
>> Emmanuel
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
> --
>     Best regards...
>                      Daniel
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140304/cd8a713e/attachment.html>

More information about the devel mailing list