[Ns-developers] [ns3] socket API

[Mathieu Lacage]

On Tue, 2008-04-15 at 19:42 -0700, Sam Jansen 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).

As I pointed out in previous emails, this is not only about performance.

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

more about this below.

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

Well, that is the problem: you cannot forget the 'simu' tree because
that tree provides the missing piece: the C POSIX socket API for those
who don't like surprises. Otherwise, if you start using
src/node/socket.h, you have to learn that it is asynchronous, uses
callbacks and notifications, none of which make _any_ sense for normal
socket users. 

So, arguing that you have to match a small detail of the socket API
because that is what users expect is really a bad argument: users
already have to learn the differences and these differences are
_already_ big. I would tend to say that we should even make these
differences bigger to avoid confusion because, if you expect the C posix
socket API src/node/socket.h, you are dead wrong.

> 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 think that your email might be really about a naming issue. What we
call a Packet is, in fact, a fancy byte buffer. Nothing more, nothing
less: it might not be obvious from the documentation (if so, feel free
to chime in) but that was really a strong design goal: make the Packet a
fancy byte buffer with lots of magic capabilities. So, Send takes a
fancy byte buffer named a "Packet": maybe this is what you would like to
see in the doxygen comments ?

regards,
Mathieu