[Ns-developers] [ns3] socket API

[Tom Henderson]

>
>You are right, but, I mentioned in my reply to george that there are two
>reasons for exporting a Ptr<Packet> version of this API:
>
>  1) performance (you focused on that in your emails and demonstrated
>successfully that it was not the _strictly_ necessary)

I still think there may be a benefit to use Packet to avoid a copy on the receive side when real data is being used.

>
>  2) allow applications to be written using Ptr<Packet>. hint: gusvato's
>olsr code does that pretty successfully.

Yes, and there are other reasons beyond header convenience to support this Packet-based API:
- applications can use the tags facility
- can use the metadata system for tracing

>
>There is another one I alluded to also: the need to support fancy
>features of the socket API such as ancillary buffers: it is trivial to
>add this support to a Ptr<Packet> API through tags attached to packets
>but adding this to a raw buffer-based API will require that you clone
>the C-style ancillary data API (man cmsg) which... Well, will represent
>much more careful painful work.

I would be fine supporting that only with Ptr<Packet> version, unless someone comes along with a patch who really wants this in the traditional C-style.

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

So, I do not see a big problem in having this duplicate API in this case, since this is such a fundamental legacy API.  We can say "here is the basic sockets API that you know and love, but the ns-3 preferred way is to wrap your buf in a Packet and get these additional features."

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

- Tom