[Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC
Mathieu Lacage
mathieu.lacage at sophia.inria.fr
Wed Jan 21 12:01:26 PST 2009
On Wed, 2009-01-21 at 18:46 +0100, Alexander Pelov wrote:
[snip]
> (C.2)
> I was only joking about CORBA. I actually meant Thrift (http://incubator.apache.org/thrift/
Well, I don't hate CORBA. It does its job pretty well.
> ). In fact, we were considering it as a possible solution candidate.
> The specific RPC technology is not important. The point is that
> someone has to sit and write interface definitions of all/most of ns-3
> functions. This way everyone who can understand the protocol at hand
> can call all functions at will.
I agree that you need to do this. However, the thing is that we have
been faced with the exact same problem when gustavo implemented our
python bindings: you might enjoy reading the relevant archives of
ns-developers. The outcome was:
1) it is not practical to maintain by hand the bindings/metadata about
our C++ API.
2) we need to automate the extraction of the relevant metadata to
generate the bindings.
To summarize: you are going to have to solve all the same problems and
be faced with the same maintenance headache. I suspect that the right
way forward would be to reuse an existing automated tool to avoid these
problems and pybindgen+pygccxml might be just the thing you need.
> So, if I have to summarize:
> - You want to plug in a simple solution and let the world figure out
> how to use ns-3 from the outside. I think RPyC is doing this for the
> Python part of the word and that's great! With the addition of a
> handful of simple, standard functions thats a solution after my own
> taste. In my own case - I am using Python for my application, so I
> could profit from this solution today - with the exception that I want
> to be able to interface with other simulators, so I would have to
> write the RPC functions anyway.
ok.
> - Regarding the other rest of the world - there is no magic, plug-o-
> caller (unfortunately). And here, I would rather say that it would be
> nice to have a set of core, standard functions that are callable from
> anyone smart enough (e.g. via JSON-RPC or Thrift) and show them what
> to do in case they want to call something more specific (making sure
> the specific things are not more than 10% of the cases). And by
> extending the core functions, the number of special cases will go down.
I think that you are proposing building a thrift/[other technology of
your choice here] binding incrementally. This is certainly doable but I
have to confess that I would never really recommend doing this and I am
not too excited to see ns-3 API changes be constrained by another layer
on top of it...
> Don't get me wrong - I also want to be able to call any function I
> wish, and have the complete power of NS-3 under my (remote) fingers.
> But doing so for everyone would require the interface of each function
> to be defined (which does not seem as an easy task to me). Maybe there
> are some tools that can aid this? I hope so.
There is no perfect solution: it's all about making a compromise which
is acceptable to everyone.
Mathieu
More information about the Ns-developers
mailing list