| Age | Commit message (Collapse) | Author |
|---|
|
To accept any nested list of codepoints and binaries. A list containing
a binary was previously misinterpreted and the documentation was
incomplete.
Also, rework codec suite slightly to be able to specify values for which
decode o encode is the identity map, for which encode should succeed,
and for which encode should fail.
|
|
|
|
* anders/diameter/request_spawn/OTP-11060:
Minor doc fix
|
|
|
|
* anders/diameter/release/R16B01/OTP-11120:
vsn -> 1.4.2
Update appup for R16B01
Trailing whitespace and copyright fixes
Minor macro simplification
Move app/appsrc from src/base into src
|
|
* anders/diameter/request_spawn/OTP-11060:
Make spawn options for request processes configurable
|
|
That is, for the process that's spawned for each incoming Diameter
request message.
|
|
Option 'accept' allows remote addresses to be configured as tuples or
regular expressions. The remote addresses for any incoming (aka
accepted) connection/association are matched against the configured
values, any non-matching address causing the connection/association to
be aborted.
|
|
|
|
* anders/diameter/5xxx_failed_avp/OTP-11092:
Fix setting of Failed-AVP on {answer_message, 5xxx} from handle_request
|
|
RFC 6733 says that certain 5xxx result codes must be accompanied by
Failed-AVP, and decode populates #diameter_packet.errors with
Result-Code/AVP pairs for errors it detects. However, Failed-AVP was not
set in the outgoing answer if the handle_request callback returned
{answer_message, 5xxx}. It is now set with the AVP from the first pair
with the specified Result-Code, if found.
Note that {answer_message, 5xxx} doesn't handle all cases in which a
5xxx answer is required, only that in which the setting above is
appropriate. If it isn't then handle_request should construct its answer
and return {reply, Ans}.
|
|
Addresses returned from a transport module were always used to populate
Host-IP-Address AVP's in an outgoing CER/CEA, which precluded the
sending of a VIP address. Transport addresses are now only used if
Host-IP-Address is unspecified.
In other words, respect any configured Host-IP-Address, regardless of
the physical addresses returned by the transport. To use the physical
addresses, don't configure Host-IP-Address.
|
|
* anders/diameter/watchdog_leak/OTP-11019:
Minor doc fix
Add testcase to exercise reconnect behaviour
Fix watchdog table leak
|
|
|
|
Use the default address address (as selected by gen_tcp) if none is
configured, passing it in the new 'connected' message introduced by the
previous commit.
The corresponding update to diameter_sctp has to wait until problems
with inet:sockname/1 are resolved: the function currently only returns
one address, and sometimes {0,0,0,0}. See OTP-11018.
|
|
A transport module can return a local address list from its start/3
function in order to specify addresses to be used as Host-IP-Address
during capabilities exchange. Now allow addresses to be communicated in
a 'connected' message in the case of a connecting transport, so that
diameter_tcp (in particular) can make local address configuration
optional, communicating the gen_tcp default after connection
establishment instead.
|
|
Diameter = the protocol
diameter = the Erlang application
|
|
* anders/diameter/app_not_configured/OTP-10972:
Fix faulty sequence validation
Add config suite
Deal with config errors detected at transport start less brutally
Move most transport_opt() validation into diameter_config
Minor doc/spec fix
Minor diameter_lib cleanup
|
|
'infinity' is a valid transport_config timeout.
|
|
Fix errors and omissions related to dictionary compilation.
|
|
|
|
|
|
Allow both share_peers and use_shared_peers to be a list of nodes, or a
function that returns a list of nodes.
|
|
|
|
Make it just a number of timeouts, without a new DWR being sent.
|
|
To make the number of watchdogs sent before the transitions REOPEN ->
OKAY and OKAY -> SUSPECT configurable. Using anything other then the
default config is non-standard and should only be used for test.
|
|
|
|
The commentary is not yet complete. It currently stops at chapter 4 of
the RFC.
|
|
|
|
RFC 3588 allowed only 3xxx result codes in an answer-message (that is,
an answer that sets the E-bit) while RFC 6733 also allows 5xxx result
codes. Setting request_errors = answer tells diameter to answer 5xxx
errors itself. Returning {answer_message, integer()} from a
handle_request callback allows both 3xxx and 5xxx result codes to be
set. {protocol_error, integer()} is retained for 3xxx result codes.
|
|
When receiving a request for which errors have been detected during
decode, diameter previously used the errors list in the decoded
diameter_packet record to unconditionally set Result-Code and Failed-AVP
in the outgoing answer. It wasn't particularly delicate in doing so
however and would happily set a 5xxx Result-Code even if a
handle_request callback returned an answer-message, leading to an encode
error. This behaviour became even less endearing as of commit ac452e28,
which made it possible to handle_request to take place even for protocol
errors. (ie. When a callback typically should return an answer-message.)
This commit fixes the behaviour by only setting a value that's
appropriate for the answer in question, either a 3xxx or a 5xxx,
depending on if the answer's an answer-message or not. It also allows
handle_request to prevent diameter from setting anything by setting
errors = false in a returned diameter_packet. Ideally it should have
been errors = [] but the empty list is the default value for the errors
field and changing the default (ideally there shouldn't have been one)
would require recompilation of all modules including diameter.hrl:
choose the less attractive 'false' to avoid such backwards
incompatibility.
The request reception is also refactored somewhat to shorten some call
chains.
|
|
Configuring the value 'callback' all errors detected in incoming
requests to result in a handle_request callback. The default value
'answer_3xxx' is the previous behaviour in which diameter answers
protocol errors without a callback.
|
|
The value determines whether or not an unexpected message length in the
header of an incoming messages causes the peer process to exit, the
message to be discarded or handled as usual. The latter may only be
appropriate for message-oriented transport (eg. SCTP) since
stream-oriented transport (eg. TCP) may not be able to recover the
message boundary once a length error has occurred.
|
|
Don't start a new timer with each incoming message. Instead, start a
timer at timeout and flush after two successive timeouts with no message
reception.
|
|
|
|
|
|
|
|
|
|
|
|
* nox/enable-silent-rules/OTP-10726:
Implement ./otp_build configure --enable-silent-rules
|
|
With silent rules, the output of make is less verbose and compilation
warnings are easier to spot. Silent rules are disabled by default and
can be disabled or enabled at will by make V=0 and make V=1.
|
|
|
|
|
|
* anders/diameter/doc/OTP-10568:
Update doc for RFC 6733
Add copies of RFC's 6733 and 6737
|
|
|
|
|
|
|
|
Not yet any content to speak of.
|
|
|
|
|
