| Age | Commit message (Collapse) | Author |
|---|
|
diameter_sctp.erl:292: Record construction #transport{parent::pid(),mode::{'accept',atom() | pid() | port() | {atom(),atom()}},active::'false',recv::'true',os::0,packet::'true',message_cb::'undefined',send::'false'} violates the declared type of field message_cb::'false' | fun() | maybe_improper_list(fun() | maybe_improper_list(any(),[any()]) | {atom(),atom(),[any()]},[any()]) | {atom(),atom(),[any()]}
diameter_sctp.erl:302: Record construction #transport{mode::{'accept',atom() | pid() | port() | {atom(),atom()}},active::'false',recv::'true',os::0,packet::'true',message_cb::'undefined',send::'false'} violates the declared type of field message_cb::'false' | fun() | maybe_improper_list(fun() | maybe_improper_list(any(),[any()]) | {atom(),atom(),[any()]},[any()]) | {atom(),atom(),[any()]}
|
|
To determine the wrapping of messages passed to recv callbacks and into
diameter. The default passing of the input stream in transport_data is
probably of no practical use, but has been set since time immemorial.
|
|
Corresponding to diameter_tcp callbacks a few commits back. Exercise the
callbacks in the traffic suite.
|
|
To let a recv callback for an incoming request set transport_data and
have it returned in a send callback.
|
|
|
|
From the receiver process, that can return binaries to send/receive and
stop the transport process from reading on the socket.
This is still undocumented, and may change.
|
|
With sends still from the receiving process by default, since changing
the default behaviour may well have negative effects. A separate sender
probably implies a greater need for some form of load regulation for
one, since a blocking send would no longer imply that incoming messages
are no longer recevied. Dealing with this could result in the same
deadlock that the sending process intends to avoid, but the user should
be in control over how/when incoming traffic is regulated.
|
|
Added in commit 2afd1fe5. Only rename variables in diameter_tcp, no
functional change.
|
|
This:
diameter_tcp.erl:241: Record construction #transport{parent::'false',ssl::boolean() | maybe_improper_list(),frag::<<>>,tref::'false',flush::'false',pending::0,reset::{1 | 4,0 | 2},throttled::boolean(),q::{0,queue:queue(_)},monitor::'undefined' | pid()} violates the declared type of field parent::pid()
The problem isn't #transport.pid at all, it's #monitor.pid, and the only
relation is that the pid that's assigned to the latter is also (later)
assigned to the former. There is no record construction that assigns
false to #transport.parent.
Introduced in commit 33a535e4.
|
|
What's interesting when implementing some form of load regulation is
when an incoming request has been answered or discarded. Acknowledge
exactly this, not the identity of handler processes as previously. A
transport process can request acks of nonforthcoming answers by sending
{diameter, ack} to the parent peer_fsm, a handler processes identifies
itself with a {handler, pid()} message, and the peer_fsm monitors on
this to be able to send a notification to the transport if the handler
dies before sending an answer.
|
|
Commits starting at 472a080c added a throttle_cb option to diameter_tcp
to let a callback apply backpressure when it decides that additional
requests should not be read. It didn't provide a hook for knowing that
an answer was sent however, which is needed when sends no longer take
place in the receiver process, and is more complicated than it should
be. Strip it all away, in preparation for a simpler incarnation.
|
|
Shutdown events have been seen to get a different association id.
For example, first incoming message with association id = 0:
+ {trace_ts,<6421.268.0>,call,
{diameter_sctp,handle_info,
[{sctp,#Port<6421.2588>,
{10,67,16,179},
44159,
{[{sctp_sndrcvinfo,0,0,[],0,0,0,269950872,269950872,0}],
<<1,0,0,156,128,0,1,1,0,0,0,0,6,193,40,137,6,193,40,137,0,0,
1,8,64,0,0,30,67,45,49,51,52,50,49,55,52,52,49,46,101,114,
108,97,110,103,46,111,114,103,0,0,0,0,1,40,64,0,0,18,101,
114,108,97,110,103,46,111,114,103,0,0,0,0,1,1,64,0,0,14,0,
1,127,0,0,1,0,0,0,0,1,10,64,0,0,12,0,0,48,57,0,0,1,13,0,0,
0,20,79,84,80,47,100,105,97,109,101,116,101,114,0,0,1,22,
64,0,0,12,0,0,0,1,0,0,1,2,64,0,0,12,0,0,0,0,0,0,1,3,64,0,0,
12,0,0,0,3>>}},
{transport,<6421.252.0>,accept,#Port<6421.2588>,true,undefined,
{32,32},
0,undefined}]},
{1493,21505,577938}}
Later, a shutdown event with association id 1536:
+ {trace_ts,<6421.268.0>,call,
{diameter_sctp,handle_info,
[{sctp,#Port<6421.2588>,
{10,67,16,179},
44159,
{[],{sctp_shutdown_event,1536}}},
{transport,<6421.252.0>,accept,#Port<6421.2588>,0,undefined,
{32,32},
2,<6421.304.0>}]},
{1493,21505,746929}}
Both this and the grandparent commit are on this:
$ uname -a
SunOS beren 5.10 Generic_118833-33 sun4v sparc SUNW,Netra-T2000
|
|
In particular, that the association id received in messages on a
one-to-one socket after peeloff may be different from the id received on
the listen socket at comm_up.
This seems odd, since it's then not possible to send until the id is
discovered by reception of an SCTP message containing it, but it's
unclear if this is a bug or a feature, or if it's specific to certain
platforms. Treat it as a feature in this commit, and get the association
id as mentioned, an incoming CER being expected before anything is sent.
Commit da3e5d67 has more history.
|
|
Which dialyzer itself has never complained about.
|
|
Both diameter_tcp and diameter_sctp are susceptible to deadlock since a
peer that blocks send also prevents additional messages from being
received. Send from a process that's paired with the transport process
to avoid this. Use the existing monitor process in the TCP case, add one
in the SCTP case.
This has been the reason for many sporadic testcase failures, mostly in
diameter_traffic_SUITE.
|
|
Should be ssl:close/1.
|
|
Since smooth upgrade won't be supported in this branch.
|
|
Message length errors in incoming messages were misinterpreted with
transport_opt() {length_errors, exit} due to the throw introduced in
commit 2ffb288: the corresponding catch in incoming/2 caught errors
thrown by close/1, leading to failure when the error reason was
interpreted as a diameter_packet record. Do away with the throw, that
also caused woe in the parent commit.
|
|
A transport process can request acknowledgement of the fate of an
incoming message to a specified pid, causing it to receive one of
{diameter, {request|answer, pid()} | discard}
depending on whether or not diameter passes the message off to a handler
process. This was broken in commit a4da06a5 (since recv/3 threw a
message that should be received), but is of little consequence since the
interface isn't yet documented and is only used from diameter_tcp with
configuration that will soon change.
|
|
From commits 5ca5fb71 and 58091992.
|
|
* anders/diameter/capx_strictness/OTP-14257:
Add transport_opt() capx_strictness
|
|
* anders/diameter/19.3/OTP-14252:
vsn -> 1.12.2
Update appup for 19.3
|
|
To allow the Peer State Machine requirement that only the expected
capabilities exchange message be received in the relevant state to be
relaxed. If {capx_strictness, false} is configured then anything bu the
expected CER/CEA is ignored.
This is non-standard behaviour, and thusfar undocumented. Use at your
own risk.
|
|
When relaying outgoing requests through transport on a remote node,
terms that were stripped when sending to the transport process weren't
stripped when spawning a process on the remote node.
Also, don't save the request to the process dictionary in a process that
just relays an answer.
|
|
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.
|
|
OTP-14206 fix 19.1 failover blunder, use diameter_request less
|
|
Commit 9a878743 addressed inefficiency at failover, but introduced
inefficiency in the sending of outgoing requests in so doing: each
outgoing request added an request table entry keyed on a transport pid,
then looked for a specific element with this key, and then (later)
removed the inserted element. Since the request table is a bag, this
results in linear searches over a potentially long list of element
keyed on the same pid. The higher the rate of outgoing calls, the more
costly it becomes.
Instead of writing entries to the request table, the peer_up/down calls
to diameter_traffic that mirror transitions to and from the OKAY state
in the RFC 3539 watchdog state machine now result in a process for
request processes to monitor in order to detect failover.
|
|
|
|
* anders/diameter/19.1/OTP-13838:
vsn -> 1.12.1
Update appup for 19.1
Fix xmllint errors in documentation
Remove documentation overkill
Don't run traffic tests in parallel when {string_decode, true}
Remove copyright from generated dictionary modules
Fix dictionary function typo
Fix dictionary typo in relay example
|
|
* anders/diameter/failover/OTP-13412:
Make peer failover more efficient
|
|
* anders/diameter/min_heap_size/OTP-13796:
Let unfortunate min_heap_size setting be disabled
|
|
* anders/diameter/19/listen/OTP-13787:
Close listening sockets at service death
|
|
OTP-13412 more efficient peer failover
OTP-13787 close listening sockets
OTP-13796 min_heap_size
OTP-13838 typo in diameter_traffic
No load order requirements.
|
|
The setting in all diameter server processes has existed since the
beginning of time. Whether it's actually useful is questionable, but it
does lead to increased memory usage, especially if there are many peer
connections whose processes wouldn't otherwise be large. Let the setting
be disabled with -diameter min_heap_size false. (Or any value that isn't
a non-negative integer.)
The diameter application itself only calls
diameter_lib:spawn_opts(server, []), but let other arguments remain for
backwards compatibility, since diameter_lib:spawn_opts/2 has been abused
from outside of diameter.
|
|
Commit 5ca5fb71 ensured that they were closed immediately at transport
removal, but in so doing broke their closing at stop service completely,
by removing the timer that caused sockets to be closed even belatedly.
Monitor on the service process to make it happen.
This could still be improved, since stop_service listening ports aren't
closed until after the service process has died. They could be closed
earlier in the case of stop_service.
|
|
The copyright was a historical remnant of diameter's roots prior to its
inclusion in OTP.
Thanks to Anatolie Golovco.
|
|
It's '#get-'/2, not 'get-'/2. Only failed if the dictionary in question
defined no Failed-AVP, which is rarely the case in practice.
Thanks to Ferenc Holzhauser.
|
|
One more followup to https://github.com/erlang/otp/pull/1056 and
https://github.com/erlang/otp/pull/1023
This time it's about `/usr/bin/env` and `/bin/cp`:
- `/usr/bin/env` in `diameterc` was used to find the bootstrapped
`escript` executable. Changed it to exlpicit call to `escript` in
Makefile.
- `/usr/bin/env` and `/bin/cp` were referenced in documentation
build/install process. Now full paths to this tools are injected using
autoconf magic.
|
|
* anders/diameter/rand/OTP-13664:
Use rand(3) instead of random(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.
|
|
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.
|
|
* 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
|
