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

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

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

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 :-)

Bye,
   Axel.

Other related posts: