[Ns-developers] [ns3] socket API

[Tom Henderson]

>-----Original Message-----
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Tuesday, April 15, 2008 12:02 PM
>To: 'Tom Henderson'
>Cc: 'ns-developers'
>Subject: Re:   [Ns-developers] [ns3] socket API
>
>
>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 ? 

It was what I suggested earlier-- you could use Packet::PeekData to get a pointer to the underlying buffer.  

I don't know whether it provides any meaningful performance impact but it seemed to be a case where you could avoid a copy if you were careful about it.

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

Yes, I could agree to that.

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

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

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