[Ns-developers] [ns3] socket API

[Gustavo Carneiro]

On 16/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> 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 ?


IMHO I think we should not treat documentation as an opportunity to "fix"
bad naming of classes.  Documentation is to provide _additional_
information.  Class and method names are the very first line of
"documentation" users will encounter.  Moreover, ever since that (imho
regrettable) decision of starting to use Packet as smart pointer and not as
value, the Packet/Buffer duality makes less sense.  But I could be wrong (no
idea if Buffer is used anywhere else outside Packet).

But I think this is all moot; it's not a good idea to rename a class like
Packet to anything else, at this point.  It would break way too much code
out there... :P

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