| Age | Commit message (Collapse) | Author |
|---|
|
The diffs are all about adapting to the OTP 18 time interface. The code
was previously backwards compatible, falling back on the erlang:now/0 if
erlang:monotonic_time/0 is unavailable, but this was seen to be a bad
thing in commit 9c0f2f2c. Use of erlang:now/0 is now removed.
|
|
By doing away with more wrapping that the parent commit started to
remove.
|
|
OTP-12845
* bruce/change-license:
fix errors caused by changed line numbers
Change license text to APLv2
|
|
A listener process in diameter_sctp starts accepting transport processes
as required, either as associations are established or as diameter asks
for a processes to be started. Since this can happen in any order, the
listener maintains two queues: one for processes that diameter has
requested and which are waiting to be given an association, another for
processes that have been started to become owners of an association but
are waiting for diameter to request them. Only one queue at a time is
non-empty. The first queue's length is bounded by the number of
accepting processes configured as pool_size. Entries in the second queue
are short-lived since diameter starts a replacement transport process
whenever an existing one dies or communicates that it has an
association.
The two queues were previously implemented in an ets ordered_set, whose
keys were the pid() of transport processes. Removing an element from the
queue was then done with ets:first/1. The problem with this it's not
really a queue: there's no guarantee that pid-ordering is the same as
the order in which processes are started. If it isn't then it's possible
that an established association never be given to diameter as a
transport process if there's always a newer association whose pid sorts
first. This isn't a problem in practice since it would require new
associations to be established faster than diameter starts transport
processes, but redo the implementation as a queue, with strict FIFO
semantics.
|
|
The changes in some of the previous commits assume application restart.
|
|
Don't pass an association id that's no longer used.
|
|
In particular, don't give the accepting transport process the listening
socket. It was used to match the initial sctp message received in a
peeloff message, but replace the socket in the forwarded message
instead.
|
|
The existing code was a remnant of the pre-peeloff implementation.
There's no need to close anything but the whole socket.
|
|
Listener death should have no effect on a peeled off association.
|
|
Forwarding an sctp message from the listener process at the same time
that the controlling process is changed means there's no guarantee that
the message order will be preserved. Selectively receive the peeloff
message before entering the gen_server loop to ensure the order is
preserved.
|
|
This is not the case under Solaris for one: successive
associations can receive the same association id as a result of peeloff,
the id only being unique for the controlling port, not for the listening
port as is the case under Linux for example. This made for many failures
in the diameter test suites, the traffic suite in particular.
Peeloff in diameter_sctp was introduced in 9a671bf0, before which the
assumption was fine since it was the listening process that owned all
associations. (Which obviously had other drawbacks.) Other remnants of
the pre-peeloff implementation have also been removed: that the listener
process might receive a message on a socket after peeloff for one.
Peeloff in gen_sctp became available in commit 067cfe79, after the
original implementation of diameter_sctp.
This is trace on the unpatched code showing id reuse under Solaris:
+ {trace_ts,<0.103.0>,call,
{diameter_sctp,handle_info,
[{sctp,#Port<0.1625>,
{127,0,0,1},
35904,
{[],{sctp_assoc_change,comm_up,0,32,32,1}}},
{listener,#Ref<0.0.1.948>,#Port<0.1625>,4,
57384,
{-4,61481},
#Ref<0.0.8.12>,
[]}]},
{1432,458752,612168}}
+ {trace_ts,<0.103.0>,call,
{diameter_sctp,handle_info,
[{sctp,#Port<0.1625>,
{127,0,0,1},
35905,
{[],{sctp_assoc_change,comm_up,0,32,32,1}}},
{listener,#Ref<0.0.1.948>,#Port<0.1625>,4,
57384,
{-3,61481},
#Ref<0.0.8.12>,
[]}]},
{1432,458752,613042}}
The result was this, when the second association was incorrectly
forwarded to the first association's controlling process:
** {function_clause,
[{diameter_sctp,transition,
[{peeloff,#Port<0.1635>,
{sctp,#Port<0.1625>,
{127,0,0,1},
35892,
{[],{sctp_assoc_change,comm_up,0,32,32,1}}},
[]},
{transport,<0.107.0>,accept,#Port<0.1634>,1,undefined,{32,32},0}],
[{file,"transport/diameter_sctp.erl"},{line,561}]},
{diameter_sctp,t,2,[{file,"transport/diameter_sctp.erl"},{line,549}]},
{diameter_sctp,handle_info,2,
[{file,"transport/diameter_sctp.erl"},{line,397}]},
{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,614}]},
{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,680}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,238}]}]}
|
|
|
|
Commit 4b691d8d made it possible for accepting transport processes to be
started concurrently, and commit 77c1b162 adapted diameter_sctp to this,
but missed that the publication of the listener process in diameter_reg
has to precede the return of its start function. As a result, concurrent
starts could result in multiple listener processes.
|
|
* anders/diameter/time/OTP-12439:
Use new time api in test suites
Use new time api in implementation
|
|
* anders/diameter/pool/OTP-12428:
Fix SCTP match blunder in suites
Be backwards compatible with diameter_sctp listener state
Add gen_tcp testcase that fails sporadically
Simplify transport suite
Remove (ancient) dead code
Don't orphan slave nodes in example suite
Refresh example code
Improve language consistency in diameter(1)
Add pool suite to test transport_opt() pool_size
Adapt tcp/sctp transport modules for pool_size > 1
Add transport_opt() pool_size
|
|
In particular, deal with the deprecation of erlang:now/0 in OTP 18. Be
backwards compatible with older releases: the new api is only used when
available.
The test suites have not been modified.
|
|
Commit 24993fc2 modified the state even in the case that the new
pool_size option the change was introduced to support was not used.
Doing so made downgrade impossible since old code would not be prepared
for the modified state. Retain a compatible state, so that simple code
replacement is enough.
|
|
Commit 9a671bf0 removed the need for diameter_sctp to send outgoing
messages through the listening process. That was prior to R5B02, so the
clause isn't need for any upgrade case.
|
|
In particular, that starts for the same transport reference can now be
concurrent. Looking up a listener process and starting a new one if not
found did handle this (more than one process could find no listener),
and diameter_sctp assumed there could only be one transport process
waiting for an association.
|
|
As suggested in supervisor(3). The leaves of the supervision tree should
determine the timeouts.
|
|
Introduced in commit ed6395a6. The {stream, Id} transport_data set upon
reception is passed back to us by default when receiving the answer to a
request message, so even capabilities exchange failed.
|
|
OTP-10229 (commit c4592b69) added these function to give access to all
addresses on a multihomed endpoint, their singular siblings not
returning anything useful in this case.
This fixes {accept, Match} config, which matches peer addresses against
configured addresses or regexps to decide whether or not a newly
established association should be retained. The functionality was added
in OTP-10893 (commit 9bbf27eb) but predated OTP-10229 by a few months.
It also fixes the addresses shown for SCTP associations in
diameter:service_info/2 output.
|
|
* anders/diameter/17.0_release/OTP-11605:
vsn -> 1.6
Remove upgrade-related code
Update appup for 17.0
Avoid type gen_sctp:open_option() until it actually exists
|
|
No longer needed to update code in runtime since the emulator is
restarted at a major release.
|
|
The type's existence is the subject of OTP-11139, which has been
gathering dust since R16B.
http://erlang.org/pipermail/erlang-bugs/2013-September/003765.html
|
|
The module uses the transport_data field of record diameter_packet to
communicate the stream on which the an incoming message is received and
on which an outgoing message should be sent, the previous interface
being that both are communicated as a tuple of the form {stream, Id}.
However, since diameter retains the value of an incoming request's
transport_data unless the corresponding answer message specifies
otherwise, the behaviour in this case is to send an answer on the
outbound stream with the same identifier as the that of the inbound
stream on which the request was received. If the inbound stream id is
greater than or equal to the number of outbound streams then this is
guaranteed to fail, causing the transport process in question to
terminate. There is no relationship between inbound and outbound stream
identifiers so diameter_sctp's imposition of one is simply wrong.
Outbound stream ids are now communicated with a different tuple:
{outstream, Id}, interpreted modulo the number of outbound streams.
Thus, retention of an inbound request's transport_data has no effect on
the selection of an outbound stream.
The change in interface is not strictly backwards compatible because of
the new atom for the outbound stream. However, as there is currently no
documented way of obtaining the available number of outbound streams for
a peer connection, there is no way for a client to have known the range
of ids from which it could reliably have chosen with the previous
interface, so any setting of the outbound stream has probably been
unintentional. Not explicitly specifying an outbound stream now results
in a round-robin selection.
|
|
Option 'accept' allows remote addresses to be configured as tuples or
regular expressions. The remote addresses for any incoming (aka
accepted) connection/association are matched against the configured
values, any non-matching address causing the connection/association to
be aborted.
|
|
The third argument to start/3 was just wrong.
|
|
|
|
Use the default address address (as selected by gen_tcp) if none is
configured, passing it in the new 'connected' message introduced by the
previous commit.
The corresponding update to diameter_sctp has to wait until problems
with inet:sockname/1 are resolved: the function currently only returns
one address, and sometimes {0,0,0,0}. See OTP-11018.
|
|
|
|
Don't start a new timer with each incoming message. Instead, start a
timer at timeout and flush after two successive timeouts with no message
reception.
|
|
|
|
Which will be the case in R16B.
|
|
|
|
Which will be the case with R16B in this case.
|
|
|
|
|
|
* anders/diameter/R15B02_release:
Dialyzer spec fix
Learn to keep time in diameter_gen_sctp_SUITE
Update command line test for changed ct:run_test/1 return value
OTP-10243
|
|
|
|
* anders/diameter/sctp_peeloff/OTP-9611:
Use gen_sctp:peeloff/2 to transfer association ownership
|
|
To be used by diameter_service in constructing service_info.
|
|
The transport process is now controlling process even in the
accept case.
|
|
Module contains a transport start function that calls an a
specified function, and more.
|
|
It isn't always the case. The information isn't currently used in
any case.
|
|
Simpler, no duplication of similar makefiles and makes for
better dependencies. (Aka, recursive make considered harmful.)
|
|
|
|
|
|
This is the method added in draft-ietf-dime-rfc3588bis, whereby
a TLS handshake immediately follows connection establishment and
CER/CEA is sent over the secured connection.
|
|
RFC 3588 requires that a Diameter server support TLS but in
practise this seems to mean TLS over SCTP since there are limitations
with running over SCTP: see RFC 6083 (DTLS over SCTP), which is a
response to RFC 3436 (TLS over SCTP). The current RFC 3588 draft
acknowledges this by equating the Inband-Security-Id value TLS
with TLS/TCP and DTLS/SCTP but underlying support for DTLS is
still thin on the ground.
|
