[Ns-developers] [ns3] socket API

[Sam Jansen]

On Wed, Apr 16, 2008 at 3:51 AM, Gustavo Carneiro <gjcarneiro at gmail.com>
wrote:

> On 16/04/2008, Sam Jansen <sam.jansen at gmail.com> wrote:
> >> I'd like to add my 2 cents here and say that this is a big important
> > point we shouldn't lose sight of here.
> >
> > Some ideas off the top of my head:
> >
> > 1. I don't like the idea of designing an API around performance and
> > forgetting what this is actually modeling (which appears to be
> > happening here).
> >
> > 2. How incredibly confusing, for either a student new to
> > networks/sockets, or an old hand used to streaming sockets, to see an
> > API where you have to pass a packet in. Without the context of this
> > email thread, I think this would leave even experienced network
> > programmers with a confused look on their face.
>
>
> I think that, because of the way ns-3 headers work, we are forced to pass
> in
> packets when we want to use the ns-3 headers framework on top of UDP
> sockets, like I did in OLSR.


Ok, point taken.


>
>
> 3. For better or for worse, the sockets API is here, has been here for
> > a long time, and is here to stay. People are familiar with it. It's in
> > books. Do we really need to deviate so much from it? Forgetting the
> > simu/process work for a second, if I want to model my application in
> > ns-3, why can't I have a familiar API to send/receive data (or send
> > receive a number of bytes).
> >
> > Let's look at this another way. When dealing with TCP, an application
> > *never* has to deal with anything called a "packet". The idea of a
> > "packet" should never enter the mind of an application developer. This
> > is the reality, so it is what we are trying to model.
> >
> > I see that performance is required here when application data is not
> > used, but why do we have to use the Packet here? It is obviously
> > convenient and solves the problem, but it doesn't sound like the right
> > way to do this to me.
> >
> > It seems to be that a different abstraction than a packet is required
> > here.
> >
> >
>


>
>
> I think perhaps sockets could accept an _additional_ API accepting bytes
> for
> sockets.  But we cannot remove the packet based API for the reason I
> explained.
>

Ok.


>
> But another consideration to be made is whether sockets should accept a
> pair
> of uint8_t* and uint32_t, (base pointer and length).  Such an interface is
> very low level and very C-like.  It is also hard to wrap for language
> bindings, as it requires manually written wrappers all the time, since for
> example a single python string argument maps to a pair of C/C++
> parameters.
>

That's a good point I hadn't considered.


>
> Perhaps a good approach (in _addition to_ the existing API, I can't stress
> enough) would be a Buffer based API.
>

Well put. I was thinking something on the same lines with the comment "It
seems to be that a different abstraction than a packet is required here.".


>
> Socket::Send (const Buffer &buffer);
>
> Like:
>
> Ptr<Socket> sock = ...;
> sock->Send (Buffer ("hello", 5));
>
> I think it "reads" better, even for TCP sockets, and is high level enough
> to
> not make language bindings too difficult.
>

I agree. This looks like the correct abstraction to be presenting to an
application model.


>
> For greater performance (avoid copy) we could have:
>
> sock->Send (Buffer::NewFromForeignData ("hello", 5));
>
> But then we need very clear semantics of when the data is actually copied
> into a packet, and this is very tricky.  Copy too soon and you lose any
> performance advantage you thought you had.  Copy too late and you risk the
> data disappearing underneath you and a memory error when you do need it.
>
> So I really do not think we are so desperate for performance that we want
> to
> risk using something like my proposed Buffer::NewFromForeignData.
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>