rewrite eradius #241
rewrite eradius #241
Conversation
RoadRunnr
force-pushed
the
feature/next-major
branch
from
0ab0e31
to
e6f81cb
Compare
Seperate concerns better. Socket managing is not in the mngr module, while the sending logic is in the client module.
There was no logic in place to remove entries from the pending registry once the timeout hits. The client side timeout would only handle re-transmission, but not the cleanup. Move the timeout logic to the sender and let it also cleanup the pending registry.
Fully prepare client suite for full IPv6 support and add some minor tweaks to the others to move them closer to IPv6 support.
RoadRunnr
force-pushed
the
feature/next-major
branch
from
e6f81cb
to
a2c9a75
Compare
Was it approved for the use-cases where it was is used?
What does it give? The projects that are using old configuration need to have adjustments to handle previous eradius configuration by themselves (or to completely change/remove it what is not always possible) and to call API instead of eradius did it automatically (start servers/clients 'manually' via API). What is the purpose of it? To have some ability to do things in runtime? The old version reconfigure API, why not to add API/wrappers around set_env like add_server,remove_server and so on but break the behaviour? |
RoadRunnr
force-pushed
the
feature/next-major
branch
3 times, most recently
from
022331f
to
dc3bc8e
Compare
There is no need to move existing use-case to the new code. If there is something that uses proxing, it can continue to use the old version.
Again, existing projects can stay with the version they are using. There is nothing that forces them to move. |
RoadRunnr
force-pushed
the
feature/next-major
branch
2 times, most recently
from
ec43b3c
to
5a4066d
Compare
| }. | ||
| %% Options to configure the RADIUS server UDP socket. | ||
|
|
||
| -type socket_config() :: #{family := inet | inet6, |
There was a problem hiding this comment.
This looks the same as socket_opts().
Why have both? (Pease keep socket_config() if one is enough)
There was a problem hiding this comment.
no, they are different. In socket_opts() all map entries are optional, in socket_config() some keys are mandatory.
It is not too obvious, but using := vs. => in map type specs make a difference.
|
|
||
| %% @private | ||
| handle_cast(_Msg, State) -> | ||
| {noreply, State}. |
There was a problem hiding this comment.
Perhaps log that something unexpected was casted?
There was a problem hiding this comment.
Nothing is casting anything to the server. The method is only there because the gen_server behavior mandates it.
v3 rewrite of eradius, major changes: * clients and servers are now started and configured through APIs, not app env settings any more * IPv6 support * supports multiple server and client instances * metrics are optional and callback based (allows the easy use of other metrics frameworks) * distributed handlers are no longer support, use erpc to replicate in use case specific code if needed. * removed proxy support (use freeradius or similar instead)
RoadRunnr
force-pushed
the
feature/next-major
branch
from
5a4066d
to
1ff6c00
Compare
v3 rewrite of eradius, major changes:
app env settings any more
metrics frameworks)
use case specific code if needed.