Thank you very much. This information is very helpful. Kudos on the excellent high-level and devel documentation as well. All open source projects should aim to be as developer-friendly (even though it is in C++). :)
On Tue, May 12, 2009 at 2:49 PM, Bruce Simpson <[email protected]> wrote: > pmv wrote: > >> Good day. >> >> At the moment, b) is probably the cleanest solution overall. If it >> is a simple matter of looking up the MFEA VIF index based on a VIF >> name, then please feel free to submit a patch which exposes >> ProtoNode<V>::vif_find_by_name() via an XRL. >> >> >> Will do, thanks. >> >> Another thing. Does an IGMP XRL client need to register with finder as a >> target, or would adding XrlStdRouter handlers for >> 'mld6igmp_client/0.1/add_membership4' (and others) and calling >> XrlMld6igmpV0p1Client::send_add_protocol4() be enough? >> > > You need to do a bit more work in a XORP process to implement an XRL target > instead of just sending XRLs. An XrlStdRouter instance is enough to send > XRLs, but not to receive them. For an example, look at the OLSR code: > > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/xorp_olsr.cc?rev=1.4 > > ...here, in OLSR's main() function, the XrlStdRouter instance is created > before the XrlOlsr4Target instance, because its constructor needs to see an > XrlRouter instance. The XrlOlsr4Target class is a proxy which glues the > implementation to the XRL layer. It is automatically generated from the > xrl/targets/olsr4.tgt file. > > Assuming you write a .tgt file for your process's XRL target, and add > handlers for the mld6igmp_client XIF, as with any other XORP component, the > Finder should be notified of the registration when your process starts. Feel > free to use the contrib/olsr code as a reference. > > One of the shortcomings of using the GNU Autotools build system is that > you cannot implement new XRL targets without actually adding them to the top > level xrl/ directory. I managed to overcome this limitation in Jam and > Boost.Build when developing OLSR, but that is not officially supported, and > it is likely the Jamfiles will go away in future. My understanding is that > we plan to switch to a new Python-based build tool, SCons, which should > eliminate this tedious and inconvenient step. > > If you want to build your application using XORP 1.6, then you will need > to add your .tgt and .xif files to the global xrl/ directory, together with > the relevant entries in Makefile.am. It is entirely likely that XRL may > change greatly in future for this and other reasons. > > >> Some background information: >> The MFEA code is very tied to the BSD MROUTING kernel multicast >> forwarding code -- and the VIF indexes in the MFEA aren't directly >> related to the FEA's notion of a VIF; they aren't redundant, as >> such, they are different identifiers. >> >> >> If that is the case, which should take precedence? Which should be >> authority for vif indeces, or furthermore between vif names and indeces? Are >> there specific situations in which this should be a consideration? >> > > I would rely on the MFEA for this mapping. > > XORP client processes should never use interface indexes directly; MFEA VIF > indexes are entirely separate from any other notion of interface names or > indexes, only the MFEA knows about them. > > Unfortunately, in extending IGMP, you've found a weak spot in the API where > the MFEA VIF index has to be exposed for the XRLs to be useful. Up until > now, this hasn't been an issue, because normally only PIM and IGMP interact > with the MFEA directly. > > >> >> In MROUTING, a VIF index is what's found in the 'struct mfcctl2' >> structure used to configure multicast forwarding, and I believe >> this is what the MFEA is dealing with internally >> >> ... > >> >> There are platforms (e.g. Windows) where the multicast forwarding >> plane is configured in a completely different way, and the MFEA >> wouldn't be suitable for driving it without significant code >> refactoring. >> >> >> So portability might be an issue then? I mostly work on FreeBSD >> exclusively. >> > > I wouldn't worry about it for now, although it is a hairy issue for the > future which needs to be carefully considered. > > It is something we would need to revisit if the MFEA is refactored to > support multicast forwarding planes other than MROUTING, but it shouldn't > impact ongoing work with XORP on FreeBSD, as Linux suffers from the same > issue. > > You can regard the multicast forwarding plane on FreeBSD and Linux as > working more or less identically. Even though the Linux code is not directly > derived from the 4.4BSD implementation (it is a clean-room GPLv2 > re-implementation), it is functionally identical, and the kernel APIs are > more or less identical. > > thanks, > BMS > -- pmv PGP keyID 0xEA5EB160
_______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
