[openbeosnetteam] Re: Information about routes and interfaces for protocols

On 2006-07-30 at 22:08:57 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Hi Oliver,
> 
> Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
> > now that a first version of UDP is at least basically working, I'd
> > like to
> > continue with filling in some holes in the stack:
> 
> Cool :-)
> 
> > UDP needs to know the IP of the outgoing interface when sending data.
> > Normally, only IP would determine this (as a result of the routing
> > decision),
> > but since UDP requires it, too, I have implemented a workaround that
> > grabs
> > the domain (via get_domain()) and then fetches the route for the
> > given
> > destination address. Now that UDP knows the route, it can copy over
> > the
> > source address from the route.
> 
> That's actually how I imagined it, and not only as a work-around.
> Specifically, the datalink's net_route_info functions are thought for
> that usage; you get the route info once when the "connection" is
> established, and then use that structure as long as you need it - the
> actual route will be updated as needed (you just don't need to care
> about that).

Ok, I had noticed the handy notion of routes being reference counted in our 
stack. A good thing that, esp. since the comments in the BONE-headers for the 
related methods indicate a rather clumsy handling of routes in BONE...

> > This works, but having to fetch the domain and the route from UDP
> > (jumping
> > from the transport layer directly into the datalink layer) isn't
> > really nice,
> > or am I just being too pedantic, here?
> > I suspect that BONE is solving this with the get_route() function
> > that is
> > missing in our net_protocol_module_info. Axel, given the fact that
> > you left
> > that function out, I'm pretty sure there's a good reason for doing
> > so, still
> > I wonder if it wouldn't be better to add get_route() to a protocol's
> > module?
> 
> My thought was that routes are linked with domains. The datalink just
> exports the routing functions - when you get a pointer to the domain,
> you also gain access to the datalink level, IMO, as they are tight
> together.

Yeah, my suggestion had the problematic notion of putting more and more stuff 
into net_protocol_module_info, which sooner or later would make it more 
complicated to find out which methods actually needed to be implement at what 
protocol level... Now that I know it's meant like this, I'm fine with using 
the domain (and the functions from net_datalink_module_info).

> In BONE routes don't have any reference counting, so you would need to
> lock the domain yourself (when you get the route, and release it when
> done).
> 
> > Along the same lines: there are instances when IPv4 needs to know the
> > IP
> > addresses of the local interfaces, in order to determine whether or
> > not a
> > given source/destination IP is indeed of this host. The current
> > implementation takes a shortcut (marked as such) and iterates over
> > net_domain.interfaces  without locking. I remember Axel mentioning
> > that
> > locking isn't thought through yet, so I guess, that's just one
> > incarnation of
> > this fact >;o)
> > 
> > In order to fix the problem, we could:
> > 1) Add is_local_address() to net_protocol_module_info and
> >    net_datalink_module_info. IPv4 would just delegate the request to
> > the
> >    datalink module, which could lock the interfaces in it's
> > implementation
> >    (as it can access the private parts of net_domain).
> > 2) Export locking functions for net_domain (rather ugly)
> > 
> > Any preferences (or other, better ideas) on this?
> 
> Also in this case, I would bind the is_local_address() function to the
> domain, and put it into the datalink module without putting it into the
> protocols.

Yes, now that I have accepted using the domain from upper layer protocols, I 
couldn't agree more >;o)

> 
> If it would be a C++ class, I would move the datalink module functions
> as methods into the domain class - having the domain gives you access
> to its functionality. Only send_data() is a bit special, as its a
> direct transport function.
> 
> At least that's what I thought about this matter, I hope you can agree
> a bit :-)

Sure! I'll have a go at implementing is_local_address later (probably 
tomorrow).

cheers,
        Oliver

Other related posts: