>>>On Tue, Mar 3, 2015 at 7:19 AM, Greg Troxel <[email protected]> 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. > 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. 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 configuration.) -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
