From 2d540b95755a6f628b0cfc5a9bab4ff41046fe4b Mon Sep 17 00:00:00 2001 From: Anders Svensson Date: Thu, 24 Aug 2017 11:51:44 +0200 Subject: Rename type evaluable -> eval Export the old type as a synonym for backwards compatability. The name evaluable is a bit too awkward. --- lib/diameter/doc/src/diameter.xml | 30 +++++++++++++++--------------- lib/diameter/doc/src/diameter_app.xml | 9 +++++---- lib/diameter/doc/src/seealso.ent | 4 ++-- 3 files changed, 22 insertions(+), 21 deletions(-) (limited to 'lib/diameter/doc/src') diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml index 264dbf9152..6a4a7b9f7c 100644 --- a/lib/diameter/doc/src/diameter.xml +++ b/lib/diameter/doc/src/diameter.xml @@ -397,10 +397,10 @@ from the peer offers it.

Note that each tuple communicates one or more AVP values. It is an error to specify duplicate tuples.

- + -evaluable() = {M,F,A} | fun() | [evaluable() | A] +eval() = {M,F,A} | fun() | [eval() | A]

An expression that can be evaluated as a function in the following @@ -418,7 +418,7 @@ eval(F) ->

-Applying an &evaluable; +Applying an &eval; E to an argument list A is meant in the sense of eval([E|A]).

@@ -484,11 +484,11 @@ Matches only those peers whose Origin-Realm has the specified value, or all peers if the atom any.

 -{eval, &evaluable;} +{eval, &eval;}

Matches only those peers for which the specified -&evaluable; returns +&eval; returns true when applied to the connection's diameter_caps record. Any other return value or exception is equivalent to false.

@@ -650,7 +650,7 @@ Result = ResultCode | {capabilities_cb, CB, ResultCode|discard} Caps = #diameter_caps{} Pkt = #diameter_packet{} ResultCode = integer() -CB = &evaluable; +CB = &eval;

@@ -843,7 +843,7 @@ Length field in a Diameter Header.

| node | nodes | [node()] - | evaluable()} + | eval()}

The degree to which the service allows multiple transport @@ -854,7 +854,7 @@ at capabilities exchange.

If [node()] then a connection is rejected if another already exists on any of the specified nodes. Types false, node, nodes and -&evaluable; are equivalent to +&eval; are equivalent to [], [node()], [node()|nodes()] and the evaluated value respectively, evaluation of each expression taking place whenever a new connection is to be established. @@ -869,7 +869,7 @@ by their own peer and watchdog state machines.

Defaults to nodes.

 -{sequence, {H,N} | &evaluable;} +{sequence, {H,N} | &eval;}

A constant value H for the topmost 32-N bits of @@ -904,7 +904,7 @@ outgoing requests.

 -{share_peers, boolean() | [node()] | evaluable()} +{share_peers, boolean() | [node()] | eval()}

Nodes to which peer connections established on the local @@ -917,7 +917,7 @@ configured to use them: see use_shared_peers below.

If false then peers are not shared. If [node()] then peers are shared with the specified list of nodes. -If evaluable() then peers are shared with the nodes returned +If eval() then peers are shared with the nodes returned by the specified function, evaluated whenever a peer connection becomes available or a remote service requests information about local connections. @@ -1073,7 +1073,7 @@ omitted counters are not returned by &service_info;.

 -{use_shared_peers, boolean() | [node()] | evaluable()} +{use_shared_peers, boolean() | [node()] | eval()}

Nodes from which communicated peers are made available in @@ -1083,7 +1083,7 @@ the remote candidates list of &app_pick_peer; callbacks.

If false then remote peers are not used. If [node()] then only peers from the specified list of nodes are used. -If evaluable() then only peers returned by the specified +If eval() then only peers returned by the specified function are used, evaluated whenever a remote service communicates information about an available peer connection. The value true is equivalent to fun &nodes;. @@ -1155,7 +1155,7 @@ TLS is desired over TCP as implemented by &man_tcp;.

 -{capabilities_cb, &evaluable;} +{capabilities_cb, &eval;}

Callback invoked upon reception of CER/CEA during capabilities @@ -1249,7 +1249,7 @@ transport.

 -{disconnect_cb, &evaluable;} +{disconnect_cb, &eval;}

