[erlang-questions] diameter callback module

[S X]

Thanks a lot for your comments.

The diameter:call function allows to send extra arguments. It works fine
after changing the callback function signatures accordingly. This is very
useful when I want to notify the other process to do the next thing.

Before sending a diameter message, we call diameter:add_transport to
connect to a peer and peform CER/CEA capability information exchange. On
the caller side, let's say the client callback module, the peer_up will be
invoked when CER/CEA is completed. Why it doesn't have the similar
mechanism like diameter:call to allow insert additional arguments so we can
utilize them, for example, notify the others to send diameter messages?

diameter:add_transport is a sync call, but it doesn't mean you can send
diameter messages successfully when the function returns, i.e. it usually
gets {error, no_connection} or { error, timeout }(this might because of the
server side) if you call diameter:call right after diameter:add_transport.

So is there any reason why not allowing to add additional arguments and use
them in peer_up callback function? Since it means capability exchange is
done and the peer is ready, at this point it should be safe to send
diameter messages to the peer.

Any suggestions?

Thanks!

Samuel


On Tue, Apr 16, 2013 at 7:22 AM, Anders Svensson <anders.otp@REDACTED>wrote:

> On Sun, Apr 14, 2013 at 7: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.
>
> diameter doesn't know anything about your client process. If you want
> a callback to be able to contact the client process associated with
> the service in question (ie. the service whose name the callback gets
> as an argument) then you need to give the callback the means to do so.
> One way would be to map the service name to your process (eg. it's the
> registered name of your client process), another would be to pass some
> identification as extra arguments to the callbacks. (Eg. {module,
> [client_cb_ccra, X]} in the config above.)
>
> > 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.
>
> You can do that, but what is it you're trying to accomplish? if it's
> handle_answer that's supposed to communicate something then it already
> does: the return value of handle_answer is returned by diameter:call.
>
> > 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.
>
> Not sure what you mean here. There's no way for your client to send
> the server anything other than a Diameter message.
>
> > 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,
>
> The arity of your callback probably doesn't agree with the number of
> extra arguments you've specified: prepare_request will also get your
> extra arguments.
>
>
> >{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?
>
> Not sure I understand what problem it is you're trying to solve.
> Multiple processes invoking diameter:call is nothing strange. You
> typically just return something useful (eg. the answer message from
> the peer) from handle_answer, which diameter:call then returns for the
> caller to deal with.
>
> Anders
>
>
> > Thanks a lot!
> >
> > Samuel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130424/94b7c73c/attachment.htm>