[erlang-questions] DIAMETER: sharing connections between applications

Umberto Corponi umberto.corponi@REDACTED
Tue Jan 26 15:54:41 CET 2016


I think this service_opt() may be what you are looking for:

*{restrict_connections, false | node | nodes | [node()] | evaluable()}*

The degree to which the service allows multiple transport connections to
the same peer, as identified by its Origin-Host at capabilities
exchange. Defaults to nodes.

In any case the same transport connection can support seamlessly more
than one application.
The correct callback will be invoked depending on the application-id of
the messages,
so if it is not required for some other reason, one transport connection
should be enough.

If separated transport connections are still a requirement in your case,
may i ask you why? Just curious...

Regards,
Umberto


On 01/26/2016 10:49 AM, Andreas Schultz wrote:
> Hi,
>
> I have a problem where a transport connection between client
> should be shared by multiple DIAMETER application. It does work
> when the transport is added once, but when I add the a transport
> for the same destination twice with different application restrictions,
> the connection will not be established and the error event will
> contain bogus error reasons.
>
> The following example is a bit contrived, but reflects the real
> use case as close as possible.
>
> start() ->
>     SvcName = ?MODULE,
>     SvcOpts = [{'Origin-Host', <<"host.local">>},
> 	       {'Origin-Realm', <<"realm.local">>},
> 	       {'Origin-State-Id', diameter:origin_state_id()},
> 	       {'Host-IP-Address', [{127,0,0,1}]},
> 	       {'Vendor-Id', 1234},
> 	       {'Product-Name', "Client"},
> 	       {'Auth-Application-Id', [1, 4]},
> 	       {string_decode, false},
> 	       {application, [{alias, nas},
> 			      {dictionary, rfc4005_nas},
> 			      {module, nas_cb}]},
> 	       {application, [{alias, cc},
> 			      {dictionary, rfc4006_cc},
> 			      {module, cc_cb}]}],
>
>     diameter:subscribe(SvcName),
>
>     ok = diameter:start_service(SvcName, SvcOpts),
>
>     TransportOpts = [{transport_module, diameter_sctp},
>                      {transport_config, [{raddr, {127,0,0,1}},
> 		                         {rport, 1234}]}],
>
>     {ok, _} = diameter:add_transport(SvcName, {connect, [{applications, [1]} | TransportOpts]}),
>     {ok, _} = diameter:add_transport(SvcName, {connect, [{applications, [4]} | TransportOpts]}),
>
>     ok.
>
> This sample will fail to establish the connections if the remote side
> supports only one of the applications and report an diameter event:
>
> #diameter_event{
>     info =
>         {closed,#Ref<0.0.8.1>,
>             {'CEA',
>                 #diameter_base_CEA{ ... },
>                 #diameter_service{ ... },
>                 diameter_gen_base_rfc3588,
>                 {app_not_configured,4}},
> ...
> }
>
> The value for 'app_not_configured' is bogus and contains either 1 or 4 in
> this example and has no relation to what the other side supports.
>
> The sample works when I'm call the add_transport only once without application
> restriction.
>
> According to the documentation, the 'applications' options will restrict the
> transport to the specified id. So why does it acct like are 'require'
> when used with multiple add_transport?
>
> Andreas 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
Umberto Corponi
Athonet




More information about the erlang-questions mailing list