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

[Alexander Pelov]

Hi Gustavo,

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.

(More inline)

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  
> 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.
>
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  
> 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.

Yes, RPyC is a great solution, I admit I didn't expect Python to be  
"that" flexible.

>
>
>
>
> 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 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
> 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



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!

Regards,
Alex