aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/transport
AgeCommit message (Collapse)Author
2017-09-18Merge branch 'anders/diameter/sctp/OTP-10889' into maintAnders Svensson
* anders/diameter/sctp/OTP-10889: Make unordered delivery configurable
2017-09-17Make unordered delivery configurableAnders Svensson
Changing the default in the parent commit is possibly a bit dangerous, even if the motivation still holds. Take a step back and make unordered delivery a matter of configuration, without changing the default: configuration is {unordered, boolean() | pos_integer()}, with false the default, and N equivalent to OS =< N, where OS is the number of outbound streams negotiated on the association in question. A user can mess with this by configuring an sctp_default_send_param of their own, but unordered sending is them from start, not only after the second message reception.
2017-09-03Merge branch 'anders/diameter/sctp/OTP-10889' into maintAnders Svensson
* anders/diameter/sctp/OTP-10889: Send unordered on all outbound diameter_sctp streams Delay rotation of diameter_sctp outbound streams Exercise unordered delivery in traffic suite Use unordered delivery on a lone outbound stream in diameter_sctp
2017-08-29Send unordered on all outbound diameter_sctp streamsAnders Svensson
There's no reason for sending ordered since request handling is concurrent: different processes handling incoming requests can't know in which order they were received on the transport, and different processes sending requests can't know the order in which they're sent.
2017-08-29Delay rotation of diameter_sctp outbound streamsAnders Svensson
For the same reason as unordered delivery is delayed in the grandparent commit. Delivery is ordered only within a stream, so until a second message is received from the peer, there's no guarantee that a second outgoing request won't be received before the initial capablities exchange message. Rotation begins upon reception of a second message from the peer, messages being sent on stream 0 until then.
2017-08-29Merge branch 'anders/diameter/config_consistency/OTP-14555' into maintAnders Svensson
* anders/diameter/config_consistency/OTP-14555: Let strict_mbit and incoming_maxlen be configured per transport Let a service configure default transport options Rename type evaluable -> eval
2017-08-29Merge branch 'anders/diameter/loopback_any/OTP-14544' into maintAnders Svensson
* anders/diameter/loopback_any/OTP-14544: Use loopback/any config in examples suite Handle loopback/any as local address in diameter_tcp/sctp
2017-08-29Use unordered delivery on a lone outbound stream in diameter_sctpAnders Svensson
RFC 6733 say the below about head-of-line blocking and SCTP, the suggestion of unordered sending being new compared to the RFC 3588. Until now, all delivery in diameter_sctp has been ordered, and roundrobin over available streams unless the user passes a stream identifier in an outgoing diameter_packet record. This commit changes this to use unordered delivery when there's only a single outbound stream to choose from. The special case at capabilities exchange is handled by only starting to send unordered after the second message from the peer has been received. (First message after capabilities exchange, as the RFC probably means.) The special case at DPR isn't handled, since there's no knowing the order in which a peer will answer: a node that sends DPR while it has other requests outstanding can't expect that the latter will be answered before DPR, even if delivery is ordered since incoming requests are handled concurrently. If it wants a guarantee then it simply has to wait for answers before sending DPR. A user can force all delivery to be unordered by specifying {sctp_default_send_params, #sctp_sndrcvinfo{flags = [unordered]}} as a config option to diameter_sctp, but in this case there's no handling of a request being sent directly after CEA since there's no ordered flag to override the default. RFC 6733: 2.1.1. SCTP Guidelines Diameter messages SHOULD be mapped into SCTP streams in a way that avoids head-of-the-line (HOL) blocking. Among different ways of performing the mapping that fulfill this requirement it is RECOMMENDED that a Diameter node send every Diameter message (request or response) over stream zero with the unordered flag set. However, Diameter nodes MAY select and implement other design alternatives for avoiding HOL blocking such as using multiple streams with the unordered flag cleared (as originally instructed in RFC 3588). On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream, and it is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. These messages can be out-of-order and belong to different Diameter sessions. Out-of-order delivery has special concerns during a connection establishment and termination. When a connection is established, the responder side sends a CEA message and moves to R-Open state as specified in Section 5.6. If an application message is sent shortly after the CEA and delivered out-of-order, the initiator side, still in Wait-I-CEA state, will discard the application message and close the connection. In order to avoid this race condition, the receiver side SHOULD NOT use out-of-order delivery methods until the first message has been received from the initiator, proving that it has moved to I-Open state. To trigger such a message, the receiver side could send a DWR immediately after sending a CEA. Upon reception of the corresponding DWA, the receiver side should start using out-of- order delivery methods to counter the HOL blocking. Another race condition may occur when DPR and DPA messages are used. Both DPR and DPA are small in size; thus, they may be delivered to the peer faster than application messages when an out-of-order delivery mechanism is used. Therefore, it is possible that a DPR/DPA exchange completes while application messages are still in transit, resulting in a loss of these messages. An implementation could mitigate this race condition, for example, using timers, and wait for a short period of time for pending application level messages to arrive before proceeding to disconnect the transport connection. Eventually, lost messages are handled by the retransmission mechanism described in Section 5.5.4.
2017-08-24Rename type evaluable -> evalAnders Svensson
Export the old type as a synonym for backwards compatability. The name evaluable is a bit too awkward.
2017-08-19Handle loopback/any as local address in diameter_tcp/sctpAnders Svensson
The support is implied by documentation, but wasn't handled in code. Be consistent in retrieving the address from the sock rather than the configuration, and in accepting both ip and ifaddr for a local address.
2017-08-18Merge branch 'anders/diameter/performance/OTP-14521' into maintAnders Svensson
* anders/diameter/performance/OTP-14521: Work around unexpected common_test behaviour Randomly skip groups in traffic suite Randomly disable traffic counters in traffic suite Add service_opt() traffic_counters Fix type spec Split AVPs at decode Avoid unnecessary copying of binaries in diameter_tcp Don't update diameter_tcp state unnecessarily Don't update diameter_tcp state unnecessarily Simplify extraction of incoming Diameter messages in diameter_tcp Restructure/simplify message reception in diameter_peer_fsm Sleep randomly at the start of (parallel) traffic testcases Fix ct return value in traffic suite Fix type spec Optimize sub-binaries Optimize sub-binaries Count AVPs in #diameter_avp.index Don't extract options unnecessarily at encode Redo message decode as a single pass
2017-08-10Avoid unnecessary copying of binaries in diameter_tcpAnders Svensson
Since messages are accumulated by appending binaries as of three commits back, the accumulated binary is prone to being copied, as discussed in the Efficiency Guide. Matching the Message Length header as bytes are being accumulated is one cause of this, so work around it by splitting the binary and extracting the length without a match. This doesn't feel like something that should be necessary: that matching a binary would cause an append to copy isn't obvious. The first attempt at simplifying the accumulation was simply to append an incoming binary to the current fragment, match against <<_, Len:24, _/binary>> to extract the length, and then test if there are enough bytes for a message. This lead to horrible performance (response times for 2 MB messages approximately 100 times worse than previously), and it wasn't at all obvious that the reason was the accumulated binary being copied with each append as a result of the match. Using split_binary avoids the match context that forces the copying.
2017-08-10Don't update diameter_tcp state unnecessarilyAnders Svensson
Not with each setopts to re-activate the socket.
2017-08-10Don't update diameter_tcp state unnecessarilyAnders Svensson
Only reset the fragment after all messages have been extracted.
2017-08-10Simplify extraction of incoming Diameter messages in diameter_tcpAnders Svensson
Appending to a binary is efficient, so just append message fragments Only match out the length once per message since doing so for every packet from TCP causes the binary to be copied.
2017-08-09Merge branch 'anders/diameter/transport/ERL-332' into maintAnders Svensson
* anders/diameter/transport/ERL-332: Remove irrelevant comment Add missing setopts after deferred diameter_{tcp,sctp} actions
2017-06-28Remove irrelevant commentAnders Svensson
2017-06-21Add missing setopts after deferred diameter_{tcp,sctp} actionsAnders Svensson
Since the actions can request that a previously passive socket be made active. Missed in commits 636a7199 and 373cd07c.
2017-06-14Merge branch 'anders/diameter/transport/ERL-332'Anders Svensson
* anders/diameter/transport/ERL-332: (35 commits) Capitulate on SCTP vs sparc-sun-solaris2.10 Remove obsolete traffic testcase Fix dialyzer warnings Remove client/server string decode from traffic suite Add diameter_sctp option packet Add diameter_sctp send/recv callbacks Let diameter_tcp send/recv callbacks deal in diameter_packet Randomly select traffic testcases Exercise diameter_tcp message callbacks in traffic suite Exercise diameter_{tcp,sctp} sender in traffic suite Remove upgrade from diameter_traffic Add diameter_tcp send/recv callbacks Make diameter_{tcp,sctp} sender configurable Remove upgrade from diameter_sctp; tweak diameter_tcp to match Fix incomprehensible dialyzer warning Simplify acks to transport processes Strip throttling callbacks from diameter_tcp Deal with (another) SCTP association id quirk on Solaris Use binary:copy/2 when generating largish data in test suites Deal with SCTP association id quirk on Solaris ...
2017-06-12Fix dialyzer warningsAnders Svensson
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()]}
2017-06-12Add diameter_sctp option packetAnders Svensson
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.
2017-06-12Add diameter_sctp send/recv callbacksAnders Svensson
Corresponding to diameter_tcp callbacks a few commits back. Exercise the callbacks in the traffic suite.
2017-06-12Let diameter_tcp send/recv callbacks deal in diameter_packetAnders Svensson
To let a recv callback for an incoming request set transport_data and have it returned in a send callback.
2017-06-12Add diameter_tcp send/recv callbacksAnders Svensson
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.
2017-06-11Make diameter_{tcp,sctp} sender configurableAnders Svensson
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.
2017-06-11Remove upgrade from diameter_sctp; tweak diameter_tcp to matchAnders Svensson
Added in commit 2afd1fe5. Only rename variables in diameter_tcp, no functional change.
2017-06-11Fix incomprehensible dialyzer warningAnders Svensson
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.
2017-06-11Strip throttling callbacks from diameter_tcpAnders Svensson
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.
2017-06-11Deal with (another) SCTP association id quirk on SolarisAnders Svensson
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
2017-06-11Deal with SCTP association id quirk on SolarisAnders Svensson
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.
2017-06-11Add missing dialyzer typesAnders Svensson
Which dialyzer itself has never complained about.
2017-06-11Don't send from receiving transport processesAnders Svensson
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.
2017-06-11Fix gen_tcp close of ssl socketAnders Svensson
Should be ssl:close/1.
2017-06-11Remove clauses supporting old codeAnders Svensson
Since smooth upgrade won't be supported in this branch.
2017-05-04Update copyright yearRaimo Niskanen
2017-02-14Fixed typos in lib/diameterAndrew Dryga
2016-08-26Close listening sockets at service deathAnders Svensson
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.
2016-05-30Close listening sockets at transport removalAnders Svensson
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.
2016-05-09Merge branch 'anders/diameter/overload/OTP-13330'Anders Svensson
* 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
2016-05-04Suppress dialyzer warningAnders Svensson
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.
2016-05-03Remove dead case clauseAnders Svensson
Orphaned in commit 9298872b.
2016-03-18Let throttling callback send a throttle messageAnders Svensson
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.
2016-03-15update copyright-yearHenrik Nord
2016-03-13Throttle properly with TLSAnders Svensson
In particular, let a callback decide when to receive the initial message.
2016-03-13Don't ask throttling callback to receive more unless neededAnders Svensson
TCP packets can contain more than one message, so only ask to receive another message if it hasn't already been received.
2016-03-13Let a throttling callback answer a received messageAnders Svensson
As discussed in the parent commit. This is easier said than done in practice, but there's no harm in allowing it.
2016-03-13Let a throttling callback discard a received messageAnders Svensson
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.
2016-03-13Let throttling callback return a notification pidAnders Svensson
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.
2016-03-13Make throttling callbacks on message receptionAnders Svensson
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.
2016-03-13Add diameter_tcp option throttle_cbAnders Svensson
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.