diameter_sctp
Diameter transport over SCTP.
This module implements diameter transport over SCTP using gen_sctp(3). It can be specified as the value of a transport_module option to diameter:add_transport/2 and implements the behaviour documented in diameter_transport(3).
Functions
start({Type, Ref}, Svc, [Opt]) -> {ok, Pid, [LAddr]} | {error, Reason}
Type = connect | accept
Ref = diameter:transport_ref()
Svc = #diameter_service{}
Opt = {raddr, inet:ip_address()} | {rport, integer()} | term()
Pid = pid()
LAddr = inet:ip_address()
Reason = term()
The start function required by diameter_transport(3).
The only diameter_sctp-specific argument is the options list.
Options raddr
and rport
specify the remote address
and port for a connecting transport and not valid for a listening
transport: the former is required while latter defaults to 3868 if
unspecified.
More than one raddr
option can be specified, in which case the
connecting transport in question attempts each in sequence until
an association is established.
Remaining options are any accepted by gen_sctp:open/1, with the exception
of options mode
, binary
, list
, active
and sctp_events
.
Note that options ip
and port
specify the local address
and port respectively.
Multiple ip
options can be specified for a multihomed peer.
If none are specified then the values of Host-IP-Address
in the #diameter_service{}
record are used.
(In particular, one of these must be specified.)
Option port
defaults to 3868 for a listening transport and 0 for a
connecting transport.
Warning!
An insufficiently large receive buffer may result in a peer having to
resend incoming messages: set the inet(3) option recbuf
to increase
the buffer size.
An insufficiently large send buffer may result in outgoing messages
being discarded: set the inet(3) option sndbuf
to increase
the buffer size.
diameter_sctp uses the transport_data
field of
the #diameter_packet{}
record to communicate the stream on which an
inbound message has been received, or on which an outbound message
should be sent: the value will be of the form {stream, Id}
on an inbound message passed to a handle_request/3 or
handle_answer/4 callback.
For an outbound message, either undefined
(explicitly or
by receiving the outbound message as a binary()
) or a tuple
should be set in the return value of handle_request/3
(typically by retaining the value passed into this function)
or prepare_request/3.
The value undefined
uses a "next outbound stream" id and
increments this modulo the total number outbound streams.
That is, successive values of undefined
cycle through all
outbound streams.