[Ns-developers] NS3 Skeleton code posted for review
tomh at tomh.org
Wed Nov 29 09:26:13 PST 2006
Mathieu Lacage wrote:
> On Mon, 2006-11-27 at 08:21 -0500, George Riley wrote:
>> I also considered the C "socket-handle" API vs. a C++ socket object,
>> and initially preferred the C++ approach that you are advocating.
>> What finally tipped
>> the scale for me was in dealing with upcalls to the application.
>> Clearly, the app needs to know which socket caused the upcall, and
>> passing a Socket* makes
>> it a little (not much I agree) harder to look up application specific
>> state info. A simple int handle can be used as an index in an array
> Given your design, the natural solution to this problem is to make each
> Socket instance hold a pointer back to the Application it was created
> Another one would be to simply decide to use callbacks since they were
> designed to do this exactly: the user could provide a callback to the
> Transport layer or the Socket object which would call back into their
> own methods which would hold an implicit this pointer to the
To respond to a few of these application issues that have been raised:
- it seems to me that a good starting point would be to consider the use
of Python sockets class, as Gustavo suggested, since it is very close to
BSD API but has virtue of being OO. And I don't see what the major
difficulty is in having the application hold a pointer to the object.
- regarding the implementation upcalls, why not try the existing
callback framework? It is already there.
- regarding "Application" vs. "Process", I am fine with "Process".
Brian Adamson at NRL has done some work on supporting apps that work in
Opnet, ns-2, and real systems; the protolib toolkit is worth a look:
this framework uses socket objects too.
I think it would be a good exercise to try to port the various flavors
of clients/servers in Donahoo and Calvert's book to an ns-3 framework:
More information about the Ns-developers