[erlang-questions] diameter callback module

[S X]

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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130415/5f253b01/attachment.htm>