[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