Callback invoked prior to terminating the transport process of a diff --git a/lib/diameter/doc/src/diameter_app.xml b/lib/diameter/doc/src/diameter_app.xml index dfcd00975b..aa334beb21 100644 --- a/lib/diameter/doc/src/diameter_app.xml +++ b/lib/diameter/doc/src/diameter_app.xml @@ -13,7 +13,8 @@

-20112016 +2011 +2017 Ericsson AB. All Rights Reserved. @@ -319,7 +320,7 @@ or &peer_down; callback.

Action = Send | Discard | {eval_packet, Action, PostF} Send = {send, &packet; | &message;} Discard = {discard, Reason} | discard -PostF = &mod_evaluable;} +PostF = &mod_eval;}

@@ -371,7 +372,7 @@ discarded}.

Action = Send | Discard | {eval_packet, Action, PostF} Send = {send, &packet; | &message;} Discard = {discard, Reason} | discard -PostF = &mod_evaluable;} +PostF = &mod_eval;}

@@ -478,7 +479,7 @@ not selected.

| {answer_message, 3000..3999|5000..5999} | {protocol_error, 3000..3999} Opt = &mod_call_opt; -PostF = &mod_evaluable; +PostF = &mod_eval;

diff --git a/lib/diameter/doc/src/seealso.ent b/lib/diameter/doc/src/seealso.ent index e5c284c6e8..ef6af1a3d0 100644 --- a/lib/diameter/doc/src/seealso.ent +++ b/lib/diameter/doc/src/seealso.ent @@ -4,7 +4,7 @@ %CopyrightBegin% -Copyright Ericsson AB 2012-2015. All Rights Reserved. +Copyright Ericsson AB 2012-2017. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. @@ -53,7 +53,7 @@ significant. diameter:application_opt()'> diameter:call_opt()'> diameter:capability()'> -diameter:evaluable()'> +diameter:eval()'> diameter:peer_filter()'> diameter:service_event()'> diameter:service_event_info()'> -- cgit v1.2.3 From 5f3becaddef9b18c81a1ec8bd7bf955384c1a225 Mon Sep 17 00:00:00 2001 From: Anders Svensson Date: Wed, 23 Aug 2017 12:21:14 +0200 Subject: Let a service configure default transport options Only a default spawn_opt has been possible to configure, but there's no reason why most others should need to be configured per transport. Those options that still only make sense on a transport are transport_module/config (because of the semantics of multiple values), applications/capabilities (since these override service options), and private (since it's only to allow user-specific options in a backwards compatible way). --- lib/diameter/doc/src/diameter.xml | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) (limited to 'lib/diameter/doc/src') diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml index 6a4a7b9f7c..8d39b9efce 100644 --- a/lib/diameter/doc/src/diameter.xml +++ b/lib/diameter/doc/src/diameter.xml @@ -943,18 +943,6 @@ of a single Diameter node across multiple Erlang nodes.

-{spawn_opt, [term()]} - -

-Options list passed to &spawn_opt; when spawning a process for an -incoming Diameter request, unless the transport in question -specifies another value. -Options monitor and link are ignored.

- -

-Defaults to the empty list.

