On Thu, Oct 12, 2000 at 01:13:06PM -0400, David Dillow wrote: > I'm trying to implement a research routing protocol, and I've come > across a situation where I think having the routing engine use an > external resover would fit the bill perfectly. As I was trying to grok > the code, I came across rtm_type RTN_XRESOLVE which indicates that it is > used for an external resolver. It seems that it is not implemented yet. [...] The routing code is not really suitable for sleeping inbetween. 2.4 is a bit better, but still has many holes. If you want to do user space routing you should consider using the netfilter hooks instead. They handle sleeping gracefully and ip_queue handles all the nasty queueing required for you. You can modify the packet to go the way of your routing decision then. > > My guess at what the semantics should be is that when a packet is to be > sent down this route, we add a destination cache with dst_entry.output = > dst_blackhole so that this packet, and others like it, will be > discarded, and send a rtnetlink broadcast message indicating the > particulars of the route to be resolved. The user space portion of the > resolver would hear the rtnetlink message, resolve the route, and modify > the destination cache route to actually point in the right direction. Discarding packets to route them sounds rather radical -- i would better queue them to some limit. -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
