| Age | Commit message (Collapse) | Author |
|---|
|
The former was misleading since the timer only applies to initial
connection attempts, reconnection attempts being governed by
watchdog_timer. The name is a historic remnant from a (dark, pre-OTP)
time in which RFC 3539 was followed less slavishly than it is now, and
the timer actually did apply to reconnection attempts.
Note that connect_timer corresponds to RFC 6733 Tc, while watchdog_timer
corresponds to RFC 3539 TwInit. The latter RFC makes clear that TwInit
should apply to reconnection attempts. It's less clear if only RFC 6733
is read.
Note also that reconnect_timer is still accepted for backwards
compatibility. It would be possible to add an option to make
reconnect_timer behave strictly as the name suggests (ie. ignore RFC 3539
and interpret RFC 6733 at face value; something that has some value for
testing at least) but no such option is implemented in this commit.
|
|
That is, for the process that's spawned for each incoming Diameter
request message.
|
|
'infinity' is a valid transport_config timeout.
|
|
|
|
Allow both share_peers and use_shared_peers to be a list of nodes, or a
function that returns a list of nodes.
|
|
This is the functionality that allows transports to be shared between
identically-named services on different nodes, which has been neither
documented nor tested (until now).
|
|
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.
|
|
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.
|
|
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.
|
|
Traffic handling is connected to the service implementation through the
pick_peer callback and failover but diameter_service was getting
unwieldy as home to both the service process and traffic handling.
|
|
|
|
|
|
|
|
Code should be loaded in this order:
diameter_session (sequence/1)
diameter_peer_fsm (calls to sequence/1)
diameter_service (sequence config, mask in receive_message/3)
diameter_watchdog (mask in peer start and receive_message/3)
diameter_config (accept sequence config)
Order of diameter and diameter_peer doesn't matter.
|
|
* anders/diameter/R15B02_release:
Dialyzer spec fix
OTP-10243
|
|
|
|
|
|
Transports are started one after the other if a connection is
not established with the timeout that can now be specified
with transport_config. For example, try an SCTP connect first,
a TCP connect if it doesn't succeed.
|
|
The module was originally just intended as a minimal callback
implementation that could be used as a template. Being able to order
just a subset of callbacks (with reasonable defaults) makes for
simpler code in many cases however so ready support for this can be
useful.
|
|
|
|
Simpler, no duplication of similar makefiles and makes for
better dependencies. (Aka, recursive make considered harmful.)
|
