[Ns-developers] [ns3] socket API

[Sam Jansen]

Some comments inline...


>
>  >
>  >> >Anyhow, 2) described above really makes it mandatory to have a
>  >> >Ptr<Packet> version of the API so, the question is: why should you
>  >> keep
>  >> >around the raw buffer-based version of the API since:
>  >> >
>  >> >  - it is trivial to emulate its behavior: wrap your raw buffers with
>  >> >Packet::Packet (uint8_t *buf, uint32_t size)
>  >> >
>  >> >  - it either won't support features such as ancillary data or will
>  >> >require a _lot_ of work to support them
>  >> >
>  >> >  - it duplicates the other API
>  >> >
>  >> >I am certain that craig would be able to come up with a nice summary
>  >> of
>  >> >all the reasons why providing two ways to do the same thing in an API
>  >> is
>  >> >really bad and why it should be avoided so, I won't try to beat him
>  >> to
>  >> >it.
>  >>
>  >> The only reason that I see to support this is the legacy API issue,
>  >> which is where I believe George is coming from.  Recall that Joe had a
>  >> question last year about how to copy data into a packet at the
>  >> application level (you need to use AddHeader, which is not intuitively
>  >> obvious).
>  >
>  >Why can't you write this:
>  >
>
> >uint8_t *buffer =...;
>
> >uint32_t size = ...;
>  >
>  >Ptr<Packet> end = Create<Packet> (buffer, size); ?
>  >
>  >Ptr<Packet> begin = ...;
>  >
>  >begin->AddAtEnd (end);
>
>
> Yes, you can do that too.  I think the point was, that these techniques are not as immediately obvious to the new users who knows sockets or who are porting over existing code.
>

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.

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.

>  >
>  >> That is, make Ptr<Packet> the primary API in terms of features (cmsg),
>  >> but also agree to support the Send/Recv buf versions as overloaded
>  >> functions, where they are immediately converted to/from Packet below
>  >> the API, as is presently done in Socket::SendTo ().
>  >
>  >I would like to avoid being on the receiving side of user emails such
>  >as: "which version should I use ?".

Howabout emails like, "why can I only send packets with TCP, why can't
I just send a bunch of bytes?"

Doesn't sound like a net win to me.

>
>
> This would not be the only instance where we provide multiple ways to do things.
>
>  I am mainly suggesting that it seems to be low implementation cost to support this overloaded API, which we had agreed to do previously, and maybe some users are more comfortable with it.
>
>
>  >
>  >> I think the main issue is making sure that tags are handled correctly
>  >> across this API boundary (bug 166) but this seems to be a TCP socket
>  >> implementation issue.
>  >
>  >I agree that it is an implementation issue for our TCP implementation,
>  >but, what will happen when we try to wrap the linux TCP implementation ?
>  >How are we going to track the application tags from within the socket
>  >implementation ? It would be nice if we could come up with a plan to
>  >address that issue: I can't think of any simple way to do this offhand
>  >though.
>
>
> We could say that packet tags are best effort data; we will have similar issues when we run in emulation mode.
>
>
>  - Tom
>
>
>
>