[quagga-dev 12084] Re: Advise on implementation

Olivier Dugeon olivier.dugeon at orange.com
Tue Mar 3 17:35:02 GMT 2015


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.






More information about the Quagga-dev mailing list