Tuesday, March 11, 2008

gen_fsm

Diameter client and server examples are now the applications under the name diameter_client and diameter_server respectively. Both of them are implemented using two processes: one of them using the gen_fsm behaviour and another one using the gen_server behaviour to handle the transport connection.

The applications may be configured (address and port) by editing their application (diameter_client.app/diameter_server.app) file. To start any of the applications it is required to start diameter application previously to provide the capability to encode/decode messages.

At the moment, only a small subset of the peer state machine in RFC3588 has been implemented so more effort will be put to be as compliant as possible with this state machine and to improve diameter stack to handle basic error cases such as avp/command definition not found.

Wednesday, March 5, 2008

application

With a little more effort, diameterl has become an application. Now diameter stack must be started as any other OTP application:
application:load(diameter).
aplication:start(diameter).

and stopped the same way:
application:unload(diameter).
application:stop(diameter).

Now development will focus on the improvement of the diameter_client and diameter_server examples using gen_fsm and gen_server to implement the diameter peer state machine as defined in RF3588.

Tuesday, March 4, 2008

gen_server

Some changes were commited yesterday. Probably the most important is that definition servers are now implemented using gen_server behaviour. It was really easy to change the plain Erlang approach to the OTP based one so there is no reason to have any fear of OTP.

In addition to this, diameter module is now implemented using the supervisor behaviour. Functionality has not changed, but at least the foundations to take advantage of OTP have been laid. The statements to test the examples are now:
diameter:start_link().
PidC = diameter_client:start().
PidS = diameter_server:start().

Other minor changes are:
  • Encoded command headers now have different End-To-End-Id and Hop-By-Hop-Id. Previously they were just set to 0, which is not compliant with RFC3588.
  • Encoded command contents are now printed so it's easier to debug looking at the messages that are being send and received.