After more than a week of work from time to time, the first changes have been committed to the trunk branch.
For now, only basic encoding/decoding implementation capabilities are available. Despite no documentation and few comments are in the code, diameter_client.erl and diameter_server.erl examples are supplied to show how to implement basic clients/servers that exchange their capabilities and later just send watchdog messages to each other. Both of them have been tried to work with each other and with external tools to check that implementation is correct for now.
To test the examples, just run the following statements in your erlang shell:
diameter:start().
PidC = diameter_client:start().
PidS = diameter_server:start().
There are lots of pending things yet, but for a first commit it's fine.
Subscribe to:
Post Comments (Atom)
10 comments:
Good work. Would you like any help? My HSS project needs an Erlang DIAMETER stack.
Thanks for you comment Vance.
Since I'm a newbie in Erlang, it would be nice if you could take a look at the code and let me know if there's something that you would develop in a completely different way.
Javier,
One thing I would do in a completely different way is to implement it as an OTP application. You have used a pure Erlang approach so far which is fine however if you want to use it in a system you would want the support which OTP provides.
I would be happy to wrap it up for you if you are interested. I would refactor the servers as gen_server behaviours and diameter as an application behaviour. I'd add a supervisor as well.
Yes, I agree with you that using OTP is a must. In the next days I'll work on it and publish a new improved version. No need to bother you with this at this time because I have to learn about OTP sooner or later and this is a good opportunity to start.
I look forward for your future comments. Thanks.
Right, that has put a proper OTP structure in place.
I see you stopped short of making diameter.erl an application behaviour. If you had it would look like this:
-module(diameter).
-export([start/2]).
-behaviour(application).
start(normal, _Args) ->
supervisor:start_link({local, diameter_sup}, diameter_sup, []).
With your supervisor in the module supervisor_sup.erl.
Then to start the application you would use:
application:start(diameter).
... or export a start/0 function from diameter.erl to do so.
I am not completely clear on the function of the definition servers. If they are needed to manage dynamic global variables it makes sense to do it the way you have, in gen_servers. Most folks cheat (IMHO) and use ets.
When you use an application behaviour you can define default values for application variables in your .app file and overide them in a sys.config file for a local run. For example:
ebin/diameter.app:
{application, diameter,
[{description, "DIAMETER Stack"},
{env, [{foo, none},{bar, 42}]}]}.
sys.config:
[{diameter, [{foo, 42},{bar, none}]}].
Start the node with the config file:
erl -config sys
Then from within your module you can retrieve the current value with:
{ok, Val} = application:get_env(foo)
Hello Vance. Thanks again for your comments. Last one contains a lot of information that is quite valuable.
Yesterday I worked on converting diameter.erl to an application, but I didn't know about how to write default values in the application file so that's a future improvement that I will take care of.
Regarding the definition servers, yes, they are just big tables that need to be accessed from any process that wants to encode/decode messages.
The idea is to provide some mechanism to extend the definitions using external files. When using Python/Ruby I like to use yaml files because they are quite easy to write, but it doesn't seem to exist any yaml parser for Erlang so probably I'll finally use xml.
The easiest thing to do is to put plain erlang terms into a file and read them with file:consult/1. That is why the sys.config, foo.app, etc. files all have erlang term format.
Yes, I thought on file:consult also; but as far as I know, there is now way to use records so tuples have to be written directly.
Probably is the easiest way, but not the most user-friendly.
Hey, what's going on with the project ? Have you stopped it ?
Thanks for your interest in the project.
I'm afraid that, yes, at the moment the project is stopped.
Post a Comment