| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* anders/diameter/rand/OTP-13664:
Use rand(3) instead of random(3)
|
|
* anders/diameter/19/listen/OTP-13611:
Fix testsuite match blunder
Remove unnecessary no_auto_import
Redo transport config server as a gen_server
|
|
That missed comm_up when something like the following was received on
FreeBSD (for one):
{sctp,#Port<0.599>,
{127,0,0,1},
45455,
{[{sctp_sndrcvinfo,0,0,[],0,0,0,0,145060462,3}],
{sctp_assoc_change,comm_up,0,10,10,3}}}
|
|
The latter is deprecated in OTP 19.
|
|
Not difficult to avoid, and better without.
|
|
To properly handle system messages. Initially implemented in commit
5ca5fb71.
|
|
* anders/diameter/19/listen/OTP-13611:
Fix leaking transports in traffic/relay suites
Close listening sockets at transport removal
Don't restart transport processes after transport removal
Rename diameter_reg:del -> remove
Add diameter_reg:subscribe/2
Add dialyzer specs to diameter_reg
Remove diameter_reg:repl/2
Remove diameter_reg bloat
|
|
This reverts commit e020f75c10410a6943cd055bfa072a2641eab7da.
|
|
|
|
Listening transports weren't removed, which diameter_reg:subs/0 revealed.
|
|
The transport interface documented in diameter_transport(3) is used to
start/stop accepting/connecting transport processes: they're started
with a function call, and told to die with their parent process. In the
accepting case, both diameter_tcp and diameter_sctp start a listening
process when the first accepting transport is started. However, there's
no way for a listening process to find out that that it should stop
listening when transport configuration is removed.
Both diameter_tcp and diameter_sctp have used a timer to terminate the
listening process after all existing accepting processes have died as a
consequence of transport removal. The problem with this is that nothing
stops a new client from connecting before this, and also that no new
transport can succeed in opening the same listening port (eg.
reconfiguration) until the old listener dies.
This commit solves the problem by adding diameter_reg:subscribe/2, to
allow callers to subscribe to messages about added/removed associations.
A call to diameter:add_transport/2 results in a new child process that
registers a term that a listening process subscribes to. Transport
removal results in the death of the child, and the resulting
notification to the listener causes the latter to close its socket and
terminate.
This is still an internal interface, but the subscription mechanism
should probably be made external (eg. a diameter:subscribe/1 that can
be used to subscribe to specified messages), so that transport modules
other than diameter's own can make use of it. There is no support for
soft upgrade.
|
|
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.
|
|
To allow processes to subscribe to a message when a matching association
is added or removed. The intention is to use this in
diameter_{tcp,sctp}, in order for listening processes to find out when
transport their transport configuration has been removed.
|
|
Last missed in commit 25bef13f.
|
|
Unused, and in the way for what's to come.
|
|
Unexpected messages don't happen in practice, and no_auto_import is
neither necessery nor difficult to avoid.
|
|
This reverts commit bd64ad8e15d66e48b36dbe3584315dd5cfc8b59a.
|
|
|
|
* anders/diameter/19.0-rc1/OTP-12913:
vsn -> 1.12
Update appup for 19.0-rc1
Update documentation for CEA/DWA/DPA Result-Code counters
|
|
* anders/diameter/info/OTP-13508:
Add diameter:peer_find/1
Add diameter:peer_info/1
|
|
* anders/diameter/overload/OTP-13330:
Suppress dialyzer warning
Remove dead case clause
Let throttling callback send a throttle message
Acknowledge answers to notification pids when throttling
Throttle properly with TLS
Don't ask throttling callback to receive more unless needed
Let a throttling callback answer a received message
Let a throttling callback discard a received message
Let throttling callback return a notification pid
Make throttling callbacks on message reception
Add diameter_tcp option throttle_cb
|
|
* anders/diameter/test/OTP-13438:
Don't assume list comprehension evaluation order
|
|
|
|
|
|
Missed in commit d6b3b84a.
|
|
To return a peer_fsm/transport pair given one of them.
|
|
To return information about a single peer_ref(), to avoid having to
retrieve more than is needed with service_info/2.
|
|
This one:
diameter_tcp.erl:928: (call)
The call diameter_tcp:throttle({'timeout',_},#transport{socket::port() | {'sslsocket',_,_},parent::pid(),module::atom(),frag::binary() | {non_neg_integer(),non_neg_integer(),binary(),[binary()]},ssl::boolean() | [any()],timeout::'infinity' | non_neg_integer(),tref::'false' | reference(),flush::boolean(),throttle_cb::'false' | fun() | maybe_improper_list(fun() | maybe_improper_list(any(),[any()]) | {atom(),atom(),[any()]},[any()]) | {atom(),atom(),[any()]},throttled::'true' | binary()})
will never return since it differs in the 1st argument from the
success typing arguments:
('discard' | 'ok' | binary() | pid() | {'discard' | 'ok' | binary() | pid(),'false' | fun() | [fun() | [any()] | {atom(),atom(),[any()]}] | {atom(),atom(),[any()]}},#transport{socket::port() | {'sslsocket',_,_},parent::pid(),module::atom(),frag::binary() | {non_neg_integer(),non_neg_integer(),binary(),[binary()]},ssl::boolean() | [any()],timeout::'infinity' | non_neg_integer(),tref::'false' | reference(),flush::boolean(),throttle_cb::'false' | fun() | [fun() | [any()] | {atom(),atom(),[any()]}] | {atom(),atom(),[any()]},throttled::binary()})
It's true that the clause doesn't return, because of the throw, and
that's the intention.
|
|
Orphaned in commit 9298872b.
|
|
|
|
That is, don't assume that it's only diameter_tcp doing so: allow it to
be received when not throttling. This lets a callback module trigger a
new throttling callback itself, but it's not clear if this will be
useful in practice.
|
|
|
|
=== OTP-18.3 ===
Changed Applications:
- asn1-4.0.2
- common_test-1.12
- compiler-6.0.3
- cosNotification-1.2.1
- cosTime-1.2.1
- cosTransactions-1.3.1
- crypto-3.6.3
- debugger-4.1.2
- dialyzer-2.9
- diameter-1.11.2
- edoc-0.7.18
- eldap-1.2.1
- erl_docgen-0.4.2
- erl_interface-3.8.2
- erts-7.3
- eunit-2.2.13
- hipe-3.15
- inets-6.2
- kernel-4.2
- mnesia-4.13.3
- observer-2.1.2
- orber-3.8.1
- public_key-1.1.1
- runtime_tools-1.9.3
- sasl-2.7
- snmp-5.2.2
- ssh-4.2.2
- ssl-7.3
- stdlib-2.8
- test_server-3.10
- tools-2.8.3
- webtool-0.9.1
- wx-1.6.1
- xmerl-1.3.10
Unchanged Applications:
- cosEvent-2.2
- cosEventDomain-1.2
- cosFileTransfer-1.2
- cosProperty-1.2
- et-1.5.1
- gs-1.6
- ic-4.4
- jinterface-1.6.1
- megaco-3.18
- odbc-2.11.1
- os_mon-2.4
- ose-1.1
- otp_mibs-1.1
- parsetools-2.1.1
- percept-0.8.11
- reltool-0.7
- syntax_tools-1.7
- typer-0.9.10
Conflicts:
OTP_VERSION
erts/vsn.mk
lib/test_server/doc/src/notes.xml
lib/test_server/vsn.mk
lib/webtool/doc/src/notes.xml
lib/webtool/vsn.mk
|
|
|
|
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/18/dialyzer/OTP-13400:
Fix dialyzer warnings
|
|
|
