aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc
AgeCommit message (Collapse)Author
2016-08-26Fix xmllint errors in documentationAnders Svensson
2016-08-26Remove documentation overkillAnders Svensson
"Defaults to X" isn't clarified by "if unspecified".
2016-06-21Prepare releaseErlang/OTP
2016-06-02Revert "Prepare release"Erlang/OTP
This reverts commit e020f75c10410a6943cd055bfa072a2641eab7da.
2016-06-02Prepare releaseErlang/OTP
2016-05-12Revert "Prepare release"Erlang/OTP
This reverts commit bd64ad8e15d66e48b36dbe3584315dd5cfc8b59a.
2016-05-11Prepare releaseErlang/OTP
2016-05-10Merge branch 'anders/diameter/19.0-rc1/OTP-12913'Anders Svensson
* anders/diameter/19.0-rc1/OTP-12913: vsn -> 1.12 Update appup for 19.0-rc1 Update documentation for CEA/DWA/DPA Result-Code counters
2016-05-09Update documentation for CEA/DWA/DPA Result-Code countersAnders Svensson
Missed in commit d6b3b84a.
2016-03-15update copyright-yearHenrik Nord
2016-03-14Prepare releaseErlang/OTP
2016-01-27Merge branch 'maint-17' into maintAnders Svensson
2016-01-26Update release notesErlang/OTP
2015-12-21Make peer handling more efficientAnders Svensson
Each service process maintains a dictionary of peers, mapping an application alias to a {pid(), #diameter_caps{}} list of connected peers. These lists are potentially large, peers were appended to the end of the list for no particular reason, and these long lists were constructed/deconstructed when filtering them for pick_peer callbacks. Many simultaneous outgoing request could then slow the VM to a crawl, with many scheduled processes mired in list manipulation. The pseudo-dicts are now replaced by plain ets tables. The reason for them was (once upon a time) to have an interface interchangeable with a plain dict for debugging purposes, but strict swapablity hasn't been the case for some time now, and in practice a swap has never taken place. Additional tables mapping Origin-Host/Realm have also been introduced, to minimize the size of the peers lists when peers are filtered on host/realm. For example, a filter like {any, [{all, [realm, host]}, realm]} is probably a very common case: preferring a Destination-Realm/Host match before falling back on Destination-Realm alone. This is now more efficiently (but not equivalently) expressed as {first, [{all, [realm, host]}, realm]} to stop the search when the best match is made, and extracts peers from host/realm tables instead of searching through the list of all peers supporting the application in question. The code to try and start with a lookup isn't exhaustive, and the 'any' filter is still as inefficient as previously.
2015-12-20Update release notesErlang/OTP
2015-12-15Update release notesErlang/OTP
2015-09-21Prepare releaseErlang/OTP
2015-09-21Merge branch 'anders/diameter/18.1/OTP-12978' into maintAnders Svensson
* anders/diameter/18.1/OTP-12978: Remove 1.11 release notes
2015-09-17Remove 1.11 release notesAnders Svensson
These were added manually in merge commit 8c5d719a, but that was wrong: the notes will be generated. Note that OTP-12791 in the comment for commit 5a339bcb is wrong: it's OTP-12891.
2015-09-14Merge branch 'anders/diameter/M-bit/OTP-12947' into maintAnders Svensson
* anders/diameter/M-bit/OTP-12947: Add service_opt() strict_mbit
2015-08-25Add service_opt() strict_mbitAnders Svensson
There are differing opinions on whether or not reception of an arbitrary AVP setting the M-bit is an error. 1.3.4 of RFC 6733 says this about how an existing Diameter application may be modified: o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7). It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. The point here is presumably interoperability: that the command grammar should specify explicitly what mandatory AVPs much be understood, and that anything more is an error. On the other hand, 3.2 says thus about command grammars: avp-name = avp-spec / "AVP" ; The string "AVP" stands for *any* arbitrary AVP ; Name, not otherwise listed in that Command Code ; definition. The inclusion of this string ; is recommended for all CCFs to allow for ; extensibility. This renders 1.3.4 pointless unless "*any* AVP" is qualified by "not setting the M-bit", since the sender can effectively violate 1.3.4 without this necessitating an error at the receiver. If clients add arbitrary AVPs setting the M-bit then request handling becomes more implementation-dependent. The current interpretation in diameter is strict: if a command grammar doesn't explicitly allow an AVP setting the M-bit then reception of such an AVP is regarded as an error. The strict_mbit option now allows this behaviour to be changed, false turning all responsibility for the M-bit over to the user.
2015-08-14Fix broken release notesAnders Svensson
Broken in the parent commit.
2015-08-13Merge branch 'maint-17' into maintAnders Svensson
The diffs are all about adapting to the OTP 18 time interface. The code was previously backwards compatible, falling back on the erlang:now/0 if erlang:monotonic_time/0 is unavailable, but this was seen to be a bad thing in commit 9c0f2f2c. Use of erlang:now/0 is now removed.
2015-08-13Update release notesErlang/OTP
2015-08-04Don't compute AVP list length unnecessarily at AVP decodeAnders Svensson
This has had a hugely negative impact on performance when decoding messages containing many AVP: each decode of an AVP having variable arity computed the length of the list of previously decoded AVPs when checking that the allowed arity was not exceeded, even if the allowed arity was infinite, making for O(n^2) cost. Here are some execution times, for diameter_codec:decode/2 on a representative message with n integer AVPs in the Common application (on the host at hand): Before After ------- --------- n = 1K 5 ms 2 ms n = 10K 500 ms 25 ms n = 100K 75 sec 225 ms n = 1M 2.6 sec Note the nearly linear increase following the change. Remove the dire documentation warning for incoming_maxlen as a consequence. It can still be useful to set, but not doing so won't have the same consequences as previously.
2015-08-04Correct inaccurate docAnders Svensson
The warning report was removed in commit 00584303.
2015-06-23Prepare releaseErlang/OTP
2015-06-22Merge branch 'bruce/change-license'Bruce Yinhe
OTP-12845 * bruce/change-license: fix errors caused by changed line numbers Change license text to APLv2
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-17Fix release note typoAnders Svensson
2015-05-29Update release notesErlang/OTP
2015-05-23Fix mangled release noteAnders Svensson
2015-05-06Prepare releaseErlang/OTP
2015-05-03Add missing doc wordingAnders Svensson
2015-03-31Prepare releaseErlang/OTP
2015-03-27Limit FQDN in DiameterURI to 255 octetsAnders Svensson
As for the port number in the parent commit, a FQDN can't be arbitrarily long, at most 255 octets. Make decode fail if it's more.
2015-03-27Add service_opt() incoming_maxlenAnders Svensson
To bound the length of incoming messages that will be decoded. A message longer than the specified number of bytes is discarded. An incoming_maxlen_exceeded counter is incremented to make note of the occurrence. The motivation is to prevent a sufficiently malicious peer from generating significant load by sending long messages with many AVPs for diameter to decode. The 24-bit message length header accomodates (16#FFFFFF - 20) div 12 = 1398099 Unsigned32 AVPs for example, which the current record-valued decode is too slow with in practice. A bound of 16#FFFF bytes allows for 5461 small AVPs, which is probably more than enough for the majority of applications, but the default is the full 16#FFFFFF.
2015-03-24Minor doc fixAnders Svensson
2015-03-24Merge branch 'anders/diameter/dpr/OTP-12609' into maintAnders Svensson
* anders/diameter/dpr/OTP-12609: Discard incoming/outgoing requests after incoming DPR Add transport_opt() dpr_timeout Be lenient with errors in incoming DPR
2015-03-24Merge branch 'anders/diameter/string_decode/OTP-11952' into maintAnders Svensson
* anders/diameter/string_decode/OTP-11952: Let examples override default service options Set {restrict_connections, false} in example server Set {string_decode, false} in examples Test {string_decode, false} in traffic suite Add service_opt() string_decode Strip potentially large terms when sending outgoing Diameter messages Improve language consistency in diameter(1)
2015-03-24Add service_opt() string_decodeAnders Svensson
To control whether stringish Diameter types are decoded to string or left as binary. The motivation is the same as in the parent commit: to avoid large strings being copied when incoming Diameter messages are passed between processes; or *if* in the case of messages destined for handle_request and handle_answer callbacks, since these are decoded in the dedicated processes that the callbacks take place in. It would be possible to do something about other messages without requiring an option, but disabling the decode is the most effective. The value is a boolean(), true being the default for backwards compatibility. Setting false causes both diameter_caps records and decoded messages to contain binary() in relevant places that previously had string(): diameter_app(3) callbacks need to be prepared for the change. The Diameter types affected are OctetString and the derived types that can contain arbitrarily large values: OctetString, UTF8String, DiameterIdentity, DiameterURI, IPFilterRule, and QoSFilterRule. Time and Address are unaffected. The DiameterURI decode has been redone using re(3), which both simplifies and does away with a vulnerability resulting from the conversion of arbitrary strings to atom. The solution continues the use and abuse of the process dictionary for encode/decode purposes, last seen in commit 0f9cdba.
2015-03-23Add transport_opt() dpr_timeoutAnders Svensson
To cause a peer connection to be closed following an outgoing DPA, in case the peer fails to do so. It is the recipient of DPA that should close the connection according to RFC 6733.
2015-03-23Merge branch 'anders/diameter/dpr/OTP-12542' into maintAnders Svensson
* anders/diameter/dpr/OTP-12542: Discard CER or DWR sent with diameter:call/4 Allow DPR to be sent with diameter:call/4 Add transport_opt() dpa_timeout Add testcase for sending DPR with diameter:call/4
2015-03-22Add transport_opt() dpa_timeoutAnders Svensson
To make the default DPA timeout configurable. The timeout say how many milliseconds to wait for DPA in response to an outgoing DPR before terminating the transport process regardless.
2015-03-19Improve language consistency in diameter(1)Anders Svensson
Akin to commit 85d44b58.
2015-02-20Improve language consistency in diameter(1)Anders Svensson
In particular, do away with unnecessary articles in the first sentence of item lists.
2015-02-20Add transport_opt() pool_sizeAnders Svensson
Transport processes are started by diameter one at a time. In the listening case, a transport process accepts a connection, tells the peer_fsm process, which tells its watchdog process, which tells its service process, which then starts a new watchdog, which starts a new peer_fsm, which starts a new transport process, which (finally) goes about accepting another connection. In other words, not particularly aggressive in accepting new connections. This behaviour doesn't do particularly well with a large number of concurrent connections: with TCP and 250 connecting peers we see connections being refused. This commit adds the possibilty of configuring a pool of accepting processes, by way of a new transport option, pool_size. Instead of diameter:add_transport/2 starting just a single process, it now starts the configured number, so that instead of a single process waiting for a connection there's now a pool. The option is even available for connecting processes, which provides an alternate to adding multiple transports when multiple connections to the same peer are required. In practice this also means configuring {restrict_connections, false}: this is not implicit. For backwards compatibility, the form of diameter:service_info(_,transport) differs in the connecting case, depending on whether or not pool_size is configured. Note that transport processes for the same transport_ref() can be started concurrently when pool_size > 1. This places additional requirements on diameter_{tcp,sctp}, that will be dealt with in a subsequent commit.
2014-12-09Prepare releaseErlang/OTP
2014-11-27Order peers in pick_peer callbacksAnders Svensson
The order of peers presented to a diameter_app(3) pick_peer callback has previously not been documented, but there are use cases that are simplified by an ordering. For example, consider preferring a direct connection to a specified Destination-Host/Realm to any host in the realm. The implementation previously treated this as a special case by placing matching hosts at the head of the peers list, but the documentation made no guarantees. Now present peers in match-order, so that the desired sorting is the result of the following filter. {any, [{all, [host, realm]}, realm]} The implementation is not backwards compatible in the sense that a realm filter alone is no longer equivalent in this case. However, as stated, the documentation never made any guarantees regarding the sorting.
2014-09-15Update release notesErlang/OTP