[Xorp-hackers] rtrmgr and TaskManager

[Ben Greear]

On 10/06/2009 09:54 AM, Bruce Simpson wrote:
> Ben Greear wrote:

> I buy the argument, but I'm sure you can understand my hands-off /
> kid-gloves position with regards to the Router Manager and taking
> changes for it -- it is a large C++ subsystem which I'm not entirely
> familiar with, and when I've made changes to it in the past, mostly when
> porting to Win32, it's been a case of get in, get out, stay focused, get
> it over with, and survive it.
>
> If you experiment with turning those timeouts down, and it works for
> you, that's great, but I really need to have a clear picture of what's
> going on, if I'm to be expected to support it on an ongoing basis.

You are welcome to expect me to support it, but then you'll need
to accept my patches, and I'm liable to get medieval on it :)
As you can tell, I don't mind changing things I don't well understand :)
And, I'll probably work towards my ideas about desired v/s actual and
definitely not towards more fine-grained threading (which is what
that 'continuation' stuff you talk about sounds like to me.)  I do
like select loops with event handling though, and I am continuously grateful
that there are no pthreads in xorp!

> In XORP's case, more engineering time seems to have been burnt up on
> getting the XRL layer written than on these external events you mention.
> The FEA in theory handles all of these events, it is something of a
> kitchen sink. What could do with better realization is how these events
> are propagated to the rest of the system -- which is why I've been
> focused on looking at XRL.

I think joining fea and rtr-mgr into a single process makes a lot of
sense.  Let the protocols remain separate.

>> The one thing I'd work towards is more of a 'desired'
>> v/s 'actual' config. Users could always configure any logical
>> configuration
>> and the system will try to make this happen, but it will also deal
>> properly
>> with 'phantom' things like interfaces that don't exist currently. A
>> different
>> programming language isn't going to help any of that I think..and I'd
>> very
>> much like to keep with c/c++.
>
> As you've probably already seen, the Router Manager code is non-trivial,
> and there's a lot of complexity in there to deal with the asynchrony of
> the XRL RPC calls.

The XRL RPC basically just works, as far as I can tell.  The logic needed
to deal with these dynamic events should be entirely outside of the RPC
mechanism..it's just a transport.  The bugs I find in this area are in
protocols and FEA, mostly because they always expect they know everything
and return errors and/or assert whenever something unexpected happens.

I'm (slowly) fixing this because I need it for my own efforts.

Someday I'll add a XORP_WARNING return instead of just OK and ERROR so
that we can return warning messages w/out failing commands.

> I agree that the configuration model needs serious looking at for things
> like dynamic interfaces (VPN, wireless, hot-swappable cards etc) and
> it's something which I raised several times as an agenda point during my
> time at ICSI. Unfortunately, the development focus has been in other
> areas, and I haven't been in a position to call the shots on where the
> effort went. I certainly got the impression that this put some folk off
> from trying XORP in the here and now.

Well, I'm in a position to fix this in my tree, and I'm doing so.
I've no idea who has position to do that to the public tree if you don't!

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com