Age | Commit message (Collapse) | Author |
|
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.
|
|
By doing away with more wrapping that the parent commit started to
remove.
|
|
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.
|
|
If TLS has been configured on Inband-Security-Id then the transport
process receives a message from the peer_fsm process indicating
whether or not to upgrade to TLS.
The current draft of RFC 3588 deprecates (but retains for backwards
compatibility) the use of Inband-Security-Id for negotiating TLS,
adding the possibility of TLS having be negotiated before capabilities
exchange. This commit handles the deprecated case.
|
|
When an initial message is received and TLS is a possibility, must
wait for a message from the peer process before either commencing
a handshake or receiving more messages.
|
|
The events are enabled by default but diameter_sctp neither disabled
nor dealt with them. Reception of such an event caused a transport
process to crash.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|