- - {strict_arities, boolean() | encode @@ -1108,6 +1096,15 @@ each node from which requests are sent.

+&transport_opt; + +

+Any transport option except applications or +capabilities. +Used as defaults for transport configuration, values passed to +&add_transport; overriding values configured on the service.

+ + @@ -1406,7 +1403,7 @@ incoming Diameter request. Options monitor and link are ignored.

-Defaults to the list configured on the service if not specified.

+Defaults to the empty list.

-- cgit v1.2.3 From b0582c6963f6dc203f05ed810c9446cf3fa0f0ae Mon Sep 17 00:00:00 2001 From: Anders Svensson Date: Thu, 24 Aug 2017 13:21:28 +0200 Subject: Let strict_mbit and incoming_maxlen be configured per transport Since these can make sense per peer. The remaining service-only options either belong there or make little sense being configured per transport. --- lib/diameter/doc/src/diameter.xml | 112 +++++++++++++++++++------------------- 1 file changed, 56 insertions(+), 56 deletions(-) (limited to 'lib/diameter/doc/src') diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml index 8d39b9efce..30a26ed845 100644 --- a/lib/diameter/doc/src/diameter.xml +++ b/lib/diameter/doc/src/diameter.xml @@ -826,19 +826,6 @@ field of diameter_packet records independently of - -{incoming_maxlen, 0..16777215} - -

-Bound on the expected size of incoming Diameter messages. -Messages larger than the specified number of bytes are discarded.

- -

-Defaults to 16777215, the maximum value of the 24-bit Message -Length field in a Diameter Header.

- - - {restrict_connections, false | node | nodes @@ -974,49 +961,6 @@ of arity 1 as bare values, not wrapped in a list.

- -{strict_mbit, boolean()} - -

-Whether or not to regard an AVP setting the M-bit as erroneous when -the command grammar in question does not explicitly allow the AVP. -If true then such AVPs are regarded as 5001 errors, -DIAMETER_AVP_UNSUPPORTED. -If false then the M-bit is ignored and policing -it becomes the receiver's responsibility.

- -

-Defaults to true.

- - -

-RFC 6733 is unclear about the semantics of the M-bit. -One the one hand, the CCF specification in section 3.2 documents AVP -in a command grammar as meaning any arbitrary AVP; on the -other hand, 1.3.4 states that AVPs setting the M-bit cannot be added -to an existing command: the modified command must instead be -placed in a new Diameter application.

-

-The reason for the latter is presumably interoperability: -allowing arbitrary AVPs setting the M-bit in a command makes its -interpretation implementation-dependent, since there's no -guarantee that all implementations will understand the same set of -arbitrary AVPs in the context of a given command. -However, interpreting AVP in a command grammar as any -AVP, regardless of M-bit, renders 1.3.4 meaningless, since the receiver -can simply ignore any AVP it thinks isn't relevant, regardless of the -sender's intent.

-

-Beware of confusing mandatory in the sense of the M-bit with mandatory -in the sense of the command grammar. -The former is a semantic requirement: that the receiver understand the -semantics of the AVP in the context in question. -The latter is a syntactic requirement: whether or not the AVP must -occur in the message in question.

- - - - {string_decode, boolean()} @@ -1345,6 +1289,19 @@ connection.

Defaults to 5000.

 + +{incoming_maxlen, 0..16777215} + +

+Bound on the expected size of incoming Diameter messages. +Messages larger than the specified number of bytes are discarded.

+ +

+Defaults to 16777215, the maximum value of the 24-bit Message +Length field in a Diameter Header.

+ + + {length_errors, exit|handle|discard} @@ -1420,6 +1377,49 @@ Changing this results in non-standard behaviour, but can be useful in case peers are known to be behave badly.

 + +{strict_mbit, boolean()} + +

+Whether or not to regard an AVP setting the M-bit as erroneous when +the command grammar in question does not explicitly allow the AVP. +If true then such AVPs are regarded as 5001 errors, +DIAMETER_AVP_UNSUPPORTED. +If false then the M-bit is ignored and policing +it becomes the receiver's responsibility.

+ +

+Defaults to true.

+ + +

+RFC 6733 is unclear about the semantics of the M-bit. +One the one hand, the CCF specification in section 3.2 documents AVP +in a command grammar as meaning any arbitrary AVP; on the +other hand, 1.3.4 states that AVPs setting the M-bit cannot be added +to an existing command: the modified command must instead be +placed in a new Diameter application.

+

+The reason for the latter is presumably interoperability: +allowing arbitrary AVPs setting the M-bit in a command makes its +interpretation implementation-dependent, since there's no +guarantee that all implementations will understand the same set of +arbitrary AVPs in the context of a given command. +However, interpreting AVP in a command grammar as any +AVP, regardless of M-bit, renders 1.3.4 meaningless, since the receiver +can simply ignore any AVP it thinks isn't relevant, regardless of the +sender's intent.

+

+Beware of confusing mandatory in the sense of the M-bit with mandatory +in the sense of the command grammar. +The former is a semantic requirement: that the receiver understand the +semantics of the AVP in the context in question. +The latter is a syntactic requirement: whether or not the AVP must +occur in the message in question.

+ + + + {transport_config, term()} {transport_config, term(), &dict_Unsigned32; | infinity} -- cgit v1.2.3