[Ns-developers] TCP and UDP layer refactoring

[Mathieu Lacage]

On Fri, 2008-07-04 at 21:05 -0700, Tom Henderson wrote:

> I think that we could probably get away without carrying around the 
> incomingInterface as an explicit parameter.

agreed. At worst, you can keep track of the interface in the tag and
filter in the socket.

> 
> The FreeBSD socket demux code I've looked at before does not need to 
> carry this parameter.  Has anyone considered porting the logic for 
> socket wildcard matching from Linux or BSD to this demux function?  This 
> is not a trivial demux to implement.

The original demux code was copy/pasted from the BSD demux function so,
you can trivially restore it with hg log+cat.

> > II) Independant EndPoint
> > 
> > - Have a single class EndPoint (and remove Ipv6EndPoint and Ipv4EndPoint).
> > - The members m_localAddr an m_peerAddress will be stored as Address
> > - Remove Ipv4Address argument from m_rxCallBack and SetRxCallback (see 
> > VI)).
> > - Add a AfType (AF_INET or AF_INET6) to know the type of address.
> 
> Can't Address::IsMatchingType be used to learn the type of the address?

That was my feeling, yes.

> 
> Would it be sufficient and appropriate to just have logic something like:
> 
> Endpoints::Lookup
> {
>    if (InetSocketAddress::IsMatchingType (address))
>      {
>        // do Ipv4-based lookup
>      }
>    else if (Inet6SocketAddress::IsMatchingType (address))
>      {
>        // do Ipv6-based lookup
>      }
> }
> 
> this begs the question:  more generally than this lookup function, since 
> we have just two address families, would it suffice to handle most of 
> these address family issues by just passing class Address around, and 
> having the method first check whether the address is Ipv4 or Ipv6?

yes.


> > Some functions in *SocketImpl use InetSocketAddress or 
> > Inet6SocketAddress. We can avoid this by having a class that have the 
> > same methods
> > than InetSocketAddress but with Address attributes called 
> > StorageSocketAddress. This is similar to the "struct sockaddr_storage" 
> > in C.
> > 
> > StorageSocketAddress
> >    -> AfType type
> >    -> Address addr
> >    -> uint16_t port
> >    -> ConvertToInetSocketAddress (???)
> >    -> ConvertToInet6SocketAddress (???)
> > 
> > The InetSocketAddress and Inet6SocketAddress should have a operator 
> > StorageSocketAddress() to map automatically its contents to a 
> > StorageSocketAddress and set the AfType.
> > -> No changes to existing applications.
> > 
> > OR
> > 
> > we can also remove InetSocketAddress and Inet6SocketAddress and use only 
> > StorageSocketAddress.
> 
> Again, I would ask here whether class Address suffices.

I suspect that you mean that you would pass around Address and test
whether it is a v6 or v4 inet address where needed, right ? If so, yes,
that sounds like a simpler way to achieve this.


> > - Add Ipv*SocketAddressesTag before sending to UdpL4Protocol.
> 
> Regarding using tags to carry addresses between layers (if I understand 
> the intention correctly), I think it is clearer, if the address is a 
> mandatory parameter to pass, to just put it in the function signature.

yes.


> > - Have Ipv6EndPointDemux and Ipv4EndPointDemux or one EndPointDemux (see 
> > VII));
> 
> one EndPointDemux could check address type and call the right Ipv4 or 
> Ipv6 EndpointDemux function?

yes.


> > - When we *L4Protocol::CreateSocket(), it will give a socket that could 
> > be bound in IPv4 or IPv6 so no need to add Udp6/Tcp6SocketFactory;
> 
> this is an interesting point, I think.  The SocketImpl classes can't 
> have any explicit address family dependency because they are created 
> before the family is known.  So I agree with your point.

I do not really understand that last point: why would you not know the
family at this point ? The caller of the CreateSocket function knows
what family it wants to get.

Mathieu