| Age | Commit message (Collapse) | Author |
|---|
|
By sending {diameter, {answer, pid()}} when an incoming answer is sent
to the specified pid, instead of a discard message as previously. The
latter now literally means that the message has been discarded.
|
|
In particular, let a callback decide when to receive the initial
message.
|
|
TCP packets can contain more than one message, so only ask to receive
another message if it hasn't already been received.
|
|
As discussed in the parent commit. This is easier said than done in
practice, but there's no harm in allowing it.
|
|
This can be used as a simple form of overload protection, discarding the
message before it's passed into diameter to become one more request
process in a flood. Replying with 3004 would be more appropriate when
the request has been directed at a specific server (the RFC's
requirement) however, and possibly it should be possible for a callback
to do this as well.
|
|
In addition to returning ok or {timeout, Tmo}, let a throttling callback
for message reception return a pid(), which is then notified if the
message in question is either discarded or results in a request process.
Notification is by way of messages of the form
{diameter, discard | {request, pid()}}
where the pid is that of a request process resulting from the received
message. This allows the notification process to keep track of the
maximum number of request processes a peer connection can have given
rise to.
|
|
The callback is now applied to the atom 'false' when asking if another
message should be received on the socket, and to a received binary
message after reception. Throttling on received messages makes it
possible to distinguish between requests and answers.
There is no callback on outgoing messages since these don't have to go
through the transport process, even if they currently do.
|
|
To let a callback module decide whether or to receive another message
from the peer, so that backpressure can be applied when it's
inappropriate. This is to let a callback protect against reading more
than can be processed, which is otherwise possible since diameter_tcp
otherwise always asks for more.
A callback is made after each message, and can answer to continue
reading or to ask again after a timeout. It's each message instead of
each packet partly for simplicity, but also since this should be
sufficiently fine-grained. Per packet would require some interaction
with the fragment timer that flushes partial messages that haven't been
completely received.
|
|
|
|
* anders/diameter/dialyzer/OTP-13400:
Fix dialyzer warnings
|
|
* anders/diameter/17.5.6.9/OTP-13385:
vsn -> 1.9.2.4
Update appup for 17.5.6.9
|
|
* anders/diameter/retransmission/OTP-13342:
Fix handling of shared peer connections in watchdog state SUSPECT
Remove unnecessary parentheses
Remove dead export
|
|
Whether making record declarations unreadable to compensate for
dialyzer's ignorance of match specs is worth it is truly debatable.
|
|
|
|
OTP-13342 remote watchdog transition to state SUSPECT
|
|
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.
|
|
Not needed as of commit 6c9cbd96.
|
|
The export of diameter_traffic:failover/1 happened with the creation of
the module in commit e49e7acc, but was never needed since the calling
code was also moved into diameter_traffic.
|
|
Too wide function clause was used in ssl_connection which led to ssl
connection process crashes when `{hibernate_after, N}` with extremely
small N was passed among other options to `ssl:connect`.
|
|
|
|
* anders/diameter/17.5.6.8/OTP-13212:
vsn -> 1.9.2.3
Update appup for 17.5.6.8
|
|
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.
|
|
|
|
OTP-13164 more efficient peer lists
One module. Downgrade not supported.
|
|
|
|
* 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
|
|
* anders/diameter/request_leak/OTP-13137:
Fix request table leak at retransmission
Fix request table leak at exit signal
|
|
* anders/diameter/17/watchdog/OTP-12969:
Fix watchdog function_clause
|
|
* anders/diameter/M-bit/OTP-12947:
Add service_opt() strict_mbit
|
|
|
|
OTP-12947 strict_mbit
OTP-12969 watchdog function_clause
OTP-13137 request leak
diameter_config (that allows the new option) should be loaded after the
others.
Anchor was missing from one regexp. Patches did not accumulate through
older versions.
|
|
By not failing in code that looks up state: pick_peer and service_info.
|
|
In the case of retranmission, a prepare_retransmit callback could modify
End-to-End and/or Hop-by-Hop identifiers so that the resulting
diameter_request entry was not removed, since the removal was of entries
with the identifiers of the original request. The chances someone doing
this in practice are probably minimal.
|
|
The storing of request records in the ets table diameter_request was
wrapped in a try/after so that the latter would unconditionally remove
written entries. The problem is that it didn't deal with the process
exiting as a result of an exit signal, since this doesn't raise in an
exception. Since the process in question applies callbacks to user code,
we can potentially be linked to other process and exit as a result.
Trapping exits changes the current behaviour of the process, so spawn a
monitoring process that cleans up upon reception of 'DOWN'.
|
|
|
|
* ia/ssl/maint-17/backport-of-18-fix:
ssl: Prepare for release
ssl: Do not crash on proprietary hash_sign algorithms
|
|
|
|
|
|
|
|
|
|
|
|
Commit 4f365c07 introduced the error on set_watchdog/2, as a consequence
of timeout/1 returning stop, which only happens with accepting
transports with {restrict_connections, false}.
|
|
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.
|
|
Too much code was removed in commit 560f73141af
|
|
|
|
* anders/diameter/17.5.6.3/OTP-12927:
vsn -> 1.9.2.1
Update appup for 17.5.6.3
|
|
* anders/diameter/17/time/OTP-12926:
Simplify time manipulation
Remove use of monotonic time in pre-18 code
Remove unnecessary redefinition of erlang:max/2
|
|
* anders/diameter/grouped_errors/OTP-12930:
Fix decode of Grouped AVPs containing errors
Simplify logic
Simplify logic
|
|
* anders/diameter/transport/OTP-12929:
Fix start order of alternate transports
Log discarded answers
|
