[Ns-developers] [ns3] socket API

[Mathieu Lacage]

On Tue, 2008-05-06 at 05:32 +0000, Tom Henderson wrote:

> >  * If the packet does not fit, the caller can split the packet to send
> >  * (based on output by GetTxAvailable) and re-attempt to send the
> >  * packet.
> >  * If you want to provide a per-packet "to" address, store it as a
> >  * special tag in the outgoing packet.
> 
> I ran into a small problem in implementing the tagged address:  tags are
> size limited to 16 bytes and class Address requires 32.  In the repo, I
> bumped this size constant up to 32 bytes.  If, in general, we want
> Addresses to be taggable data, we ought to allow for 32 byte tags.

Forcing a fixed max size on tags is probably too painful in the end. The
mathieu/ns-3-tags branch supports arbitrarily-sized tags.

> 
> >  */
> > int Send (Ptr<Packet> p, uint32_t flags);
> > 
> > /**
> >  * returns the number of bytes which can be sent in a single call
> >  * to Send. 
> >  */
> > uint32_t GetTxAvailable (void) const;
> 
> I implemented this in the base API, and supported returning "maxint" for
> the PacketSocket and UdpSocket classes.  Again, Raj will support this
> correctly in the TCP code, which is where it really matters for now.
> 
> > 
> > If we implement this, we should remove the SendTo method. Problem: if we
> > do this, we cannot specify the "to" address for
> > int Socket::SendTo (uint8_t *buffer, uint32_t size);
> > because there is no Ptr<Packet> to attach the "to" address to.
> 
> I don't know why removing SendTo is related to the above.


I believe I wrote that as a reference to the fact that if we want to
support the flags argument to Send, then, we also want to support it for
SendTo and if do that, we are quickly going to be swamped by the number
of combinations of Send which take a to address and/or a flags argument.
It seems simpler to just push all optional arguments to be packet tags
than to try to support all method signature combinations.


> > 
> > Solution: get rid of the Socket::Send* methods which take raw buffers
> > and implement them exclusively at the "synchronous" layer.
> 
> There are several options here:
> - implement raw buffers only at the synchronous layer
> - implement them also at the current Socket layer (what we have done for
> now)
> - implement them instead at the synchronous layer and a new helper layer
> - do not implement raw buffers below the synchronous layer, but use the
> Buffer class in place of the raw buffers (Gustavo proposed this on the list)

The only reason why using Buffer is a good idea is naming: it does not
support tags though so, that would rule it out if we want to support the
application-level flow tagging features we discussed on the list in
other threads.

The simplest approach seems to me to move them to the SocketHelper class
and remove them from the Socket class.

[snip]


> > Another option here would be to just add all of the above methods to the
> > existing src/node/udp.h and src/node/tcp.h classes with an extra
> > Ptr<Socket> argument:
> > 
> > class Udp  ...
> > {
> > public:
> >   /* Implement the linux IP_PKTINFO socket option. */
> >   virtual void EnablePktInfo (Ptr<Socket> socket) = 0;
> >   virtual void DisablePktInfo (Ptr<Socket> socket) = 0;
> >   virtual bool IsPktInfoEnabled (Ptr<Socket> socket) = 0;
> > };
> > 
> > The former approach feels slightly more "right".
> 
> There are also two more approaches possible, I think:
> 
> 3) implement what you proposed for class Udp instead for class
> UdpSocket (which is what I did for now)

One problem with that is that the UdpSocket class is specific to the
internet-node module so, we cannot re-implement it in src/linux for
example. Another problem is that a lot of these per-socket controls are
common to both tcp and udp (they are specific to ipv4 or ipv6 instead)
so, it would probably make sense to move them to a class which is common
to both Udp and Tcp sockets and you cannot do that since that would
require multiple-inheritance. That is why I suggested to move that stuff
to an aggregated class.

> 4) support these through the attribute system on the sockets (i.e.,
> PktInfo would be an attribute of UdpSocket)

That might work for some of these per-socket controls but it would be
nice to have a clear public API for all of them.

> 
> > 
> > 4) How is ancillary information supported ? It is attached as a tag to
> > each packet whether it is sent or received.
> 
> I haven't tried to support ancillary information.

If we support per-packet tags, we can support ancillary information
later as needed.


> The tomh/ns-3-dev-socket branch supports the above additions to the
> socket API and underlying implementation for UDP and PacketSocket, and
> placeholders for TCP.  The ns-3-dev-socket-helper branch doesn't yet
> have different code but the idea there is to prototype a variant in
> which the API on current ns3::Socket is reduced and a new helper-like
> class is built on top of that with more of a traditional socket
> look-and-feel, albeit asynchronous.

sounds good to me.

Mathieu