<div dir="ltr"><div><div><div><div><div><div>Thanks a lot for your comments.<br><br></div>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.<br>
<br></div>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? <br>
<br>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.<br>
<br></div>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.<br>
<br></div>Any suggestions?<br><br></div>Thanks!<br><br></div>Samuel<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 7:22 AM, Anders Svensson <span dir="ltr"><<a href="mailto:anders.otp@gmail.com" target="_blank">anders.otp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Apr 14, 2013 at 7:01 PM, S X <<a href="mailto:erlangprogram@gmail.com">erlangprogram@gmail.com</a>> wrote:<br>
</div><div class="im">> Hello,<br>
><br>
> Based on the erlang diameter library and the sample code, I want to start<br>
> multiple diameter client processes in one erlang node(one client IP), and<br>
> the client needs to define a diameter_app callback module for certain<br>
> application, for example:<br>
><br>
> -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".<a href="http://example.com" target="_blank">example.com</a>"},<br>
> {'Origin-Realm', "<a href="http://example.com" target="_blank">example.com</a>"},<br>
> {'Vendor-Id', 193},<br>
> {'Product-Name', "Client"},<br>
> {'Auth-Application-Id', [?DIAMETER_APP_ID_COMMON,<br>
> ?DIAMETER_APP_ID_CCRA]},<br>
> {application, [{alias, ?APP_CCR_ALIAS},<br>
> {dictionary, ?DIAMETER_DICT_CCRA},<br>
> {module, client_cb_ccra}]}]).<br>
><br>
><br>
> First question:<br>
> how the diameter library handles this situation? Will all diameter client<br>
> processes share one single diameter_app callback module "client_cb_ccra" or<br>
> it will automatically attach different instance of the callback module<br>
> (process) to the different client process by using spawn_monitor? So from<br>
> the callback handle_answer in "client_cb_ccra" I can notify the proper<br>
> client proce by just calling client:notify() something.<br>
<br>
</div>diameter doesn't know anything about your client process. If you want<br>
a callback to be able to contact the client process associated with<br>
the service in question (ie. the service whose name the callback gets<br>
as an argument) then you need to give the callback the means to do so.<br>
One way would be to map the service name to your process (eg. it's the<br>
registered name of your client process), another would be to pass some<br>
identification as extra arguments to the callbacks. (Eg. {module,<br>
[client_cb_ccra, X]} in the config above.)<br>
<div class="im"><br>
> Second question:<br>
> Notice that diameter:call allows to set extra arguments, so I was wondering<br>
> I could set some data like:<br>
> diameter:call(Name, ?APP_CCR_ALIAS, CCR, [{extra, [self()]}]).<br>
> which sets the client process ID and I hope to deliver to the callback<br>
> module "client_cb_ccra" and when the callback module knows which client<br>
> process sends request and response accordingly, for example using the client<br>
> process ID in the callback function handle_answer.<br>
<br>
</div>You can do that, but what is it you're trying to accomplish? if it's<br>
handle_answer that's supposed to communicate something then it already<br>
does: the return value of handle_answer is returned by diameter:call.<br>
<div class="im"><br>
> However, I don't want pack the extra arguments into the diameter packet<br>
> since the diameter server doesn't know what they are and the extra ones are<br>
> not part of standard diameter packet.<br>
<br>
</div>Not sure what you mean here. There's no way for your client to send<br>
the server anything other than a Diameter message.<br>
<div class="im"><br>
> Now I changed the pick_peer callback signatures to allow extra arguments,<br>
> pick_peer([Peer | _], _, _SvcName, _State, A)<br>
><br>
> But I got encoding error in the callback prepare_request<br>
><br>
> =ERROR REPORT==== 14-Apr-2013::11:40:41 ===<br>
> Error in process <0.175.0> with exit value:<br>
> {undef,[{client_cb_ccra,prepare_request,[{diameter_packet,<br>
<br>
</div>The arity of your callback probably doesn't agree with the number of<br>
extra arguments you've specified: prepare_request will also get your<br>
extra arguments.<br>
<div class="im"><br>
>{diameter_header,1,undefined,undefined,undefined,3958849953,3958849953,undefined,undefined,undefined,undefined},undefined,{diameter_rfc4006_cc_CCR,["who",";","142745567...<br>
><br>
> {error,encode}<br>
><br>
> In overall, I read the online documents, which have limited information on<br>
> how to use the extra arguments in the library and don't quite get how to<br>
> utilize the extra arguments to do something tricky,<br>
><br>
> Are there any suggestions on how to deal with multiple client processes?<br>
<br>
</div>Not sure I understand what problem it is you're trying to solve.<br>
Multiple processes invoking diameter:call is nothing strange. You<br>
typically just return something useful (eg. the answer message from<br>
the peer) from handle_answer, which diameter:call then returns for the<br>
caller to deal with.<br>
<br>
Anders<br>
<br>
<br>
> Thanks a lot!<br>
><br>
> Samuel<br>
><br>
</blockquote></div><br></div>