[quagga-dev 12091] Re: Advise on implementation
lberger at labn.net
Tue Mar 3 22:12:27 GMT 2015
On 3/3/2015 4:50 PM, David Lamparter wrote:
>>>> On Tue, Mar 3, 2015 at 7:19 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>>>>> My basic opinion is that shm interfaces end up being painful for
>>>>> various reasons, including portability but also leaving shm segments
>>>>> around. Since this is control plane, and sockets are fast anyway, I
>>>>> don't see any reason to get wrapped up in shm.
>>> Le 03/03/2015 16:31, Dinesh Dutt a écrit :
>>>> +1, plus the issue that the various daemons may no longer be isolated
>>>> from each other due to this shm,
>> On 3/3/2015 12:37 PM, Olivier Dugeon wrote:
>>> What do you mean by 'may no longer be isolated from each other' ? They
>>> are already link to the zebra daemon.
>>> In order to implement BGP-LS, we need some communication between OSFP,
>>> IS-IS and BGP. Of course, this will
>>> break this isolation principle, but wathever the solution will be.
> I agree with Dinesh & Greg. The problem is, with SHM, it is far easier
> for invalid data to cause a crash in all the daemons from a bug in just
> one of the daemons. The problem isn't locking or anything, it's invalid
> (pointer) data inside the SHM data. It's possible to take precautions,
> but ultimately you need to validate all incoming data and thus lose much
> of the zerocopy advantage.
I too am not a big fan of SHM, unless you have something really simple
like a double buffered scheme with single writer. For cases where IPC
is too expensive (e.g., between a TED and path computation) I think a
scheme that provides a common way to bind additional functionality into
a (e.g., TED) daemon makes more sense.
>> On Tue, Mar 03, 2015 at 02:23:59PM -0500, Lou Berger wrote:
>> Have you considered introducing a generic TED (topology database)
>> deamon in parallel to zebra? I think this would more closely match what
>> other implementations have done and there are many advantages over
>> direct protocol exchanges.
>> And yes, I know this question/topic is orthogonal to the current
>> question/thread on shm vs ipc/rpc.
> This sounds interesting. The direction of this, as I understand it, is
> to split off new functionality into a separate daemon to reduce
> congestion in zebra.
exactly. It makes a lot of sense to have a common topology
repository/DB just like it does for normal routes, but there's little if
any intersection/overlap with current zebra so why put it into the same
> Jumping from this to details regarding socket-based protocols, there are
> also some design questions. I'd like to use some pseudostandard
> extensible encoding, allowing us to add fields in a structured manner
> and profit from code generators for various languages. Apache Avro is
> unfortunately under the Apache License, leaving mostly protobuf. What
> are people's opinions on this?
> (I'd very much like to use something common here, for ZAPI, OSPFAPI, and
> any new APIs including linkstate stuff and structured access to
More information about the Quagga-dev