[Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC
apelov at gmail.com
Wed Jan 21 09:59:15 PST 2009
I am sorry, but there was a little confusion with the e-mails. In
fact, Mathieu responded with RPyC to the mail you've commented on.
Le 21 janv. 09 à 18:17, Gustavo Carneiro a écrit :
> 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
> 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
> we expose. However, I think that this is going to create a very
> 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
> 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
> "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.
When I wrote that mail I didn't know about the existence of RPyC, so I
was discussing the way I thought these things could happen without RPyC.
> Lets look at the way mobility is implemented in the moment. There
> are two
> methods acting on node movement direction - GetDirection and
> 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
> format and send it over the net. And remember - all this is that
> easy just
> because there is a
> 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.
Yes, RPyC is a great solution, I admit I didn't expect Python to be
> So, we are going to have to write several lines of code for each
> 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
> in a language-independent way. Doing so would have several benefits:
> 1) Implementing it in several network simulators would allow third
> software to communicate interchangeably with all of them. It would
> 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 think I didn't express myself very well on this point. I was
referring to having a set of standard, implementation independent
functions VS exposing the whole ns-3 API over RPC. I think that the
latter would be a great solution, but difficult to implement (maybe
I'm wrong on this, though).
> I'm sure this list could go on, but I think that these reasons are
> > 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
> to the full extent, and we have taken note from your remarks. We are
> 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!
> Alexander PELOV
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
I've sent another mail to the mailing list which covers all these
subjects more thoroughly - I would be glad to hear your opinion on the
points I've mentioned there.
Thank you for your comments!
More information about the Ns-developers