[Ns-developers] [ns3] socket address

[Mathieu Lacage]

On Mon, 2007-07-30 at 11:52 +0100, Gustavo Carneiro wrote:

>         
>         >   - pass Address objects by value: avoids memory management
>         >     issues for users.
> 
> I am guessing that this requirement drives the regretable (but
> unavoidable) design decision of not having a base address class and
> specific address types subclassing the base class.

it does.


> Also regarding Eui48Address, it may be useful by itself (in analogy to
> Ipv4Address) but it departs significantly from the linux "packet
> socket" model.  The former only has the 48 bits MAC address, while the
> latter supports up to 64 bits of link-layer address, interface index,
>  and address type, etc.  More specifically: 
> 
>          struct sockaddr_ll {
>              unsigned short sll_family;   /* Always AF_PACKET */
>              unsigned short sll_protocol; /* Physical layer protocol
> */
>              int            sll_ifindex;  /* Interface number */ 
>              unsigned short sll_hatype;   /* Header type */
>              unsigned char  sll_pkttype;  /* Packet type */
>              unsigned char  sll_halen;    /* Length of address */
>              unsigned char  sll_addr[8];  /* Physical layer address
> */ 
>          };
> 
> We need all these fields if we want complete and consistent link layer
> sockets API; the Linux packet(7) explains the use of each of the
> fields.  Else I'm afraid we will come up with a simplified API that
> will not cover all the cases that we need and make us revisit the
> issue later on, causing wasted time and effort. 

If you look at the ns-3-address tree, you will see that the NetDevice
base class has been adjusted to use an Address class so, it would be
conceivable to implement an Eui64Address class which is convertible to
and from Address classes and that would address the issue you raise
here.


> And, do not forget, put Socket in the address type name.  That's
> important.

The current design does not provide Socket addresses. It just describes
a way to encapsulate any number of types of different user-specific
addresses into a single object named Address. The Socket API happens to
use that class Address in lieu and place of sockaddr in the BSD socket
API but the Address class is also used in the NetDevice API, so, there
is little point in making _every_ address class use a Socket prefix
because they are not all necessarily used by sockets.
> 
> Finally a remark on this (Eui48Address, probably InetAddress has the
> same problem) method:
>   /**
>    * \returns a new Address instance 
>    *
>    * Convert an instance of this class to a polymorphic Address
> instance.
>    */
>   Address ConvertTo (void) const;
> 
> "ConvertTo" doesn't read very well if the method has no parameters.
> Convert to what?  If there's any place that deserves implicit
> convertion, it may be here.  Can't we get rid of explicit
> ConvertTo/From methods?  I would suggest this; it will save us poor
> programmers a lot of pain: 
> 
> class Eui48Address
> {
> [...]
>    // former ConvertFrom
>   Eui48Address (const Address &from);
>   // former ConvertTo
>   operator Address ();
> [...]
> };

As I said in my initial email, this is one of the open issues. That
solution is more risky in the sense that it is not trivial to figure out
the order of implicit conversions for mere mortals, so, that is why I
did not yet implement it. But if there is a strong consensus that this
is needed and if it turns out to work correctly, I am fine with it.

Mathieu
--