[Ns-developers] [ns3] socket API

[Sam Jansen]

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

Ok, I can agree with the argument that the differences are there for a
reason, and that they should even be large and obvious.

However, that is not a reason to use Packet as the difference in API.
My fundamental problem with "Packet" is that it is a very well defined
context in terms of networks, and something everybody who uses a
network simulator is (hopefully!) familiar with. When you see code
something along the lines of "socket->Send(packet);" what you read is
*not* what is happening at all - you're not sending a packet, you're
sending some data.

But I realise its a bit late to complain about this now :)

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

If the best we can do is make it obvious in the documentation, then
lets do that. I think it needs to be very clear in the docs for the
socket. I should have a look at the current documentation I guess to
see what is there right now.