[erlang-questions] diameter callback module

[André Graf]

We use a registered gen_server process for that.


On 16 April 2013 05:51, S X <erlangprogram@REDACTED> wrote:
> Maybe using registered process PID can handle the notifications across
> different modules. Not sue it is a good practice or not.
>
>
>
>
> On Mon, Apr 15, 2013 at 5:02 PM, S X <erlangprogram@REDACTED> wrote:
>>
>> I think the first question is clear. The diameter library maintains the
>> diameter_app callback module properly with each client calling process.  In
>> erlang, each process behaves like an object comparing with the OO
>> programming language. On the other hand, in order to deliver variables, has
>> to pass the values through a series of function calls or through message
>> box. Sometimes it is bit difficult to organize the code nicely.
>>
>> But how to establish a nice notification mechanism, i.e. when the
>> diameter_app callback module "client_cb_ccra" receives the response from the
>> diameter server, how to notify the master process? By using ets table or
>> some generic behaviours?
>>
>> Thanks,
>>
>> Samuel
>>
>>
>> On Sun, Apr 14, 2013 at 1:01 PM, S X <erlangprogram@REDACTED> wrote:
>>>
>>> Hello,
>>>
>>> Based on the erlang diameter library and the sample code, I want to start
>>> multiple diameter client processes in one erlang node(one client IP), and
>>> the client needs to define a diameter_app callback module for certain
>>> application, for example:
>>>
>>> -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".example.com"},
>>>                         {'Origin-Realm', "example.com"},
>>>                         {'Vendor-Id', 193},
>>>                         {'Product-Name', "Client"},
>>>                         {'Auth-Application-Id', [?DIAMETER_APP_ID_COMMON,
>>> ?DIAMETER_APP_ID_CCRA]},
>>>                         {application, [{alias, ?APP_CCR_ALIAS},
>>>                                        {dictionary, ?DIAMETER_DICT_CCRA},
>>>                                        {module, client_cb_ccra}]}]).
>>>
>>>
>>> First question:
>>> how the diameter library handles this situation? Will all diameter client
>>> processes share one single diameter_app callback module "client_cb_ccra" or
>>> it will automatically attach different instance of the callback module
>>> (process) to the different client process by using spawn_monitor? So from
>>> the callback handle_answer in "client_cb_ccra" I can notify the proper
>>> client proce by just calling client:notify() something.
>>>
>>> Second question:
>>> Notice that diameter:call allows to set extra arguments, so I was
>>> wondering I could set some data like:
>>> diameter:call(Name, ?APP_CCR_ALIAS, CCR, [{extra, [self()]}]).
>>> which sets the client process ID and I hope to deliver to the callback
>>> module "client_cb_ccra" and when the callback module knows which client
>>> process sends request and response accordingly, for example using the client
>>> process ID in the callback function handle_answer.
>>> However, I don't want pack the extra arguments into the diameter packet
>>> since the diameter server doesn't know what they are and the extra ones are
>>> not part of standard diameter packet.
>>>
>>> Now I changed the pick_peer callback signatures to allow extra arguments,
>>> pick_peer([Peer | _], _, _SvcName, _State, A)
>>>
>>> But I got encoding error in the callback prepare_request
>>>
>>> =ERROR REPORT==== 14-Apr-2013::11:40:41 ===
>>> Error in process <0.175.0> with exit value:
>>> {undef,[{client_cb_ccra,prepare_request,[{diameter_packet,{diameter_header,1,undefined,undefined,undefined,3958849953,3958849953,undefined,undefined,undefined,undefined},undefined,{diameter_rfc4006_cc_CCR,["who",";","142745567...
>>>
>>> {error,encode}
>>>
>>> In overall, I read the online documents, which have limited information
>>> on how to use the extra arguments in the library and  don't quite get how to
>>> utilize the extra arguments to do something tricky,
>>>
>>> Are there any suggestions on how to deal with multiple client processes?
>>>
>>> Thanks a lot!
>>>
>>> Samuel
>>>
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>