| Age | Commit message (Collapse) | Author |
|---|
|
Despite the efforts of commits 1df74351 and 111261d1 to salvage it, SCTP
is just flakey on sparc-sun-solaris2.10. In addition to the woes of the
loopback address, even connect on other addresses sporadically returns
{error, eafnosupport}, so the initial check for a working SCTP (aka
resistance) is futile. Revert both commits.
|
|
Outgoing requests no longer write to the request table, as of commit
a4da06a5.
|
|
Decode on both ends or not, since the choice doesn't affect the peer.
|
|
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.
|
|
Since the number of configuration variants tested makes for (too) many.
Randomly select a subset of testcases in each configuration group.
|
|
|
|
|
|
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.
|
|
Faster than lists:duplicate/2.
|
|
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.
|
|
By explicitly skipping instead of omitting testcases from groups.
|
|
Autoskip traffic testcases if transport isn't established instead of
having traffic cases run and fail.
|
|
Testcase is already run elsewhere on the suite.
|
|
In particular, that transmission can be very slow. The problem appears
to be linked to sndbuf/recbuf, but even with buffers that are large
enough to hold all messages being sent, turnaround times can still vary
by hundreds of milliseconds in a reasonable test environment.
Use multiple streams and a sender process to more closely mirror the
usage in diameter_sctp, but neither is the source of the problems.
|
|
The server sent and died, but there's no guarantee that it won't take
the connection down before the client has receive its bytes. Make the
server wait for the client to take down the connection.
|
|
This addresses the testcase failures mentioned in the parent commit,
which has been on account of the behaviour below, in which connect fails
on the loopback address. Work around it by finding/using another address
if possible.
$ erl
Erlang/OTP 20 [DEVELOPMENT] [erts-9.0] [smp:2:2] [ds:2:2:10] [async-threads:10] [hipe] [kernel-poll:false] [sharing-preserving]
Eshell V9.0 (abort with ^G)
1> {ok, LP} = gen_sctp:open().
{ok,#Port<0.439>}
2> gen_sctp:listen(LP, true).
ok
3> inet:socknames(LP).
{ok,[{{10,67,16,178},36506},{{127,0,0,1},36506}]}
4> {ok, S} = gen_sctp:open([{ip, {127,0,0,1}}]).
{ok,#Port<0.443>}
5> gen_sctp:connect_init(S, {127,0,0,1}, 36506, []).
{error,eaddrnotavail}
6> gen_sctp:connect_init(S, {10,67,16,178}, 36506, []).
{error,eaddrnotavail}
7> gen_sctp:close(S).
ok
8> f(S).
ok
9> {ok, S} = gen_sctp:open().
{ok,#Port<0.444>}
10> gen_sctp:connect_init(S, {127,0,0,1}, 36506, []).
ok
Even the following has been seen on at least one host, so that success
of gen_sctp:open/0 is no guarantee.
$ ifconfig -a4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
inet 10.67.16.180 netmask ffffff00 broadcast 10.67.16.255
$ erl
Erlang/OTP 20 [DEVELOPMENT] [erts-9.0] [source] [smp:2:2] [ds:2:2:10] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V9.0 (abort with ^G)
1> {ok, S} = gen_sctp:open(),
1> gen_sctp:connect(S, {127,0,0,1}, 3868, []).
{error,eafnosupport}
2> gen_sctp:connect(S, {10,67,16,180}, 3868, []).
{error,eafnosupport}
|
|
The comment in commit 736ce20a isn't quite true. There's no different
behaviour that diameter doesn't support, but there is a quirk with the
loopback address that has caused many testcases to fail. This will be
addressed in a subsequent commit.
Reverts commit 736ce20a.
|
|
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.
|
|
|
|
|
|
* 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
|
|
The SCPT stack has a different behavior in solaris2.10 then in later versions
and linux. Diameter implementation does not support this behavior.
|
|
Since the large strings copied between processes cause testcases to fail
randomly.
Option string_decode was added in commit 1590920c.
|
|
* anders/diameter/rand/OTP-13664:
Use rand(3) instead of random(3)
|
|
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.
|
|
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.
|
|
Letters are cheap.
|
|
Unused, and in the way for what's to come.
|
|
* anders/diameter/test/OTP-13438:
Don't assume list comprehension evaluation order
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
* 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/lcnt/OTP-12912:
Make ets diameter_stats a set
Remove unnecessary sorting in stats suite
Set ets {write_concurrency, true} on diameter_stats
Don't start watchdog timers unnecessarily
Remove unnecessary erlang:monitor/2 qualification
Add missing watchdog suite clause
|
|
The ordering of (ets) diameter_stats (also unnecessary) ensures the
sorting.
|
|
By doing away with more wrapping that the parent commit started to
remove.
|
|
Commit c74b593a fixed the problem that a decoded deep diameter_avp list
couldn't be encoded, but did so in the wrong way: there's no need to
reencode component AVPs since the Grouped AVP itself already contains
the encoded binary. The blunder caused diameter_codec:pack_avp/1 to fail
if the first element of the AVP list to be encoded was itself a list.
Thanks to Andrzej Trawiński for reporting the problem.
|
|
The suite pretends to be gen_tcp-ish in configuring itself to
diameter_tcp. The function close/1 can be called as a result.
|
|
OTP-12845
* bruce/change-license:
fix errors caused by changed line numbers
Change license text to APLv2
|
|
* anders/diameter/sctp/OTP-12768:
Fix connection timeouts in test transports
Fix start order of alternate transports
Log discarded answers
Ensure accepting processes are first in, first out
Remove upgrade-related code
Be less parallel in traffic suite
Increase send/receive buffers for testsuite SCTP listeners
Decrease unnecessarily long testsuite timetraps
Simplify accepting transport start
Simplify peeloff signaling
Simplify socket close at terminate
Don't monitor listener after peeloff
Don't receive initial messages out of order
Remove assumption that SCTP association ids will be unique
|
|
* anders/diameter/grouped_errors/OTP-12721:
Fix decode of Grouped AVPs containing errors
Simplify logic
Simplify logic
|
|
Without a timeout, TCP/SCTP connect can take some time to fail, which
resulted in failures in the pool suite after the parent commit fixed the
previously faulty sctp-first-then-tcp connect.
|
|
At the current count, there are 128 groups run in parallel, each of
which runs 52 testcases in parallel. That makes for 128*52 = 6656
testcases, which is probably also a factor in the sporadic failures
addressed by the parent commit. Don't run the 128 groups in parallel.
|
|
The defaults result in sporadic timeouts in the traffic suite after
testing over SCTP was added in commit fadf753b. The behaviour looks to
be specific to SLES 11, and is presumably the same resends/congestion
that lead to the buffers being increased in the gen_sctp suite in commit
12febf13 (and commented in commit e931991f). The behaviour hasn't been
seen on SLES 10.
|
