[Ns-developers] ns-3 node draft proposal

[Mathieu Lacage]

On Mon, 2006-11-13 at 12:00 +0000, Gustavo Carneiro wrote:
>  Hi Mathieu,
> 
>   For now I only have a couple of comments, then we'll see... :)
> 
> On 11/13/06, Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
> >
> > hi all,
> >
> > Based on the 'ns-3 design' document, I have put together a draft
> > proposal with sample scenarios, a small rationale document and some
> > sample headers. If you think that some really important use-cases or
> > constraints have not been taken into account, I think that it would be
> > nice to comment on this now.
> >
> > Any kind of feedback, positive or negative, is welcome.
> 
> 
> ** Comment #1:
> 
> I just had a glance at the simple-router.cc example and saw this:
> 
> class EthernetTopologyFactory
> {
> [...]
>   template <typename T>
>   uint32_t AddInterface (T *node, EthernetCable *cable);
> [...]
> 
>   Can we please refrain from using templates so much?  Why is T a templated
> typename, why can't it be simply NodeBase?

Because AddInterface accesses the m_ipv4 field of the node object and
the m_ipv4 field is not part of the Node base class but of the node
subclass.

Arguably, I don't care much about making the T type a LeafIpv4Node type.
It just means that the helper methods/class will not be as widely
re-useable as possible. I do not think that this would be such a big
deal.


> ** Comment #2:
> 
> About the sockets API:
> 
>   " This class has not been designed yet but I expect that the Tcp socket
>     API is split in two classes, TcpServerSocket and TcpClientSocket, in
>     a way similar to the design of the java socket API where sockets
>     listening for incoming connections are called ServerSocket: they can
>     then create any number of ClientSockets from the incoming connections
>     once they have been accepted."
> 
> Unless I'm confusing something, doesn't the design document talk about
> implementing a POSIX sockets API?   I thought the idea was to implement
> POSIX sockets in order to facilitate writing protocols that can be easily
> ported to/from regular POSIX operating systems, such as Linux and *BSD.

Regular C/posix style socket APIs can be built on top of a Java-like
socket. Java-like sockets simply happen to be a much better designed
object-oriented API which is why I would like to re-use them to allow
users of the in-simulator sockets to save themselves pain.


> ** Comment #3 (well, so I lied, it's 3 comments :D)
> 
> "For brevity and clarity, all examples in this document omit to use the
> ns3::ptr template smart pointer class but I assume that it is used
> everywhere so, memory-management issues are somewhat simplified."
> 
> 
>   This ns3::ptr smart pointer sounds interesting.  I was going to suggest
> something along those lines myself.  However, I can't find it anywhere.  But
> I would expect a smart pointer would perform reference counting
> transparently in the background, and so I would expect a standard Object
> base class for everything that can have a refence count (and so would have a
> refcount member)...  Could shed some light on your plans for this?

boost::shared_ptr uses an external reference count. This is not really
optimal so, I would like to make the ns3::ptr template smarter and use a
boost::shared_ptr if the underlying class has no public refcount field
or use the public refcount field directly if it can. i.e., if you notice
that you are using too much memory or cpu with the external refcount,
all you have to do is add a public refcount field to your class (or a
pair of ref/unref methods) and everything will work as usual, except
faster. This is, however, more of an implementation detail than anything
else.

Mathieu
--