| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The updates of xref_base:analysis() are cosmetic (the strings are
parsed by the Erlang scanner only).
|
|
It's not clear to me if the receiving file always can handle
characters codes greater than 255.
|
|
|
|
|
|
|
|
|
|
|
|
There is more to do.
|
|
|
|
|
|
|
|
* ingela/ssl/session-cache-max/OTP-14556:
ssl: Mend Max session handling
|
|
The commit 256e01ce80b3aadd63f303b9bda5722ad313220f was a misunderstanding
that actually broke the implementation.
It is not so important to keep specific max, rather max is a threshold
when the table should be shrinked as to not grow indefinitely.
New sessions are created when the id is created and may be short lived
it they are not registered for reuse due to handshake failure.
|
|
* ingela/ssl/error-msg-enhancment:
ssl: Add the role (server or client) to the alert message
Addition to 972f9121311efcfb50db727ab3e930ebc95ab314 solved in OTP-14236
|
|
* anders/diameter/decode_format/OTP-14511:
Map less in traffic suite
Fix decode_format doc oversights
Rename decode_format false to none
Tweak {decode_format, false} semantics
Fix dialyzer spec
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
|
|
* anders/diameter/Proxy-Info/OTP-9869:
Fix handling of Proxy-Info in answers formulated by diameter
|
|
* anders/diameter/Experimental-Result/OTP-14511:
Fix extraction of Experimental-Result for counter keys
|
|
* anders/diameter/performance/OTP-14521:
Rename variable
Fix decode of too many generic AVPs
Enumerate AVPs in diameter_avp.index (again)
|
|
* anders/diameter/sctp/OTP-10889:
Send unordered on all outbound diameter_sctp streams
Delay rotation of diameter_sctp outbound streams
Exercise unordered delivery in traffic suite
Use unordered delivery on a lone outbound stream in diameter_sctp
|
|
By just decoding to map in the client, instead of to record first. The
record decode is exercised enough in the server and in other suites.
|
|
diameter_codec(3) referred only to the record format in places. The
configurable format was added in commits 722fa415 and then 55e65b26.
|
|
Which reads better and makes it easier to distinguish this false from
others.
|
|
Represent the decoded message by its atom-valued name in
diameter_packet.msg, which makes trace much more readable. A
diameter_avp.value is untouched (ie. undefined): the AVP name is already
in the name field.
|
|
Which dialyzer hasn't noticed.
|
|
anders/diameter/decode_format/OTP-14511
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
Let strict_mbit and incoming_maxlen be configured per transport
Let a service configure default transport options
Rename type evaluable -> eval
Document transport_opt() strict_capx
Rename transport_opt() capx_strictness to strict_capx
|
|
Remove value from the merged map, not from the maps being merged.
Bundled in commit 5f3becad.
|
|
It is desirable to be as specific as possible in the info message, so
there can be no mistake if the alert is form the peer or generated by
us. This use to be an error message, but it is better to make it an
info message as sending an ALERT ending the connection is an expected
behaviour.
|
|
Leading to this admonition from dialyzer:
diameter_config.erl:670: The variable No can never match since previous
clauses completely covered the type 'ok'
The throw was caught, but resulted in an error return without the
intended information.
|
|
Changes confusing example of a bad guard in ets:fun2ms
|
|
OTP-14574
* rickard/pcre-8.41:
Upgrade to PCRE 8.41 from PCRE 8.40
|
|
RFC 6733 says this:
6.2. Diameter Answer Processing
When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter
application defining the command:
...
o Any Proxy-Info AVPs in the request MUST be added to the answer
message, in the same order they were present in the request.
This wasn't done when a handle_request callback returned a Result-Code
in an 'answer-message' or protocol_error tuple, causing diameter itself
to construct the answer message. This form of answer is just a
convenience, since the callback can always return an answer that it
constructs itself.
|
|
The introduction of decode_format in commit 722fa415 (and then 55e65b26)
meant the value was not necessarily the intended tuple.
|
|
It's no longer the AVP name as of the parent commit, but the name of
the field/member the value will be stored in. Typically the AVP name,
but possibly 'AVP'.
|
|
That is, when the arity of an 'AVP' field has an upper bound. This
shouldn't happen in practice, but if an AVP is known but its name not
explicit in the message grammar then its count was confused with that
of AVPs packed into the 'AVP' field.
|
|
Commit 96cd627a changed the way the index field was used, but the
enumeration is used in at least one known application (as a pointer from
elements of diameter_packet.errors to elements of diameter_packet.avps)
and the motivation for the change is questionable: the lookup that was
avoided was unnecessary given that it was already performed in
incrementing a counter. Revert to enumerating as before in the non-relay
case, but not in the relay case since there's no corresponding usecase.
|
|
Make handling of match contexts stricter
OTP-14591
|
|
* dgud/kernel/fix-hanging-io/OTP-14571:
Always reply to sync requests
|
|
beam_validator could fail issue a diagnostic when a register
that was supposed to be a match context was not guaranteed to
be a match context.
The bug was in merging of types. Merging of a match context with
another term would result in a match context. That is wrong. Merging
should produce a more general type, not a narrower type. Also, the
valid slots in two match contexts should be combined with 'band', not
'bor'.
|
|
There's no reason for sending ordered since request handling is
concurrent: different processes handling incoming requests can't know in
which order they were received on the transport, and different processes
sending requests can't know the order in which they're sent.
|
|
For the same reason as unordered delivery is delayed in the grandparent
commit. Delivery is ordered only within a stream, so until a second
message is received from the peer, there's no guarantee that a second
outgoing request won't be received before the initial capablities
exchange message. Rotation begins upon reception of a second message
from the peer, messages being sent on stream 0 until then.
|
|
|
