[Ns-developers] [ns3] socket API

[Gustavo Carneiro]

On 21/04/2008, Tom Henderson <tomh at tomh.org> wrote:
>
> craigdo at ee.washington.edu wrote:
> <snip>
>
> > So I encourage thinking about this not as just "the socket API," but as
> > a
> > friendly synchronous sockets API, a fast native asynchronous low-level
> > ns-3
> > API and impedance matching glue.  The friendly synchronous socket API
> > should
> > offer no surprises to the user that expects BSD sockets.  The fast
> > native
> > asynchronous low-level ns-3 API should work in the ns-3 model, but be
> > advertized as *different* and implemented in that elusive,
> > hard-to-define
> > way that makes it easy to understand what is going on if you understand
> > sockets and ns-3, but plainly obvious that "it ain't sockets."  The glue
> > code is whatever is required to efficiently match the two different
> > models
> > and is not really public API.
> >
>
> Craig, I agree with your point that multiple viewpoints are colliding in
> this discussion.  Plus, the terminology issue-- that ns3::Packet is not
> really a packet at this level but is being used as a byte buffer, and that
> when we say ns3::Socket we are not talking about precisely matching any
> real-world sockets implementation.
>
> One way we have tried to handle that in the past has been to introduce
> helper functions, which may be appropriate here.  For instance, some type of
> helper to marshal in data from a large Send() call, and one that exports the
> byte interface and converts to/from Packet.
>
> The larger issue here seems to be what will be the prevailing model for
> applications that we will use as examples of how to do things in ns-3? I'm
> not sure that many people have looked closely at Mathieu's ns-3-simu but one
> possibility would be that the process code (see examples/process.cc) would
> be the most widely used API,


See, this is what I was afraid of.  You are opening the door for any and
every simulation model to use simulated processes, yet the performance
implications of this approach have not been studied.  We have already seen
that the only portable implementation of simulated processes is through
POSIX threads, namely one thread per simulated process.  Now suppose you
have 500 nodes, each running 2 routing protocols using synchronous socket
API.  NS-3 will then create 1000 threads.  And what will the performance of
that look like?...

because of its close parallel to a synchronous socket API, because it
> supports thinking about the applications as processes, and because it may
> lead to more portable code:
> http://mailman.isi.edu/pipermail/ns-developers/2008-April/003912.html
>
> If we go down that route (of using ns-3 processes more often than current
> applications) then the issue of whether ns3::Socket contains a byte-based
> API may be less important.  For instance, someone teaching a class on
> networking using ns-3 might work exclusively at the synchronous API.


Like I said, we should not go down this road without clear performance
indications.  Moreover, if this was a good idea it should had been
introduced one year ago, not now when we are just about to freeze the NS-3
core API, at least for a while.

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