| 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
|
|
* anders/diameter/terminate/ERIERL-124:
Fix handling of SUSPECT connections at service termination
|
|
* anders/diameter/reg/OTP-14839:
Fix diameter_reg:subscribe/2 remove notification
|
|
|
|
|
|
Timestamps have been monotonic time since OTP-17.5. See commit e6d19a18.
The examples should really be replaced by more detailed doc of return
values.
|
|
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)
|
|
Commit fae8ca0c broke notification by removing table elements before
matching for them, causing diameter_tcp/sctp listening processes to
live on after diameter:remove_transport/2.
Commit 58091992 added diameter_reg:subscribe/2, and commit 5ca5fb71
started using it for listener exit.
|
|
|
|
|
|
Only change is doc.
|
|
|
|
|
|
* anders/diameter/decode/OTP-14684:
vsn -> 2.1.2
Update appup for ERIERL-14684
|
|
The options map wasn't updated after the AVP was identified, with
the resulting consequences for M-bit interpretation.
|
|
Which may have been used in the past, but aren't now.
|
|
The wrong variable was passed into the decode recursion, causing the
options map to be contaminated by strict_mbit and failed_avp
modifications that should only apply to component AVPs in the Grouped
case. Decode errors and M-bits could be ignored as a result.
|
|
|
|
|
|
|
|
|
|
|
|
Commit fae8ca0c inadvertently removed the monitor at add/1 and
add_new/1. As a result, process death did not remove associations,
causing table diameter_reg to leak entries and stop/start of a service
to fail.
Add a testcase to detect the problem, which existing testcases miss.
|
|
|
|
* anders/diameter/doc/OTP-14561:
Document new(ish) options in diameter_tcp/sctp
|
|
* anders/diameter/SoC/OTP-10927:
Simplify/complete Standards Compliance doc
|
|
With a table. Probably no one wants to read a commented RFC, it's been
unfinished for some time, and it's difficult to get an overview from it.
|
|
See commits d3829525 (unordered), c591056b (packet), eadf4efc (sender),
636a7199 (tcp message_cb), 373cd07c (sctp message_cb)
|
|
* anders/diameter/20.1/OTP-14561:
Update appup and version for 20.1
|
|
* anders/diameter/sctp/OTP-10889:
Make unordered delivery configurable
|
|
* anders/diameter/performance/OTP-14521:
Fix append of Route-Record AVPs
|
|
Changing the default in the parent commit is possibly a bit dangerous,
even if the motivation still holds. Take a step back and make unordered
delivery a matter of configuration, without changing the default:
configuration is {unordered, boolean() | pos_integer()}, with false the
default, and N equivalent to OS =< N, where OS is the number of outbound
streams negotiated on the association in question.
A user can mess with this by configuring an sctp_default_send_param of
their own, but unordered sending is them from start, not only after the
second message reception.
|
|
Commit b3d9e0c0 did away with the reordering of diameter_avp lists, so
prepending the AVP to the list means prepending it in the message, which
is not what the RFC requires.
Appending to a list isn't ideal, but right now there's no better way.
|
|
|
|
* anders/diameter/grouped_decode/OTP-14607:
Fix diameter_packet.avps decode of Grouped AVP errors in Failed-AVP
|
|
* anders/diameter/DOIC/OTP-14588:
Fix avp_dictionaries decode with {decode_format, none}
|
|
The decode didn't respect the format as a list of diameter_avp records,
so information about faulty component AVPs was lost.
|
|
anders/diameter/grouped_decode/OTP-14607
* anders/diameter/DOIC/OTP-14588:
Fix avp_dictionaries decode with {decode_format, none}
|
|
Decode is only a no-op when the AVP is Grouped, and then only on the
Grouped AVP itself, not its components.
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix type spec
Fix strict_arities blunder
|
|
* anders/diameter/performance/OTP-14521:
Simplify implementation in diameter_reg (take 2)
|
|
Map key was not retained when the spec was added in commit 66bb5251.
|
|
The watchdog process retained the configuration, causing DWR/DWA encode
to fail on a string-valued Origin-Host/Realm if the encode arity was
relaxed.
Bungled in commit 5f3becad.
|
|
Simplify the simplification. The order of sending is changed, but the
order isn't significant.
|
|
* anders/diameter/performance/OTP-14521:
Simplify implementation in diameter_reg
Fix type spec
Fix minor monitor blunder in diameter_reg
|
|
Use maps instead of dict for traceability more than performance.
|
|
That dialyzer hasn't noticed is wrong.
|
|
* anders/diameter/answer-message_decode/OTP-14596:
Exercise answer-message/AVP decode in traffic suite
Exercise answer-message/Failed-AVP decode in traffic suite
|
