[Ns-developers] [ns3] socket API

[Tom Henderson]

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

Tom