[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-devel
Subject:    Re: Ongoing re-architecture
From:       Arran Cudbard-Bell <a.cudbardb () freeradius ! org>
Date:       2015-11-16 16:39:50
Message-ID: E4746D44-F006-44F3-B625-F7611DC64D69 () freeradius ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> On 16 Nov 2015, at 08:55, Alan DeKok <aland@deployingradius.com> wrote:
> 
> For people watching github... there's been a flurry of changes to the code in the \
> last few weeks.  This is all necessary for future expansion of the server. 
> Arran has updated the way the dictionary API handles attributes.   Previously, it \
> assumed that all attributes could be packet into a 32-bit integer... via a terrible \
> packing scheme.  The idea at the time was that you could address any attribute at \
> compile-time via a magic number.

Now they're all in a very large tree structure.

> That functionality was never used.  Worse, it prevented us from having TLVs nested \
> more than 4 layers, and made other work harder.  So it's been removed.

Users of the internal APIs should no longer use fr_dict_attr_by_num, except for top \
level VSA and RFC attributes.

If you need to access a TLV navigate the relationships from the dictionary root.

fr_dict_attr_t const *da;

da = fr_dict_attr_child_by_num(fr_dict_root(fr_main_dict), PW_VENDOR_SPECIFIC);
da = fr_dict_attr_child_by_num(da, MY_FAVOURITE_VENDOR);
da = fr_dict_attr_child_by_num(da, 1);
da = fr_dict_attr_child_by_num(da, 2);

Or use fr_dict_attr_by_name() which works as before (all attribute names are in the \
same namespace).

Removing the packing allows parent/child relationships between attribute numbers of \
greater than 8bits.

> Attributes can now be nested to almost any depth.  After about 20, though, it \
> starts getting silly.

This allows us to represent nested tree structure from other protocols using \
dictionary attributes, you can map SNMP OIDs to RADIUS TLVs for example.   For the \
current RADIUS MIBs that requires a nesting level of 14.

There is a hard limit of 24.  This is mostly for sanity.  The maximum in RADIUS is \
162, but you won't be able to fit many attributes in a packet with that level of \
nesting :)

If the limit needs to be changed in future, it's now just a one line change instead \
of a 10,000 line change *ugh*.

> As a result of the previous change, the RADIUS encoder / decoder was updated.  The \
> decoder didn't change much, as it was already well abstracted.  The encoder was \
> almost completely re-written.  It's now *much* simpler and easier to understand.

The DHCPv4 option Encoder/Decoder were also rewritten in the style of the RADIUS \
Encoder/Decoder to make maintenance easier.  The two protocols are very similar in \
the way attributes are packed, the major differences are the length field in DHCP \
does not include the option header, DHCP supports the concept of value coalescing in \
single options, DHCP doesn't need to deal with WiMAX crap, and DHCP's vendor specific \
options are buried inside a TLV structure.

They both use 8bit attribute space, 8bit lengths, support VSAs (ish in the case of \
DHCP), support TLVs, and use the same packing for TLVs.

> What made this possible was the tests in src/tests.  And the Coverity / clang \
> scans.  So we're sure that the new code works, and has minimal problems.

Yes, the testing framework made this far far easier.  WiMAX must die.

> I've been working on cleaning up the architecture of the server.  Previously, the \
> initialization code was scattered across multiple files, and wasn't very clear.  If \
> you now read radiusd.c, it's pretty clear what gets initialized, and in what order. \
>  There is more to do, of course.  But the goal is a better structure which is \
> easier to maintain, and easier to extend.

The listener registry which is possibly the next part of Alan's work may also allow \
proper hupping of all modules at some point in the future.

-Arran

Arran Cudbard-Bell <a.cudbardb@freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.28
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWSgbWAAoJEP+k1YKfttfK378P/iLmIb5QOpmakmXHJSR1Zz9D
SJj+WVjvQaEchJocQJjGWpHadh7CLRT1vdm1XJeYP8xTNVjrlsQ5a4eAbkUyDO9d
khcXLPwp8rjJa4ShXYkfKp+l7bcnkz/uS8sPbbq14Tlmkia2BjGklhyCPjgvYUCw
A/kQ/ZYd0zAm+Q/p4NEhScG78eKud3FHTYI8m5uUU7m3hemKKM8cdN6+U5jx91qW
R9moPo16VQFIUCpKSvabOSEtdAKjeHDjzanLdnr898i4K6hMi6pYUzSdCsdWyQJQ
iX7UcdnAMO/SnuKIen7pJX2xZXSotpjsvfkzKTkxD8qaQZ8N/0ZUQOuDaOnqYZmU
NcbvTd75wCoHlECzMCTROBPpJYXChGjex7DruWQ99akGcTKx2dfQfcfIO7QY2KbK
Ou2z0Q2crGh1NyX5oL3r4lH4rN5CRqbAQbAffYtk3nMqCedzYb7261vP/eLjBMx+
L+TOX2OLKPZV4yAYElrhI3EUGt7sGjtPu/DMoXPn9CEhj21ZMDbRqEt3VpyT2nxb
K9WKbYGXoRRtQ2PSMs0i999kErNBGmNOqSWjXh5o1W13HZy32JcYWx06XZ1PRZHa
cRAXSlV+p1ozDxGhQyCjjQR3B7qjdIFIVSgrzKYyhzuD42YtVycx+Lpgyr83C2N4
rJHs9+te1hdw13NTj+gM
=x286
-----END PGP SIGNATURE-----

[Attachment #6 (text/plain)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

[prev in list] [next in list] [prev in thread] [next in thread]