| Age | Commit message (Collapse) | Author |
|---|
|
To control whether or not messages and grouped AVPs are decoded to
records, in #diameter_packet.msg and #diameter_avp.value respectively.
The decode became unnecessary for diameter's needs in parent commit,
which decoupled it from the checking of AVP arities.
|
|
|
|
* anders/diameter/capx_vs_dpr/OTP-14338:
Let candidate peers be passed to diameter:call/4
Comment on RFC ambiguity regarding application identifiers
Remove trailing whitespace
|
|
* anders/diameter/performance/OTP-14343: (50 commits)
Let spawn_opt config replace erlang:spawn_opt/2 for request processes
Move (most of) diameter_gen.hrl to diameter_gen.erl
Change signature associated with dictionary @custom_type/@codecs
Avoid sending answer terms between processes unnecessarily
Refactor handling of incoming requests
Restore diameter_codec:decode/2, update diameter_codec(3)
Add diameter_codec option ordered_encode
Restore undocumented Failed-AVP setting convenience
Fix/simplify setting of one Failed-AVP
Avoid recreating records
Avoid recreating records
Avoid recreating records
Avoid recreating records
Adapt test suites to modified encode/decode
Simplify diameter_caps construction
Don't compute URI defaults unnecessarily
Don't deconstruct {TPid, Caps} unnecessarily
Remove use of process dictionary in decode
Remove minor diameter_config bloat
Fix maximum AVP arity check
...
|
|
To solve the problem of being able to send messages to a peer that
hasn't advertised support for the application in question, as discussed
in the parent commit. diameter:call/4 can be passed 'peer' options to
identify candidates, and the only requirement is that an appropriate
dictionary be configured for encode. Filters are applied as if
candidates had been selected by advertised application.
|
|
To pass the options map through the encode. This is not backwards
compatible, and dictionaries supporting @custom_types or @codecs will
need to be updated.
|
|
The documentation has been out of date since the string_decode option
was added in commit 1590920c. The optionless decode/2 was removed in the
commit that removed the use of the process dictionary in decode.
|
|
This reverts commit dc57404252c47520f352834ad9be45ad684f96c9.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Defaults to X" isn't clarified by "if unspecified".
|
|
|
|
This reverts commit e020f75c10410a6943cd055bfa072a2641eab7da.
|
|
|
|
This reverts commit bd64ad8e15d66e48b36dbe3584315dd5cfc8b59a.
|
|
|
|
* 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
|
|
Missed in commit d6b3b84a.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
* anders/diameter/18.1/OTP-12978:
Remove 1.11 release notes
|
|
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.
|
|
* anders/diameter/M-bit/OTP-12947:
Add service_opt() strict_mbit
|
|
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.
|
|
Broken in the parent commit.
|
|
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.
|
|
|
|
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.
|
|
The warning report was removed in commit 00584303.
|
|
|
|
OTP-12845
* bruce/change-license:
fix errors caused by changed line numbers
Change license text to APLv2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
