[Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC

[Gustavo Carneiro]

2009/1/20 Alexander Pelov <apelov at gmail.com>
[...]

> I should say that Python is a great language, so it would probably be
> feasible to write a single XML-RPC entry point that would go through all
> existing object in the Python namespace and execute that method on the fly.
> That's great - it would save us the need to write code for each RPC
> function
> we expose. However, I think that this is going to create a very convoluted
> way of calling the functions.
>
> But this will not solve the problems, as Python bindings are only what they
> are - bindings - the return value of a method invocation is a proxy to the
> underlying C++ object. You cannot automatically marshal/unmarshal that
> (unless you force ALL methods to provide the necessary methods). This is
> going to create a true nightmare for all third party software authors -
> they
> are going to be forced to understand the way these objects serialize
> themselves OR stream the object back to ns-3 to call a particular function
> on it, and then get it back. And that is not guaranteed to work, unless you
> force all member functions that perform in-place changes to also return
> "this" (uploading an object to ns-3, just to receive an "OK" is not going
> to
> help the poor caml user on the other side of the fence).


I do not understand why you feel the need to marshal NS-3 objects at all.
In rpyc, objects are created in the server and always stay in the server.
The client only sees a proxy/reference to the server-side object.  The only
thing you really need to marshal is fundamental types, such as strings,
floats, integers, etc.


>
>
> Lets look at the way mobility is implemented in the moment. There are two
> methods acting on node movement direction - GetDirection and SetDirection,
> which return/receive a Vector. The  Vector does support an internal
> serialization format, but it does not have anything to do with XML. So, in
> the best case, the caller will obtain something she has to parse (after the
> whole XML-RPC over HTTP processing), change, then generate the fixed string
> format and send it over the net. And remember - all this is that easy just
> because there is a
>
> killer-all-in-one-state-of-the-art-reflection-using-python-based-single-entry-XML
> function.
>

No, the ns3.Vector object is not copied from server to client, only a
reference to that vector is copied.  The problem that you have is only that,
when you want to obtain the x,y,z coordinates you have to access 3
attributes of the proxy object, which will probably translate into 3 round
trips.  So you could argue about a potential performance problem, but not
about lack of transparency.


>
>
> So, we are going to have to write several lines of code for each function
> exposed via RPC (which is what everyone does) - exactly the approach we
> have
> taken. I do agree that the code would be more succinct in Python than in
> C++, but I think that with the right helper functions the difference will
> be
> minimal, and the user will be able to harvest the full potential of the C++
> roots of ns-3.
>
>
> I think that a better approach is to define interfaces - specify a set of
> universally accepted methods, along with their parameters and return values
> in a language-independent way. Doing so would have several benefits:
>
> 1) Implementing it in several network simulators would allow third party
> software to communicate interchangeably with all of them. It would become
> trivial to write an application in Java and see how it would behave in ns-3
> and omnet++ for example.
>
> 2) Be implementation independent. Changing an implementation detail would
> be
> hidden from the external user.
>
> 3) Be easier to use.
>

I think your proposal sounds more like NS-2 and the otcl bindings, where all
objects would have to subclass a special TclObject class, and would have to
write explicit code for receiving the parameters from TCL.

In NS-3 things a better layered now.  You write normal C++ objects, and
pybindgen reads the header file to figure out how to bind the API for
Python.  The C++ code is not even aware it is being wrapped for Python.  You
are proposing to change that?


>
>
> I'm sure this list could go on, but I think that these reasons are
> sufficient.
>
>
> >
> >
> > I am really very sorry to be so negative after the review :/
> >
> > Mathieu
> >
> >
> In conclusion I have to say, that maybe we didn't prepare the announcement
> to the full extent, and we have taken note from your remarks. We are going
> to prepare an additional document explaining the proposed RPC functions, so
> that we could have a fruitful discussion on concrete use-cases.
>
> Thank you again for your remarks and suggestions!
>
> Regards,
> Alexander PELOV
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert