| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* anders/diameter/20.3/OTP-14946:
vsn -> 2.1.4
Update appup for 20.3
Update service_info examples in doc
Fix inaccurate comment
|
|
A peer_fsm process can be started long before a connection is
established in the listening case. The time reported in a 'peer' tuple
in service_info is of connection establishment.
|
|
A peer connection in watchdog state SUSPECT is represented by a peer
table entry in diameter_service, but not by a request table entry in
diameter_peer, so diameter_service:terminate/2 could result in failures
like this:
exception error: no match of right hand side value []
in function diameter_traffic:peer_down/1 (base/diameter_traffic.erl, line 141)
in call from lists:foldl/3 (lists.erl, line 1263)
in call from ets:do_foldl/4 (ets.erl, line 611)
in call from ets:foldl/3 (ets.erl, line 600)
in call from diameter_service:terminate/2 (base/diameter_service.erl, line 557)
in call from gen_server:try_terminate/3 (gen_server.erl, line 648)
in call from gen_server:terminate/10 (gen_server.erl, line 833)
in call from gen_server:handle_msg/6 (gen_server.erl, line 679)
|
|
* anders/diameter/DOIC/OTP-14588:
Exercise avp_dictionaries in traffic suite
Let generic AVPs be encoded/decoded in alternate dictionaries
Rename field in codec map: dictionary -> app_dictionary
Add RFC 7683 Diameter Overload Indicator Conveyance text and dictionary
Fix decode undef
Fix dictionary compilation error message
|
|
To support specifications like RFC 7683 DOIC, that only define AVPs, not
applications. AVPs that aren't known to the application dictionary in
question could previously not be decoded. Configuring alternate
dictionaries with the new transport/service option avp_dictionaries
changes this, so that AVPs like DOIC's Grouped OC-OLR can presented in
their fully decoded glory. Encode is also extended, allowing things like
the following to be encoded in an outgoing message:
'AVP' => [{'OC-OLR', #{'OC-Sequence-Number' => 1,
'OC-Report-Type' => 0,
'OC-Reduction-Percentage' => [25]}}]
A diameter_gen_doic_rfc7683 dictionary is installed, but
avp_dictionaries isn't specific to DOIC.
This commit also solves the problem demonstrated a few commits back,
that application AVPs aren't decoded in answers setting the E-bit. Test
coverage will come in a subsequent commit.
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
|
|
Remove value from the merged map, not from the maps being merged.
Bundled in commit 5f3becad.
|
|
* anders/diameter/config_consistency/OTP-14555:
Let strict_mbit and incoming_maxlen be configured per transport
Let a service configure default transport options
Rename type evaluable -> eval
|
|
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).
|
|
* anders/diameter/performance/OTP-14521:
Work around unexpected common_test behaviour
Randomly skip groups in traffic suite
Randomly disable traffic counters in traffic suite
Add service_opt() traffic_counters
Fix type spec
Split AVPs at decode
Avoid unnecessary copying of binaries in diameter_tcp
Don't update diameter_tcp state unnecessarily
Don't update diameter_tcp state unnecessarily
Simplify extraction of incoming Diameter messages in diameter_tcp
Restructure/simplify message reception in diameter_peer_fsm
Sleep randomly at the start of (parallel) traffic testcases
Fix ct return value in traffic suite
Fix type spec
Optimize sub-binaries
Optimize sub-binaries
Count AVPs in #diameter_avp.index
Don't extract options unnecessarily at encode
Redo message decode as a single pass
|
|
* anders/diameter/5009/OTP-14512:
Use relaxed arity checks in traffic suite
Be forgiving of non-list values at encode
Add service_opt() strict_arities
Fix detection of 5009 errors
Test Result-Code 5009 in traffic suite
|
|
* anders/diameter/codec/OTP-14511: (26 commits)
Limit SCTP testing in traffic suite
Increase init_per_group timetrap in traffic suite
Add diameter_util:eprof/1 for test
Don't search forms unnecessarily in diameter_exprecs parse transform
Increase init_per_suite timetrap in traffic suite
Don't count AVPs unnecessarily at encode
Test decode_format record_from_map in traffic suite
Tweak limiting of testcases in traffic suite
Don't take length of AVP lists unnecessarily at encode
Tweak map-valued decode
Rearrange group names in traffic suite
Randomly wrap answers in diameter_packet in transport suite
Don't exercise client/server encoding independently in traffic suite
Add decode_format record_from_map
Rename record_decode -> decode_format
Create fewer client connections in traffic suite
Test record_decode in traffic suite
Map answers to maps in traffic suite
Test map encoding in traffic suite
Let messages and grouped AVPs be decoded to lists
...
|
|
To be able to disable the counting of messages for which application
callbacks take place. Messages sent/handled by diameter itself are
always counted.
|
|
To be able to disable the relatively expensive check that the number of
AVPs received in a message or grouped AVP agrees with the dictionary in
question. The may well be easier for the user in handle_request/answer
callbacks, when digesting the received message, and in some cases may
not be important.
The check at encode can also be disabled, allowing messages that don't
agree with the dictionary in question to be sent, which can be useful in
test (at least).
|
|
{record_decode, map} is a bit too quirky.
|
|
That is, decode to the same format that encode already accepts. Only a
message has its name at the head of the list since AVPs are already
name/value pairs.
|
|
With {record_decode, map}. The option name is arguably a bit misleading
now, but not too objectionable given that the encode/decode in question
has historically only been of records.
One advantage of the map decode is that the map only contains values for
those AVPs existing in the message or grouped AVP in question. The name
of the message or grouped AVP is stored in with key ':name', the leading
colon ensuring that the key isn't a diameter-name.
Decoding to maps makes the hrl files generated from dictionary files
largely irrelevant. There are value defines generated into these, but
they're typically so long as to be unusable.
|
|
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.
|
|
Service configuration share_peers and use_shared_peers is used to share
peer connections with other connected nodes having a service of the same
name: a service process asks its neighbours about existing connections
when it starts, and pushes new connections as they're established.
The problem is that the mechanics assume that nodes() doesn't change. In
particular, if a neighbour isn't connected when a service starts then it
doesn't receive the request to share connections. Solve by having each
service process monitor nodes, a nodeup notification causing it to
request connections of its neighbours. Nodes going down is already
handled, by remote connections being monitored in diameter_service.
|
|
* 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
|
|
By accepting an MFA that is applied to the fun that is otherwise spawned
for each incoming request, to allow handler processes to be reused. This
is not yet documented and may change, but the motivation is to let spawn
be replaced by process pool, from which the MFA selects. A list-valued
spawn_opt is equivalent to {erlang, spawn_opt, [Opts]}.
|
|
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.
|
|
The tuple is returned from and passed to callbacks, so retain the tuple
instead of its elements.
|
|
By passing additional arguments through it.
|
|
This and subsequent commits are destined for OTP 20.0.
|
|
The table has existed forever, to route incoming answers to a waiting
request process: each outgoing request writes to the table, and each
incoming answer reads. This has been seen to suffer from lock contention
at high load however, so this commit moves the routing into the
diameter_peer_fsm processes that are diameter's conduit to transport
processes. The request table is still used for failover detection, but
entries are only written when a watchdog state transitions leaves or
enters state OKAY.
|
|
A replacement accepting transport could be started after the service
process received a shutdown message from diameter_config, if a
connection was accepted before the transport process in question was
terminated. The replacement lived on until the service needed to restart
it.
|
|
Letters are cheap.
|
|
* anders/diameter/info/OTP-13508:
Add diameter:peer_find/1
Add diameter:peer_info/1
|
|
To return information about a single peer_ref(), to avoid having to
retrieve more than is needed with service_info/2.
|
|
|
|
Whether making record declarations unreadable to compensate for
dialyzer's ignorance of match specs is worth it is truly debatable.
|
|
|
|
* anders/diameter/retransmission/OTP-13342:
Fix handling of shared peer connections in watchdog state SUSPECT
Remove unnecessary parentheses
Remove dead export
|
|
A peer connection shared from a remote node was regarded as being
available for peer selection (aka up) as long as its peer_fsm process
was alive; that is, for the lifetime of the peer connection. In
particular, it didn't take note of transitions into watchdog state
SUSPECT, when the connection remains. As a result, retransmissions could
select the same peer connection whose watchdog transition caused the
retransmission.
A service process now broadcasts a peer_down event just as it
does a peer_up event.
The fault predates the table rearrangements of commit 8fd4e5f4.
|
|
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.
|
|
See commit 862af31d.
|
|
|
|
|
|
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.
|
|
See commit 862af31d.
|
|
* anders/diameter/17.5.6.7/OTP-13211:
vsn -> 1.9.2.2
Update/fix appup for 17.5.6.7
Be resilient to diameter_service state upgrades
|
|
By not failing in code that looks up state: pick_peer and service_info.
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
* 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.
|
|
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.
|
|
By doing away with more wrapping that the parent commit started to
remove.
|
|
|
