[Ns-developers] [ns3] socket API

[Mathieu Lacage]

On Tue, 2008-04-15 at 19:40 +0000, Tom Henderson wrote:
> >
> >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.

Would you care to elaborate that use-case ? 

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

Can we agree to _not_ take that patch if it ever comes ?

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

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

I have to confess that using the word "legacy" here seems a bit out of
context: it is the synchronous BSD/posix API which is legacy, not our
hacked-up version of it. What matters is that our implementation of the
synchronous BSD/posix API implements correctly the "legacy" in
src/process/simu.h: the node/socket.h header matters very little from
that perspective.

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

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

Mathieu