Hello Greg,
In fact, I try to manage the situation where we have ZAPI in one hand
and OSPF-API in
other hand. ZAPI & OSPF_API work well for the moment. But, my concern is
to extend/generalize
OSPF_API to other Quagga daemon (IS-IS and BGP to support BGP-LS at least).
So the question is two fold:
- There is an architecture decision to take: do we continue to
maintain / extend two communication
channels i.e. ZAPI and OSPF_API or is it time to think to Quagga
architecture and design
a flexible channel (single or multiple) communication system for all
purpose
- And an implementation choice for this communication system.
I understand that the ZAPI bus could be congested when playing with a
large number of VPN. So,
Vincent Jardin suggest me to not extend ZAPI and look to an other
communication channel.But,
is it valuable to maintain 2 different API, or is it time to move to a
common system sufficiently
powerfull and safe to handle present and future needed.
I'm open to any advice and suggestion, but would not start a development
that conduct in a dead end.
I'm also another question regarding the thread implementation / usage in
Quagga. Looking to the
architecture, we could keep the modularity of Quagga, but moving to
pthread and dynamic load of
daemon. We could have a main pthread (i.e. Zebra layer) that dynamically
load piece of code that
implement a given protocol regarding the configuration file or based on
which protocol is needed.
This allow the possibility to share the same memory space between the
different daemon (pthread)
while avoiding communication channel between process. But, perhaps I'm
completely wrong, and I
perfectly understand that it is a huge amount of work to do.
Regards,
Olivier
Le 03/03/2015 16:19, Greg Troxel a écrit :
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.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
